You build a product on a model. It works, your users are happy, you move on. Twelve months later, an email informs you that this model will be retired from service on a given date. Your settings, your examples, your calibration: all of it has to be redone. This isn't an incident—it's how the industry normally operates.
A new wave of retirements of older models is underway at several providers. It's a good opportunity to explain a mechanism that consistently catches those building with these tools off guard.
Why providers retire their models
Three reasons, all legitimate from their point of view.
The cost of serving. Keeping an older model in production ties up memory and compute that could go to newer models. In a context of component shortages, this trade-off becomes more pressing.
Security. Older models haven't benefited from recent work on guardrails. Keeping them accessible means keeping versions that are easier to misuse.
Simplification. Every model maintained multiplies the support and documentation surface.
What this actually breaks
The replacement is never neutral, and that's the point teams underestimate.
Prompts don't carry over. An instruction finely tuned for one model produces different results on another. All the calibration work has to be redone.
Output formats change. If your code expects a specific structure, a new model may produce it slightly differently, which breaks downstream processing.
Costs shift. A new model may consume more tokens for the same work, as we showed regarding the tokenizer change. Your budget changes without the listed price moving.
Behaviour drifts. A newer model may be more cautious on certain topics, causing refusals where your product used to work.
We covered an API migration with a hard deadline, where two model identifiers disappeared at a precise time. The trap wasn't the outage—easy to detect—but the silent degradation: the code kept working by pointing at a less capable model, with nothing signalling the drop in quality. An outage is visible immediately; a degradation is discovered three weeks later.
How to protect yourself
Pin your versions. Use specific model identifiers rather than generic aliases. You'll know exactly what you're calling, and a change won't happen without your knowledge.
Build a reference test set. Around twenty representative cases, with expected outputs. At each migration, you replay them and measure the gap. Without this, you'll never know whether the new model is better or worse for your use case.
Isolate the model call. An abstraction layer in your code lets you switch providers without rewriting the application. It's the advice we repeat in our selection guide.
Watch for deprecation announcements. Providers give notice, often several months in advance. Someone just has to read them.
What to take away
There's a difference in kind between building on software and building on a model. Software you own a version of keeps working indefinitely. A model accessed via API exists only as long as someone else decides to maintain it.
That's a concrete argument, and often the most convincing one, in favour of open-weight models: a file you've downloaded doesn't retire. For critical, stable use, that guarantee can be worth more than a few points of performance.