Two model IDs change meaning on August 5: check whether your code names one of them

On August 5, claude-opus-4-1-20250805 reaches its retirement date. Anthropic's model deprecations page is unambiguous about what happens next: "Requests to retired models will fail." The model was deprecated on June 5, and the recommended replacement is claude-opus-4-8.

On the same day, grok-voice-latest starts pointing somewhere else. xAI's release notes put it in one line: "grok-voice-latest will route to this model starting August 5, 2026," where the model is Grok Voice Think Fast 2.0 rather than the 1.0 your code has been reaching so far.

Two unrelated companies, two unrelated products, one date. One of them fails loudly. The other swaps silently and returns a 200 the whole time.

That coincidence is the useful part. The model identifier sitting in your config is not a constant you write once. It is a pointer that someone else maintains on their release calendar, and the last two weeks produced four different mechanisms for moving it.

A retirement has a date and a hard edge

Retirement is the version you can plan for, because the date is published in advance and Anthropic commits to "at least 60 days' notice before model retirement for publicly released models." Opus 4.1 got that notice on June 5.

It is also the version people miss, because nothing degrades first. The call works exactly as well on August 4 as it did in June, and then it does not work at all. If a cron job, a background worker, or an evaluation harness still names claude-opus-4-1-20250805, the failure lands wherever that code runs, which is often not where anyone is looking.

Worth noting for anyone still on that model for cost reasons: Opus 4.1 is priced at $15 per million input tokens and $75 output, while the replacement claude-opus-4-8 is $5 and $25. Migrating off it is a price cut, not a price increase.

An alias is a pointer, and pointers move

xAI documents the convention plainly on its models page: <modelname>-latest is aliased to the latest version, while <modelname>-<date> refers directly to a specific model release. Writing -latest is an explicit decision to accept whatever the vendor ships next, including on a Wednesday you were not planning to deploy.

Anthropic has moved the other direction, which is easy to misread. Its models overview states: "Every Claude model ID is a pinned snapshot. Models with a date in the ID (for example, 20250929) are fixed to that specific release. Starting with the Claude 4.6 generation, model IDs use a dateless format that is also a pinned snapshot, not an evergreen pointer." So claude-opus-5 looks like an alias and behaves like a pin. For models before the 4.6 generation, the same-looking dateless string is a convenience pointer that resolves to a dated ID.

The practical rule is not "always pin" or "always float." It is that you should be able to say, for each provider you call, which of the two you chose and why. A string that looks stable across two vendors can mean opposite things.

Defaults move, and one of them is hidden on purpose

Claude Opus 5 shipped on July 24 as, in Anthropic's own words, "the new default model on Claude Max, and the strongest model on Claude Pro." Anyone on a Max subscription got a different model behind the same chat box without changing a setting.

Cursor went further on July 22 with Router. Cursor's changelog describes it as "our intelligent model router. It analyzes each request and sends it to the right model for the job," and adds two details that matter more than the feature itself: "It is on by default for Teams plans," and "Routed model can be displayed or hidden (hidden by default)."

Read those together and the situation is specific rather than alarming. If your team is on Cursor Teams, requests are being assigned to models by a classifier, and the default configuration does not tell the developer which model answered. That is a reasonable product decision and a bad debugging position. If two engineers get different output quality on the same task this week, "which model served that" is currently an unanswerable question for them unless an admin turns the display on.

Something similar already happened inside Claude Code, where the built-in Explore subagent stopped defaulting to Haiku and started inheriting the session model. We wrote up the exact override and the pricing math when that landed. Same pattern, different surface: the model your work runs on was decided by a default you did not set.

The price moves under an ID that never changed

The fourth mechanism does not touch the identifier at all. It changes what the identifier costs.

Anthropic's pricing page carries a dated note: "Introductory pricing of $2/$10 per million input/output tokens is in effect through August 31, 2026, after which the standard pricing of $3/$15 per million input/output tokens will take effect." That is a 50% increase on both input and output for claude-sonnet-5, on a fixed calendar date, with no model change and no deploy. Batch pricing steps from $1/$5 to $1.50/$7.50, and cache reads from $0.20 to $0.30 per million.

