Your model id has an expiry date

On 5 August 2026, claude-opus-4-1-20250805 reached its retirement date on the Claude API. Anthropic's own wording for what happens next is unambiguous: Requests to retired models will fail. If that string is a literal somewhere in your application, the fix is a code change, a review, a build and a deploy, and the deadline was set by someone else, two months earlier.

This is not an Anthropic problem. It is the normal operating model of every major provider, and it has been for years. What varies is how much warning you get and whether anyone moves you. Below is what each provider actually commits to, read from their own policy pages, followed by the part most teams get wrong: assuming an alias protects them.

What the providers actually commit to

These are the published floors, not observed behaviour. Each links to the page it came from, because these pages change.

Two details in that table deserve more attention than they usually get.

Google's dates are floors, not schedules. The page states that the shutdown dates listed in the table indicate the earliest possible dates on which a model might be retired. A date in that column is not a date you can plan a migration around; it is the earliest one you might have to.

Anthropic's floor is also its practice. Take the three most recent retirements from its own deprecation history: Haiku 3 was announced 19 February 2026 and retired 20 April 2026; Sonnet 4 and Opus 4 were announced 14 April and retired 15 June; Opus 4.1 was announced 5 June and retired 5 August. Sixty, sixty-two, and sixty-one days. The published at least 60 days is what you will get, not a conservative worst case with slack behind it.

The "latest" alias is not the escape hatch

The obvious response to a dated model id is to stop writing dated model ids: point at -latest and let the provider handle it. This fails in three separate ways, and each one is documented by the provider itself.

Aliases get deprecated too. They are model ids, and they die like model ids. From OpenAI's own deprecation list: chatgpt-4o-latest announced 18 November 2025 and shut down 17 February 2026; codex-mini-latest announced 17 November 2025, shut down 12 February 2026; gpt-5-chat-latest and gpt-5.1-chat-latest announced 22 April 2026 and shut down 23 July 2026. Pointing at an alias does not buy you a stable target, and note that OpenAI classes chat variants as specialised, so they carry the 3-month floor rather than the 6-month one.

An alias that works moves under you. Google is explicit that a -latest id will get hot-swapped with every new release, with two weeks' notice before a breaking change. That is the correct behaviour for an alias, and it is also a model change landing in production on a date you did not choose, with no deploy of yours attached to it. If your evaluations are pinned to a snapshot and your serving is pinned to an alias, they are measuring different things.

An id that looks like an alias may not be one. Anthropic calls this out directly: A common misconception is that dateless model IDs such as claude-sonnet-4-6 behave as evergreen pointers that route to the latest or best-performing version. That is not the case. Meanwhile shorter aliases for pre-4.6 models, such as claude-sonnet-4-5, do point at the most recent dated snapshot. Two ids with the same shape, opposite semantics, in the same provider. Nothing in your code will tell you which one you have.

The same model dies on different days depending on where you call it

This is the one that catches teams who thought they had done the work. The provider's retirement date is not the retirement date: the retirement date belongs to the endpoint.

Anthropic states that its dates apply to Anthropic-operated platforms and that partner-operated platforms (Amazon Bedrock and Google Cloud) set their own retirement schedules. AWS states the same thing from its side: Bedrock's dates may differ from dates published by model providers (such as Anthropic or Cohere). For Amazon Bedrock usage, only the dates on this page apply.

Concretely, for the model that retired yesterday: claude-opus-4-1-20250805 is retired on the Claude API as of 5 August 2026, while anthropic.claude-opus-4-1-20250805-v1:0 on Bedrock went Legacy on 8 July 2026 with an EOL of 8 January 2027. Same weights, five extra months, depending only on which endpoint your code points at. The reverse also happens: claude-sonnet-4-20250514 was retired by Anthropic on 15 June 2026 and has a Bedrock EOL of 14 October 2026.

If you run multi-provider, and the reason most teams put a gateway in front of their traffic is that they do, then "when does this model die" has more than one answer, and the answer you need is the one for the path the request actually takes.

One platform will move you. Read what it moves.

Azure is the interesting exception: for Global Standard, Data Zone Standard and Standard deployment types, Microsoft manages automatic upgrades when a model version is retired, on a rolling region-by-region basis. Its documented example is gpt-4o version 2024-05-13 being automatically upgraded to gpt-5.1 at its retirement.

Three caveats sit in the same document, and each one turns the guarantee off:

• Provisioned deployments are not auto-upgraded. The docs put it in bold: provisioned customers must manually migrate.
• You can opt out, and opting out is not neutral. Setting versionUpgradeOption to NoAutoUpgrade means the deployment stops working at retirement.
• There is no appeal. Asked whether a retirement date can be extended, the FAQ answers: No. Retirement dates aren't extendable.

There is also a trap for anyone who tries to monitor this programmatically. Microsoft warns that the API uses different terminology than the docs and portal: a model the documentation calls Deprecated (still serving, closed to new customers) reports lifecycleStatus: "Deprecating", while the API value "Deprecated" means the model is retired and returns 410 Gone. A monitoring script that greps for Deprecated reads the opposite of what its author intended.

Where the indirection belongs

None of this argues for never pinning a version. Pinning is correct: it is what makes an evaluation result mean something, and Anthropic's guarantee that weights are fixed for the lifetime of an id is exactly what you want from a serving contract. The problem is not the pin. The problem is where the pin lives.

A model id in application code has three properties you do not want. It is duplicated across every service that calls the model. It is only changeable by whoever can deploy that service. And changing it is indistinguishable, in your release process, from changing business logic — same review, same risk, same window.

Moving the pin outward — into configuration, or into a routing layer the application talks to — leaves the pin intact and changes only who can move it and how fast. The application asks for a capability; something else decides which id serves it today. That decision becomes a config change with an audit trail instead of a release, which matters most on the day you have sixty days of notice and a change freeze.

This is one of the reasons Runix Router exists: your application holds one base URL, and which upstream id serves a request is decided behind it. But the argument stands regardless of what you put there — a config file you can reload, an internal service, a gateway you host yourself. What matters is that the id stops being a string literal in a binary you have to rebuild.

What to check this week

1. Grep for model ids. Every repository, plus environment variables, plus Terraform, plus notebooks, plus anything that was "just a script". Count the places. That count is your migration cost, and it is usually larger than the estimate.
2. Write down the retirement date for each id, per endpoint. Not per model — per endpoint. If you call the same model through two providers, that is two dates.
3. Find out whether you are on an alias, and whether it is really an alias. Both mistakes are common, and they fail in opposite directions.
4. Check the notification path. These notices go to account owners and subscription owners by email. If that address is a founder's inbox or a distribution list nobody reads, the 60 days you were promised are not 60 days you will get.
5. Time the change. Not the code edit — the whole path from decision to production, including review and any change freeze. Compare that number against 60 days, and against the two weeks a preview model gets.

The providers are not being unreasonable; they publish these schedules years in advance and mostly meet them. But every one of these dates is a deadline in someone else's calendar, and the only question that matters is whether meeting it costs you a deploy or a config change.

Every provider claim above was read from the linked policy page on 6 August 2026. These pages are revised; check the source before relying on a number.