Two models we offered stopped existing this month. Not deprecated with a sunset date, not replaced with a migration guide. The IDs simply stopped resolving, and every request using them started failing. If you build on AI APIs, this will happen to you, and the industry has quietly normalised it.
What happened
Doing a routine audit against the live catalogue, we checked all 46 model IDs we offer. Two came back missing: Alibaba's undated qwen3.8-max and Mistral's mistral-large-2512. Both had been listed and working. Both were gone.
Nobody had emailed us. Nothing in our monitoring fired, because a model that no longer exists does not throw a distinctive error; it returns a generic failure that looks like any other bad request. The only reason we caught it was that the audit compares our list against the catalogue rather than trusting it.
The pattern differed between the two. Alibaba appears to have moved to dated snapshots: the undated alias went away and qwen3.8-max-0902 exists in its place, same price, same capabilities. Mistral's Large 3 was withdrawn with the current flagship being Medium 3.5, a different model at a different price.
Why this keeps happening
Providers retire models for reasons that are entirely rational from where they sit. Serving an old model costs GPU capacity that a newer one would use better. Undated aliases are a support burden because nobody can tell which weights they got. A model that underperforms its successor makes the brand look worse every day it stays up.
What is missing is the deprecation discipline that other infrastructure has. There is no widely observed convention for how long an AI model stays available, no standard sunset period, and no reliable notification channel. Compare that to a cloud provider retiring an instance type, where you get months of warning and repeated emails.
The economics explain it. Model generations arrive every few months, and the previous generation becomes unattractive to serve almost immediately. A twelve-month deprecation window would mean supporting three or four generations at once.
What to actually do about it
Audit against the live catalogue on a schedule
The single highest-value habit. Fetch the provider's model list, compare it against every ID you reference, and alert on anything missing. This is a handful of lines of code and it turns a silent outage into a ticket. It is how we caught both of ours.
Map retired IDs to replacements instead of erroring
When a model goes away, users who had it selected should land on the closest live equivalent rather than a failure. We keep an alias table that maps every retired ID to a current one, so a saved preference or an old chat keeps working.
One trap worth naming: if your alias table is a single lookup rather than a recursive one, an alias pointing at a model that later gets retired resolves to a dead ID. Every time you retire something, re-point the aliases that targeted it. We check this automatically now, having nearly shipped exactly that bug.
Prefer dated snapshots where they exist
An undated alias like model-latest is convenient and unstable: the weights change under you without notice, and the alias itself can be withdrawn, which is precisely what happened to Qwen 3.8 Max. A dated snapshot changes only when you change it.
Do not pin your evaluations to a single model
If your quality bar is defined entirely by one model's behaviour, its retirement is a crisis. If you routinely run the same prompts across several models, you already know which alternatives are acceptable, and switching is a configuration change rather than a project.
The broader point
Building on a single model from a single vendor means accepting that vendor's retirement schedule as your own. That is a real dependency, and it is usually invisible until the day it is not.
This is a large part of why Deepest is built around several models rather than one. Not mainly for the comparison, though that is the visible benefit, but because a single provider's decision should not be able to take your workflow down. When those two models vanished, our users did not notice: the IDs re-pointed at live equivalents and the answers kept arriving.
Frequently Asked Questions
How much warning do providers usually give?
It varies enormously and we would not want to quote a typical figure, because the two cases we hit this month came with none that reached us. Assume you may get no warning, build the audit, and treat any notice you do receive as a bonus.
Is a dated snapshot always safer than an alias?
Safer against silent change, yes, since the weights behind a dated ID do not move. It is not immune to retirement: a dated snapshot can still be withdrawn eventually. The advantage is that it fails loudly at a time you can plan for, rather than shifting behaviour underneath a passing test suite.
What should I do the day a model I depend on disappears?
Route to the nearest equivalent immediately to stop the bleeding, then evaluate properly rather than trusting that the replacement behaves the same. Same vendor and a similar name does not mean similar output; Mistral Large 3 and Medium 3.5 are different models at different prices, not a rename.
