In one week we received deprecation notices from four separate providers. One of them retired 32 models across two batches and stated plainly that no replacements would be offered. Another gave a single day of warning.
This is ordinary. Anyone who has pinned a model id in production has felt it. What is less ordinary is how easy it is to make the situation worse while trying to handle it responsibly.
The trap
One notice announced the end of GLM 4.7, Kimi K2.7, Kimi K2.6, Inkling and DeepSeek V4 Pro. Those are well-known models. The obvious move is to search the catalogue for those names and switch them off.
Doing that would have deactivated 96 active models across fourteen providers. The notice was from one vendor about its own hosted copies. Every other provider serving those same weights was unaffected and still working perfectly.
A model id is not a model. It is a model at a provider, and only one of those was being retired.
So retirements are recorded with a provider attached, and a test asserts that the same ids at other providers stay untouched. It sounds obvious written down. It is not obvious at 9am with a deadline in the email.
The second trap: whose deprecation is it?
The same batch included notices that GPT-4o would be retired on 1 October and Gemini 2.5 Flash on 16 October. Both came from a third-party agent platform retiring its own hosted copies. Neither OpenAI nor Google announced anything.
We reach those models directly, so acting on it would have removed 41 working models because somebody else stopped reselling them. Read the sender, not just the subject line.
Why a date, not a delete
A model announced for October still works in September, and pulling it early throws away service people are still paying for. Each retirement is stored with the date the provider switches it off, and applies itself once that date passes.
There is a less obvious reason it has to work this way. Catalogue sync rewrites every model's active flag from what the provider reports, so a manual deactivation survives exactly until the next sync. We learned that the hard way in August, when 78 models we had switched off quietly came back.
What this means if you build on Antbase
- •If you pin a provider-specific model id, you inherit that provider’s deprecation calendar. That is a real cost of pinning.
- •Virtual models (ant:auto, ant:coder, ant:reasoning, ant:free) name an intent rather than a model, so a retirement becomes a routing change instead of an outage in your code.
- •When a pinned model does disappear, you get a clear MODEL_NOT_FOUND rather than a silent fallback to something that behaves differently. We would rather you know.
None of this makes deprecations pleasant. It moves them from something that breaks your deploy to something that shows up in a changelog — which is roughly the whole argument for putting a router in front of thirty providers.
