On 5 August 2026, Claude Opus 4.1 was retired. Requests to it now fail.
That was not a surprise, an incident, or anyone’s fault. It was announced on 5 June — exactly 60 days earlier — and it appeared in a public table with a date next to it the whole time.
And yet I would bet real money that somewhere out there, a service went down that week because a model ID was hardcoded in a file nobody had opened since it was written.
We have seen this movie. It was called “the certificate expired.”
The shape of the problem
Strip away that this is AI, and look at the operational primitive:
- A deployed artifact your production system depends on
- With an externally-imposed expiry date
- That is published in advance
- Where missing the date causes hard failure, not degradation
- And where the fix requires work that takes longer than the notice period
That is a certificate. It is exactly a certificate. And we did not solve certificates by asking engineers to be more attentive to expiry emails. We solved them with inventory, automated tracking, alerting well ahead of the date, and eventually automated renewal.
Model EOL has all the same properties and currently gets none of the same tooling. Most organizations’ answer to “which models are we running and when do they retire” is a person who thinks they know.
Three things that make it harder than certificates
I do not want to push the analogy too far, because there are three ways model EOL is genuinely worse.
1. The same model has different dates in different places
This is the one that surprises people, and it comes straight from Anthropic’s own model deprecations page:
The dates on this page apply to Anthropic-operated platforms… Partner-operated platforms (Amazon Bedrock and Google Cloud) set their own retirement schedules, so a model’s lifecycle status and dates can differ.
Read that again if you run multi-cloud. “Which model version are we on” is not a question with one answer. It is a question per deployment target. A model that is Active on one platform can be Deprecated on another, with a different retirement date, and neither of those facts tells you about the third.
Your inventory key is not the model. It is the (model, platform) pair.
2. Renewal is not mechanical
A certificate renewal produces a functionally identical certificate. A model migration produces a different model, with different behavior, on your specific prompts, on your specific tasks.
You cannot script it. You have to evaluate it. Which brings us to the real problem.
3. There is no acme.sh for this
Certificate automation works because verification is cheap and deterministic. Model migration verification is neither. It requires an eval suite that reflects what you actually care about, and most teams do not have one.
The failure pattern
Here is how it goes wrong, and it is consistent enough to be a pattern:
- Deprecation email arrives. 60 days on the clock.
- It goes on the backlog, because 60 days is ages and there is an incident this week.
- Around day 25, someone picks it up and swaps the model ID.
- Around day 28, they run whatever evals exist and find a regression — output format drift, a tool-call pattern that changed, a prompt that was tuned to the old model’s verbosity.
- Now there are 32 days to diagnose behavior differences, re-tune prompts, re-run evals, and ship — while doing the normal job.
The mistake was not step 2. The mistake was that the answer to “does the replacement pass?” took 25 days to start producing and could not be produced in an afternoon.
Your migration timeline is not set by the vendor’s notice period. It is set by how fast you can answer that question. If you have a maintained eval suite, 60 days is comfortable. If you do not, 60 days is not enough and neither would 180 be, because you would spend the first 150 building the suite under deadline pressure — which is the worst possible time to decide what “good” means.
The bit that fails at runtime, not review
One trap worth calling out specifically, because it turns a config change into a code change.
Parameters deprecate too. Anthropic deprecated temperature, top_p, and top_k on Claude Opus 4.7 and later — setting them to a non-default value now returns a 400 error. Not a warning. Not a silently-ignored field. A rejected request.
So a migration that looks like this:
- model="claude-opus-4-1-20250805",
+ model="claude-opus-4-8",
temperature=0.2, # ← this line is now a 400…passes code review, passes type checking, and fails in production on the first request.
The general lesson: a model migration is a request-surface migration. Diff the whole request shape, not just the ID. Sampling parameters, thinking configuration, prefill patterns, tool schema versions, beta headers that went GA. Any of them can be the thing that breaks.
What to build
Four pieces. None of them are hard; they are just nobody’s job right now.
1. An inventory keyed on (model, platform)
Not a wiki page. A file in a repo, or a row in a database, that CI can read.
| Field | Example |
|---|---|
model_id | the exact string sent on the wire |
platform | first-party API / Bedrock / Vertex / self-hosted |
eol_date | from that platform’s published schedule |
owning_service | who breaks when it goes |
replacement | the designated successor |
evals_last_green | date the suite last passed against the replacement |
That last field is the one that makes this useful rather than decorative. An inventory that tells you a date is a calendar. An inventory that tells you whether you are ready for the date is an operational tool.
2. Alert at 120 days
Not 30. Not on the vendor’s email. The vendor’s notice period is calibrated to when they need to tell you, not to how long your migration takes.
If your provider gives 60 days and you alert at 120, you are alerting before the deprecation is announced — which sounds absurd until you notice that active models publish tentative retirement dates too. Anthropic’s table carries “not sooner than” dates for currently-active models. That is a planning signal available today, for free, on models nobody has deprecated yet.
Use it. Pull the table, diff it weekly, alert on changes.
3. Find out what you are actually running
You cannot inventory what you cannot see, and grep is not sufficient — model IDs end up in config files, environment variables, database rows, and prompt templates.
Most providers give you the ground truth. Anthropic’s is a usage export: Console → Usage → Export, producing a CSV broken down by API key and model. That is your reconciliation source. Run it against your inventory and find the rows you did not know about.
I would expect the first run of that to be uncomfortable. It usually is with certificates too.
4. Route through a gateway
If switching a model means editing eleven services, you have made a business decision about migration cost without realizing it.
Route model calls through a gateway that owns the model identity, so a migration is a config change in one place with a canary and a rollback. That is the same argument I made for model-aware routing in the inference gateway, and EOL is the strongest version of the case — because it converts a deadline-driven, multi-service code change into a routing rule you can roll forward and back on your own schedule.
It also unlocks the thing you actually want: shadow the replacement in production. Mirror a percentage of real traffic to the successor model, compare outputs offline, and build confidence from your own traffic instead of your test fixtures. That turns migration from an event into a gradient.
The eval suite is the real asset
I have been dancing around the conclusion, so let me state it.
Your prompts are not durable. Your model choice is not durable. The provider will retire it and you will move.
The durable asset is the eval suite — the encoded, executable definition of what correct output looks like for your workload. It is what makes a migration a two-day job instead of a two-month one, and it is the only artifact in your AI stack that appreciates rather than depreciating.
There is decent academic work on this now — When Your LLM Reaches End-of-Life frames confident model migration as its own problem class — and the practitioner version is simpler than the paper: if you cannot answer “does the new model pass?” in an afternoon, you do not have an eval suite, you have some tests.
The related argument for agent systems specifically is in evaluating AI SRE agents and in the case for keeping evals and graders in the repo alongside the workflow. Same principle, different surface: reliability evidence has to be portable, because the thing it is evidence about will be replaced.
One more reason to care
There is a version of this problem that is not about outages.
If you are in a regulated context, you may need to demonstrate what model produced a given output, on what date, with what evaluation evidence behind it. That is hard retroactively and easy prospectively — but only if the inventory exists and records evaluation state over time.
Anthropic has publicly committed to long-term preservation of model weights, partly in response to exactly this concern from researchers losing access to models mid-study. That is a good commitment. It is not the same as those models remaining available on the API, and your compliance story cannot depend on it.
The uncomfortably simple version
Models are dependencies with expiry dates. You already have a discipline for dependencies with expiry dates. Apply it.
- Inventory the (model, platform) pairs, because the dates differ per platform
- Record whether evals pass against the replacement, not just when the date is
- Alert months out, using the tentative dates published for active models
- Route through a gateway so the switch is config, not code
- Diff the whole request surface, not just the model string
None of that is novel. That is what makes it slightly embarrassing that most AI platforms do not have it.
The email will arrive. The only question is whether it is a ticket or an incident.
Related
- The inference gateway pattern: model-aware routing — making the swap a config change
- Evaluating AI SRE agents in 2026 — building the suite that makes migration cheap
- The SLM tier model: right-sizing what you run — how model choice per task changes the blast radius of any single EOL
- Agent workflows belong in code — why the evals live in the repo
Sources: Anthropic model deprecations documentation · When Your LLM Reaches End-of-Life (arXiv:2604.27082)
Comments