What Breaks When Your Model Version Retires

The email arrives on a Friday. One of your model snapshots has a shutdown date, and it is sixty days out.

Your first instinct says config change. Swap the string, redeploy, done.

Then you start looking. The prompt was tuned against that snapshot. The eval baseline was measured on it. The vector index was built with an embedding model from the same family. The fine-tune sits on a base that goes with it.

Model retirement is not a version bump. It is a migration with a hard deadline, and the deadline belongs to your vendor.

This piece walks those sixty days in order, from notice to cutover, and names what model retirement breaks at each stage.

Key Takeaways

• The clock is short and it is not yours. Anthropic runs a fixed 60-day window from deprecation to retirement. Opus 4.1 was deprecated on 5 June 2026 and retired on 5 August.
• Nothing fails loudly. The API returns 200, latency holds, throughput holds, and the behavioural regression ships anyway.
• Embeddings are the worst case. A retired embedding model means re-embedding the whole corpus, and a dimension or distance-metric mismatch silently ruins ranking.
• Fine-tunes retire with their base. OpenAI is shutting down fine-tuned GPT-3.5 and GPT-4 variants on 23 October 2026, and Cohere has already made older fine-tunes inaccessible.
• Auto-upgrade can move you before any retirement date. Azure deployments set to update to the default version switch roughly two weeks after a new default publishes.
• Sometimes there is no replacement. OpenAI’s deprecation table lists a dash against the Videos API, which means choosing a vendor, not swapping an identifier.

---

Quick Navigation

---

Why Model Retirement Is Not a Version Bump

A library upgrade breaks loudly. Types stop matching, tests go red, the build fails. You fix it before anything ships.

Model retirement breaks quietly. The new snapshot takes the same request, returns valid JSON, and answers in the same voice.

That is the trap. Your dashboards watch error rate, latency and throughput. A model retirement swap can leave all three flat while it rewires how the system behaves.

So the regression ships, then shows up later wearing a different face. Support tickets rise. A classifier drifts. An agent takes an extra tool call it never needed.

Model retirement also runs on someone else’s calendar. You are not choosing to upgrade. You are handed a date, and the date does not negotiate.

---

The Blast Radius: What Model Retirement Actually Touches

Before the runbook, the map. Most teams guess this table at about half its real size, which is why model retirement overruns.

Artefact	What model retirement does to it	How it fails
Prompts	Tuning was fitted to one snapshot	Quietly, in output quality
Eval baselines	Scores were measured on a model that no longer exists	Silently, as a lost reference point
Vector indexes	Built with an embedding model in the same lifecycle	Silently, as worse retrieval
Fine-tunes	Retired alongside their base model	Loudly, with an API error
Tool schemas	Calling behaviour and format shift between versions	Intermittently, under load
Audit records	Reference a model nobody can re-run	At the next audit
Cost model	Token spend and reasoning behaviour change	On the invoice

Note the third column. Four of the seven fail with no error at all. That silence is why model retirement eats more calendar time than anyone budgets.

---

Day 0: The Model Retirement Notice Nobody Reads

The first model retirement problem is delivery. Notices go to whoever is on the account, not to whoever owns the code.

Azure notifies the subscription roles: owner, contributor, reader and the monitoring roles. Whether that list includes the engineer who wrote the prompt is down to your tenant hygiene.

Model retirement windows vary more than people expect. Anthropic commits to at least 60 days for a public model, with a fixed gap from deprecation to shutdown.

Azure notifies at 60 days, at 30 days, and at retirement, with at least 60 days of notice for generally available models and only 14 days before a preview version upgrade.

OpenAI runs longer on its main line. Its June 2026 notice set a December 2026 shutdown for the GPT-5 and o3 snapshots, roughly six months out.

One detail hides inside the date itself. Azure runs retirements on a rolling basis, region by region, so two deployments of the same model can behave differently for part of the window.

What to do on day zero. Put the date in your release calendar, name an owner, and check the notice actually reached that person. Model retirement nobody owns gets found in week seven.

---

Week 1: The Inventory Model Retirement Forces on You

You cannot plan a model retirement until you know where the string lives. It is almost never in one place.

Grep the model ID across app code, prompt templates, eval configs, infra code, notebooks, cron jobs and vendor dashboards. Then grep the aliases too.

Aliases deserve their own line, because they fail the other way. An alias never errors on model retirement. It just starts pointing somewhere else, which is worse than a break you can see.

Azure makes this concrete. A deployment set to update when a new default arrives moves about two weeks after that default publishes, not on the retirement date.

So model retirement can move you early, on a schedule you were not watching. Pinning to a dated snapshot trades that surprise for a date you control.

Check the replacement column while you are there. Most model retirement notices name a successor, and the ones that do not are a different project entirely.

One inventory item teams forget. List every artefact the old model produced that you still lean on: embeddings, cached completions, synthetic training data, labelled eval sets.

---

Weeks 2 to 4: Where Model Retirement Actually Breaks Things

This stretch decides whether you make the date. Five model retirement failure classes, roughly in the order they eat time.

Prompts Tuned to a Snapshot

Every production prompt carries fitting. Someone added a line because the old model rambled, or cut one because it refused too much.

That fitting does not carry over. A newer model may need less scaffolding, or may react badly to lines written around a quirk it no longer has. Model retirement resets the tuning, not just the ID.

Reasoning models sharpen this. Vendor migration guides now read as “rewrite the prompt”, not “reuse the prompt”.

Evals That Lose Their Baseline

Here is the circular problem in every model retirement. You want to prove the new model is no worse, and the proof rests on scores measured against a model about to vanish.

Re-run your full eval suite on the outgoing snapshot before it shuts down. Store the outputs, not just the aggregate numbers.

