Twenty Days or Six Months: How Much Time You Get When a Model Is Retired

What happened in the past two weeks

Three announcements, each on the vendor's own deprecation page, none of which got press coverage in Hungarian or Spanish:

• 11 September. OpenAI marked gpt-5.4-cyber for deprecation. The shutdown date is 1 October 2026. That is twenty days from the announcement. The successor is gpt-5.6-cyber.
• 24 September. The Videos API and the Sora 2 model variants shut down. This was announced back on 24 March, so here the notice was six months — but no successor model is named. The browser and mobile experiences had already been discontinued on 26 April.
• 26 August. Four transcription models (whisper-1, gpt-4o-transcribe, gpt-4o-mini-transcribe, gpt-4o-transcribe-diarize) were deprecated, with shutdown on 26 February 2027. Here you get six months, and there is a named successor.

The pattern is not "things get discontinued sometimes". The pattern is that the notice period swings between twenty days and six months at the same provider, and there is no way to predict which one you will get.

SEP 24  Videos API + Sora 2 shut down
        no successor model named
        announced Mar 24  -> 6 months

OCT 1   gpt-5.4-cyber shuts down
        successor: gpt-5.6-cyber
        announced Sep 11 -> 20 DAYS

NOV 2   grok-imagine-image-quality
        redirected, quality=low
        announced Sep 2  -> 61 days

DEC 11  gpt-5 and o3 snapshots go
        successor: gpt-5.6 variants
        announced Jun 11 -> 6 months

What six providers commit to in writing

This is the backbone of the article. Every row comes from the vendor's own documentation, as of 12 September 2026:

The lesson is not which provider is "better". It is that the notice period is not an industry convention but a separate commitment per provider and per tier (GA or preview) — and if you have not read it, you do not know how much time you will get.

Three traps worse than the notice period

1. The model does not shut down, it changes under you. This is the harder case, because you get no error. Microsoft Foundry Standard deployments are upgraded automatically at retirement, region by region. Behind Google's latest alias a new version appears with two weeks' notice. With the Grok image-quality variant, requests are not rejected but redirected to 2.0 with quality=low, at a lower per-image price. In all three cases the code keeps running — it just returns something else.

2. Reserved capacity does not upgrade itself. In the same place where a Standard deployment moves over automatically, a Provisioned deployment is not upgraded: that has to be migrated by hand, and after the deadline every request returns 410 Gone. In other words, whoever paid for guaranteed capacity gets more work, not less. And for a preview model there is no third option: it is either force-upgraded or terminated — staying put is not available.

3. It is not only the model that can go, but the data. For the video service shutting down on 24 September, the vendor's own help page says that after the export window closes it will permanently delete any data associated with your use of the service, and it recommends exporting as soon as possible. If months of work have piled up inside one tool, that is the deadline with no way back.

What to do now

Four steps, a few hours in total:

1. List which model identifiers appear in your systems. Not just in code: in automations, in no-code flows, in calls embedded in spreadsheets, and in the settings of the tools your team uses. If you do not know which model something runs on, you will not notice when it is retired.
2. Use versioned identifiers rather than a latest-type alias — at least where output stability matters. The trade-off is real: you have to step a versioned identifier yourself, but it will not change under you after one email. An alias is convenient, and can flip in two weeks.
3. Nominate a successor for every model before you need one. Knowing the vendor's recommended replacement is not enough: you also need to know how it performs on your task. A two-week comparison does that, and Run a Two-Week Model Bake-Off sets out the recipe in detail.
4. Open your provider's deprecation page and put it in the calendar. The only date that really matters is your own: when the migration has to be finished on your side. The vendor's deadline is not your deadline.

Two structural moves reduce the exposure. A model router puts several providers' models behind one key, which turns switching into a configuration change instead of a development project. And with open-weight models what you have downloaded cannot be retired from under you — the weights are with you. Neither is free: the router is one more intermediary, and local inference asks for hardware and operations. (More: monthly Care — we migrate before a model is retired.)

How to catch it in time

Here is the systemic problem: there is no RSS feed under the deprecation pages of any major provider. Not OpenAI, not Anthropic, not Google, not Microsoft, not AWS. The vendor blog feed carries the announcements; retirements do not appear there — and the daily AI newsletters skip this kind of news routinely, because it is not exciting enough.

That leaves two methods. Either five minutes a week in the calendar, when you click through the two or three deprecation pages that concern you. Or automated page monitoring: a change-detection service is enough for this even on a free tier, and it also shows you the content of the change rather than merely the fact of it. We found one consolidated exception: the Microsoft Foundry retirement schedule lists ten providers' models with dates on a single page — a useful overview even if you are not on Azure.

Common misconceptions

• "They'll send an email." Notification typically reaches whoever has active usage on that model, at the address registered as the developer or billing contact — not necessarily the person who operates the process.
• "The big providers all give six months." The same provider gave both twenty days and six months within one month. The fifteen-day commitment is not theoretical either: it is published.
• "A preview model is fine for production." Two of them commit to two and thirty days' notice respectively, and a preview deployment has no "I'll stay on the old one" option. A live process running on a preview model is not cost optimisation, it is exposure.
• "It doesn't affect me, I don't use an API." The models behind the consumer interfaces get swapped too; you just do not get a 410 about it — only a different output.
• "If it's retired, the successor must be better." The successor is different. Your prompts, your temperature setting and the parsing built on the output format were all tuned to the old one. That is why the comparison belongs before the switch, not after.

What to take away

Model retirement is not a fault but the normal running of the service: where an 18-month lifecycle is published, every model is replaced within a year and a half — and that is the stated maximum, not the average. Three things are within your control: knowing which model runs what, using versioned identifiers where stability matters, and looking at the deprecation page that concerns you once a week. The rest is the provider's business — and its notice period is worth reading before your process comes to depend on it.