OpenAI moved the same lever in the other direction on July 30. Reporting from CNBC, VentureBeat citing Reuters, and Axios has GPT-5.6 Luna dropping 80%, from $1/$6 to $0.20/$1.20 per million tokens, and Terra dropping 20%, from $2.50/$15 to $2/$12. OpenAI's own post was not reachable directly when we checked, so treat the figures as consistent secondary reporting rather than a primary quote. The timing is the point regardless: GPT-5.6 became generally available on July 9, and the prices moved three weeks later. Any tier decision made at launch was based on numbers that no longer hold.

If you are budgeting per task rather than per seat, we went through that math in Frontier AI is going metered. The addition this week is that the inputs to that math now have expiry dates.

Finding out what you actually call

Three steps, in the order that gives you answers fastest.

Export your real usage. Anthropic documents this directly: go to the Usage page in Claude Console, click Export, and review the CSV, which breaks usage down by API key and model. This is more reliable than reading your own code, because it catches the staging key, the notebook, and the internal tool nobody remembers owning. Do the equivalent on every provider you pay.

Log the model that answered. The Messages API response body includes a model field identifying which model handled the request. So does the OpenAI chat completions response. Recording that field alongside your latency and cost metrics converts "which model served this?" from a guess into a query. It is a one-line change that pays for itself the first time output quality shifts and you need to know whether the model or your prompt moved.

Grep for the floating references. Search your repositories, environment files, and infrastructure config for -latest and for any model string older than your last two migrations. What you find is not automatically wrong. It just needs to be a decision rather than a leftover.

Changing the string is not the whole migration

Two traps sit in the current Claude generation specifically, and both are documented rather than folkloric.

Anthropic lists temperature, top_p, and top_k as deprecated from Claude Opus 4.7 onward, with this behavior: "Returns a 400 error when set to a non-default value on Claude 4.7 and later models." A request that has carried temperature: 0.2 for a year will start failing outright when you point it at a newer model. The recommended replacement is to omit them and steer through prompting instead.

The second one is quieter and shows up on the invoice. On Claude Opus 5 and Claude Sonnet 5, the effort parameter "defaults to high on the Claude API and Claude Code." Unless you set it, you are buying the expensive setting on every call, including the ones that classify a support ticket or extract a date from a string.

Where this lands, by who you are

If you ship code against a provider API: the export and the response-field log are today's work. Then decide, per call site, whether you want a pinned ID or a floating one. Batch jobs and evaluation harnesses argue for pinning, since a silent model swap invalidates a baseline you were using to make decisions.

If you run a team on Cursor Teams: turn on routed-model display. There is no cost to knowing, and the alternative is a class of quality complaints nobody can reproduce.

If you use a subscription rather than an API: you cannot pin anything, and that is fine. The thing to internalize is that the model behind your chat window changes on the vendor's schedule, so a workflow tuned on one model can shift under you without notice. Keep a small set of your own test prompts and re-run them when a default changes.

If you are on Claude Sonnet 5 at any volume: the 50% step on September 1 is the one worth calculating now, while there is still time to test Haiku 4.5 at $1/$5 on the subset of tasks that do not need Sonnet.

The dates already published

August 5: claude-opus-4-1-20250805 retires and requests to it fail; grok-voice-latest starts routing to Grok Voice Think Fast 2.0.

September 1: claude-sonnet-5 goes from $2/$10 to $3/$15 per million tokens.

September 29: claude-sonnet-4-5-20250929 reaches the earliest date Anthropic will retire it, currently listed as "not sooner than."

There is a separate reason to build the habit now. Anthropic's own status page logged model-specific incidents on July 25, 26, 27, 29, 30, and 31, and the entries name individual models rather than the API as a whole. That is worth pairing with a fallback path that can reach a second model when the first one is degraded. A fallback chain only helps if you know what is in it, which brings the whole thing back to the same question: which model string does your code name, and did you choose it?