What breaks when a model is retired

Model retirement is the most predictable outage in this industry and the one teams are least prepared for. The email arrives, it gives you ninety days, and it is written as though the change is a string replacement. Then you go and look at what actually depends on that string.

• Prompts. Tuned against one model's instruction-following quirks, its tolerance for long system messages, its habit of over-hedging or under-hedging.
• Output contracts. Anything downstream that parses the response — a JSON schema the old model honoured reliably and the new one honours differently.
• Evaluation baselines. Your regression suite's pass thresholds were calibrated on the retiring model. They are now unlabelled numbers.
• Caching keys. Prompt caching is keyed on an exact prefix under a specific model. Change the model and your cache hit rate goes to zero, which changes your cost profile before it changes anything else.
• Token budgets. Context window and max output differ. Code that assumed 200K and got 128K fails in production, not in tests.
• Latency assumptions. Timeouts and streaming buffers tuned for one model's tokens-per-second behaviour.
• Price. Your unit economics were computed against the old rate card.

Seven categories, and only the first is what the deprecation notice is about. This is the shape of the problem the industry has named vendor lock-in, but lock-in is a slightly misleading word: nobody locked you in. You made a series of reasonable local decisions and each one attached a piece of your system to a specific model version.

Note that none of these are hard problems. Re-tuning a prompt is a day. Re-baselining an eval suite is a week. The problem is that a retirement notice arrives on the provider's schedule, not yours, and the work lands on top of whatever you were doing. As one practitioner put it: models get retired, limits change, and outages happen — and if your agent is tightly tied to one provider, those changes force rushed work at the worst possible time.

Nobody is bad at migrating models. Everybody is bad at migrating models in the same sprint as a launch.

The mitigation is old and boring: put a name you control in front of a name you do not. Instead of writing a provider's model identifier into your application, write an alias, and resolve the alias at the routing layer. The application asks for the role it needs. The routing layer decides which concrete model fills that role today.

// Application code names a role, not a vendor SKU.
await router.chat.completions.create({
  model: "wuraw/summarizer",       // alias, resolved at route time
  messages,
});

// Alias definition lives in config, versioned, reviewable, revertible.
{
  "wuraw/summarizer": {
    "primary":  "claude-haiku-4-5",
    "fallback": ["gpt-5.6-luna", "deepseek-v4-flash"],
    "policy":   "cost",
    "pin":      "2026-06-27"           // freeze resolution for reproducibility
  }
}

The pin field is the part people skip and then miss. An alias that silently re-resolves is great for availability and terrible for reproducibility — you cannot debug last Tuesday's bad output if you do not know which model produced it. Pin the alias, record the resolved model on every response, and change the pin as a deliberate act with a diff attached.

The rehearsal is cheap. Take one percent of production traffic, shadow it to the candidate model, and diff the outputs against your eval suite continuously rather than in a panic. You will find the output-contract drift in week one instead of week twelve, and you will have a real number for the cost delta rather than an estimate from a rate card.

This is what a router is for, and it is worth being precise about the claim. Routing does not make model migration free — the prompts still need work and the evals still need re-baselining. What it does is decouple the deadline from the deploy. When the retirement date lands, the change is a config edit against an alias you have already tested, rather than a code change against every call site you can find with grep.

In 2026 most frontier models are good enough that architecture and operations decide outcomes more than model choice does. Retirement handling is squarely in that category. It is not glamorous, it never appears in a demo, and it is the difference between a calendar entry and a weekend.