8 min read Model Lifecycle

Your provider's minimum notice period has become its actual schedule

Your provider's minimum notice period has become its actual schedule

On September 24, 2026, OpenAI's Videos API and the entire sora-2 family stop responding. Four days later, on September 28, gpt-3.5-turbo-instruct, babbage-002, davinci-002 and gpt-3.5-turbo-1106 go the same way. Both deadlines fall twenty-three and twenty-seven days from the day you read this, and they were announced on March 24, 2026 and September 26, 2025 respectively on OpenAI's Deprecations page. Nobody was ambushed. Plenty of teams will still be caught out.

The usual reading of deprecation policies is reassuring. OpenAI commits to at least six months for its generally available models, Anthropic to at least sixty days for publicly released ones. A floor, then, with the implicit assumption that practice will be more generous. Both public histories say otherwise. Across OpenAI's last five GA model retirement announcements, the effective notice was 182, 183, 184, 184 and 184 days. Across Anthropic's last four, 60, 61, 62 and 62 days. The floor is not a minimum guarantee the provider comfortably clears, it is the train's departure time.

The August 28 article on qualifying an anonymous provider covered what to verify before the first call goes out. This one covers the end of life of that same integration: what breaks afterwards, when the provider retires or replaces what your code calls. What follows sets out why notice varies by a factor of three between providers and by a factor of two inside a single catalog, why it is not always a model that breaks you, and what a migration actually costs when measured in production.

Calendar grid where a few orange cells mark imminent retirement deadlines
Retirement notice is not a property of the market, it is a clause each provider writes for itself.

Three notice regimes for a single architectural decision

OpenAI publishes three distinct commitments, and the distinction carries more weight than most teams assume. At least six months for generally available models. At least three months for specialized variants of those same models, a category covering chat variants such as gpt-5.1-chat-latest, Codex variants such as gpt-5.3-codex and deep research variants such as o3-deep-research. And for preview models, identifiable by the word preview in the name, notice that can drop to two weeks, with an explicit recommendation in the documentation: do not use them for business-critical production workloads unless you can migrate on short notice.

Anthropic runs a single regime, at least sixty days for any publicly released model. Working through the full history on its deprecations page, nineteen models across nine announcements since September 2024, the median is 63 days. The spread is instructive: 189 and 181 days for the 2025 announcements, then 60, 61, 62 and 62 days for the four most recent. Notice has tightened onto the contractual floor as release cadence accelerated.

The vocabulary of the lifecycle

Dated snapshot: a model identifier frozen on a specific version, such as claude-opus-4-5-20251101 or gpt-5-2025-08-07. The behavior behind that identifier no longer changes.

Floating alias: an undated identifier such as gpt-5.1-chat-latest, pointing at a version the provider can move without notification and without a name change.

Deprecated: the model still works but is no longer recommended, and a retirement date is assigned to it. Retired or shut down: calls fail, with no degraded mode and no grace period.

Specialized variant: a version of a GA model tuned for a specific use, code, chat or research. At OpenAI this category carries three months' notice rather than six.

The variant that looked like the better technical choice halves your notice

On April 22, 2026, OpenAI announced the July 23 retirement of gpt-5-codex, gpt-5.1-codex, gpt-5.1-codex-max, gpt-5.1-codex-mini, gpt-5.2-codex, gpt-5-chat-latest, gpt-5.1-chat-latest, along with the deep research variants o3-deep-research and o4-mini-deep-research. Effective notice: 92 days. On May 8, gpt-5.2-chat-latest and gpt-5.3-chat-latest got 94 days. That same month, GA models in the GPT-5 and o3 family were given 183.

A team that standardized its coding agents on a Codex variant therefore had three months where a team that stayed on the GA snapshot had six, for a decision that looked, when it was made, like the more careful technical call. This is what architecture reviews miss most often: specializing a model is a service-level decision as much as a quality one.

The second trap is floating aliases. A -latest identifier often gets adopted because it looks neutral, a way to stay current without thinking about it. OpenAI's history shows those aliases have fared no better than anything else: chatgpt-4o-latest, codex-mini-latest, gpt-5-chat-latest, gpt-5.1-chat-latest, gpt-5.2-chat-latest and gpt-5.3-chat-latest have all been retired, and all on the short three-month regime. An alias does not shield you from retirement, it only removes the signal that would have warned you about a behavior change in the meantime.