Those stored outputs are the only comparison you will ever have. After the shutdown date you cannot rebuild the baseline, and model retirement has quietly taken your reference point.

The Embedding Trap in Model Retirement

This is the expensive one, and the one model retirement plans miss until late.

If your index was built with an embedding model that is retiring, you cannot mix old and new vectors. The whole corpus needs re-embedding. That is compute, calendar time and database write throughput.

Worse, matching dimensions do not mean the models match. Models differ in distance metric and scaling, so an index set for cosine similarity holding vectors meant for dot product ranks wrongly while looking healthy.

The safe model retirement pattern is a dual index. Build the second one beside the first, route each query to model and index together, compare on a labelled set, then cut over. Keep the old index as rollback for a week.

Fine-Tunes That Retire With Their Base

A fine-tune is not an asset you fully own. It is an adapter on a base model, and model retirement usually takes both.

OpenAI’s table lists shutdowns for fine-tuned GPT-3.5 and GPT-4 variants on 23 October 2026. It names replacement base models rather than migrating anything for you.

Cohere went further and stated plainly that previously fine-tuned models would no longer be accessible once fine-tuning for those bases was retired.

Plan a re-train, not a port. Keep training data, hyperparameters and eval scores versioned together, because model retirement will ask for all three.

This stretch decides whether you make the date. Five model retirement failure classes, roughly in the order they eat time.

Tool Calls and Structured Output

Agents have a model retirement failure mode the rest do not. Tool-calling behavior shifts between versions in ways that are hard to write a test for.

The new model may call a tool the old one never touched, call it in a new order, or pass a slightly different argument. Everything validates. The path changes.

Watch for API changes riding alongside model retirement. When OpenAI sunset the Assistants API, threads became conversations and runs became responses, so the request shape moved, not just the ID.

Agents have a model retirement failure mode the rest do not. Tool-calling behavior shifts between versions in ways that are hard to write a test for.

The new model may call a tool the old one never touched, call it in a new order, or pass a slightly different argument. Everything validates. The path changes.

Watch for API changes riding alongside model retirement. When OpenAI sunset the Assistants API, threads became conversations and runs became responses, so the request shape moved, not just the ID.

---

Weeks 5 to 7: Running Both Models Through Model Retirement

Offline evals catch the obvious regressions. Production catches the rest, so model retirement needs both.

Shadow traffic is the cheapest insurance available during model retirement. Send a slice of real requests to both models, log both outputs, and compare without serving the new one to anyone.

Compare the right things. Output quality on your labelled set, yes, but also token spend per request, p95 latency, refusal rate, and for agents, tool-call counts and path length.

Then ramp rather than flip. One percent, five, twenty five, with a rollback that stays valid until the old snapshot actually shuts down.

Keep one number in view throughout. A model that scores identically while spending forty percent more output tokens is not a neutral swap, and that arithmetic sits in our piece on what inference actually costs per token.

Also re-run your safety testing. A model version change is one of the standard triggers for a fresh adversarial pass, which we covered in the hidden flaws in a passing red-team test.

---

The Cutover: What Model Retirement Leaves Behind

The switch is the easy part of model retirement. The residue is not.

Start with repeatability. You can no longer regenerate any output the old snapshot made. That matters when a customer disputes a decision, or a regulator asks how it was produced.

That is a records problem more than a technical one. Model retirement means your logs must already hold the snapshot ID, the prompt version and the parameters, because the model will not be there to ask. We went deeper on that in our guide to AI compliance evidence.

Then come the dependencies you never called dependencies. Cached completions from the old model. Synthetic data used to train a smaller one. Labelled sets where the old model did the labeling.

None of those break on the shutdown date. Model retirement just turns them into relics of a system you can no longer rebuild.

One harder case deserves naming. Sometimes model retirement offers no replacement at all. OpenAI’s table carries a dash against the Videos API entry, which means finding another vendor rather than editing a string.

---

Building So the Next Model Retirement Costs Less

There will be a next model retirement, usually within a year. Five changes make it routine instead of disruptive.

1. Pin snapshots in production. Aliases are for experiments. A dated identifier means model retirement arrives as a deadline you can see rather than a behavior change you cannot.
2. Put the model behind one boundary. One config value, one client wrapper, one place to edit. If the ID sits in forty files, model retirement is forty times harder than it needs to be.
3. Version the eval set like code. Same repository, same review process, and a rule that every migration re-runs the outgoing model before shutdown.
4. Derive index names from the embedding config. Model, dimensions, distance metric and chunk version in one config that builds the index name, so a mismatch cannot happen quietly.
5. Log the snapshot with every response. Not the family name, the dated identifier. This is the single cheapest habit on the list and the one that saves you in an audit.

Then diary a quarterly check of your vendors’ deprecation pages. The model retirement email is unreliable. The page is not.

---

The Verdict: Model Retirement Is a Standing Cost

• Go back to that Friday email and the sixty-day clock. Nothing in your system was broken when it arrived.
• What changed is that a part you do not control picked up an expiry date, and every artefact built on it inherited the same one.
• Treat model retirement as a recurring line item rather than an incident. Somewhere between two and four times a year, an engineer spends a few weeks on migration, and the budget should say so.
• The line item is smaller than it looks, too. An engineer for three weeks, twice a year, is cheaper than one rushed cutover that ships a quiet regression to customers.
• Teams that find model retirement painless are not lucky. They pinned their snapshots, versioned their evals, and logged which model produced what.
• The teams that find it brutal usually discover in week seven that the vector index was built with something that retires on the same day.

---

Frequently Asked Questions

---

Keep reading

Here are the latest posts from the blog.