Bars comparing observed retirement notice, from 184 days down to 14 days depending on model type and provider
Three notice regimes at one provider and a single regime at the other, for the same calling decision.

What breaks is not always a model

Two categories of breakage escape an inventory built around model identifiers entirely.

The first is parameter deprecation. At Anthropic, temperature, top_p and top_k return a 400 error when set to a non-default value on Claude Opus 4.7 and later models. The Python SDK from version 1.0 onward removed them from its request types, so a call that passes them raises a TypeError. No model was retired in that story: a version upgrade breaks the code, and it appears on no shutdown date.

The second is the deprecation of tooling products. At OpenAI, the v1/prompts API and reusable prompt objects shut down on November 30, 2026, the Evals platform goes read-only on October 31 and shuts down on November 30, and Agent Builder shuts down on November 30 as well. Teams that externalized their prompts into the provider's reusable prompt objects, or their evaluation harness into its evals platform, are discovering that the layer meant to secure their model migrations is itself on a countdown. The end-of-life calendar covers not only what you call, but what you measure with.

The Assistants API case is worth citing for the opposite reason. Announced on August 26, 2025 and shut down on August 26, 2026, it carried 365 days of notice, and the shutdown came with no degraded mode and no grace period. A full year of notice did not prevent integrations from falling over, because migrating to the Responses and Conversations APIs meant reshaping domain objects, not changing a string.

What a migration actually costs, measured in production

A team at Verint published a case study on arXiv in late April 2026 covering the migration of a production question-answering system serving 5.3 million interactions per month across six regions. Their starting observation is blunt: the proprietary model deprecation and migration cycle repeats roughly every twelve months and hits every product built on the retired model, with migration windows short enough to make manual evaluation prohibitively expensive.

Their most useful result is the one they did not expect. They tested three strategies for adapting the prompt to the new model: manual adaptation following the provider's recommended practices, the hosting platform's automatic prompt optimizer, and MIPROv2 through DSPy. None produced a prompt clearly better than the original. The DSPy-optimized prompts did reduce errors, but by sharply increasing the rate at which the system declined to answer, and the gain did not reproduce on an out-of-distribution test set. Their conclusion: the baseline prompt generalizes surprisingly well across models.

Which means the expensive part of a migration is not rewriting the prompt, contrary to what most effort estimates assume. The expensive part is the evaluation apparatus that tells you whether something broke. In the field, teams that have already been through two or three retirement cycles no longer budget migration by the number of models to swap, they budget it by the number of regression sets to maintain. That is also why the same migration costs four times more in one organization than in another at comparable technical scope.

What to start this week

Search your code and configuration for any undated model identifier. A grep for -latest, for model names with no version suffix, and for the word preview produces the first list. Every occurrence on a production path is an integration whose real version and retirement date you do not know.

Build the inventory you are missing: a four-column table with calling service, pinned model identifier, provider-announced retirement date, and owner on the team. The two deprecation pages worth watching are public and dated, and each takes twenty minutes to read.

Provision the migration budget against the shortest notice period in your estate, not the longest. If a single service runs on a specialized variant or a preview model, your real reaction window is three months or two weeks, whatever regime covers everything else.

Check what your evaluation harness rests on. If your regression sets, prompts or evals live inside a provider product rather than in your own repository, check its end-of-life date before you check your models'. The tool that is supposed to de-risk the migration should not expire during it.

Treat the budget line as recurring. Two to three migrations per year per provider is the observed regime today. That is no longer an incident to absorb but a maintenance load to plan, on the same footing as your database version upgrades.

Conclusion

Debate about model choice almost always turns on quality, latency and price per million tokens. Retirement notice appears in no comparison table, even though it sets how often your teams will redo the work. Between 184 days for a GA model at one provider, 92 days for a specialized variant at the same one, and 61 days at the other, the same architectural decision commits you to a maintenance rhythm that varies threefold. The information is public, dated and free. It belongs in the selection grid before you go to production, not three weeks before the lights go out.

Sources: As of August 2026

Godwin AVODAGBE