Guides · ← All guides
What Happens When an AI Model Is Deprecated? The Full Lifecycle
Last updated: October 13, 2026 · 9 min read
By the Ingenious AI team
Every production AI feature rests on a model ID — a string like gpt-4-0613 or claude-3-sonnet-20240229 — and every one of those IDs has an expiration date. Providers retire models constantly: older snapshots get consolidated, pricing tiers get reorganized, architectures get superseded. If you have never watched a deprecation unfold end to end, the mechanics will surprise you. The surprise is rarely pleasant.
Here is the part that trips people up first: "deprecated" and "retired" are not the same thing. OpenAI's deprecations page draws the line explicitly — when a model is deprecated it immediately becomes deprecated, and it also gets a shutdown date; at the time of the shut down, the model or endpoint will no longer be accessible. Deprecated means the clock is running. Retired means the endpoint is gone. Most teams only learn the vocabulary when they are already on the clock.
The four stages of a deprecation
Most provider retirements follow the same pattern, whether the announcement arrives as a blog post, a changelog entry, or a quiet line in the API docs:
1. The announcement
Somewhere — a developer blog, a status page, an email to API customers — the provider names the model, gives the retirement date, and names the recommended replacement. Announcement windows vary wildly. Some providers give six months or more. Others have given as little as a few weeks.
The announcement is the only stage where you are fully in control, and it is the stage most teams miss, because nobody was watching that feed. Consider how the October 23, 2026 OpenAI wave was announced: on April 22, 2026, under the heading "Legacy GPT model snapshots," on the developer deprecations page. Six months of warning. Plenty of time — for the teams that saw it. The deprecation email goes to the account that holds the API key, which is sometimes an engineer who left the company two jobs ago. We keep coming back to this detail because it is where most failures actually start: not in the code, in the inbox.
2. The sunset window
Between announcement and shutdown, the model still works. This is your migration window. Smart teams treat it as a deadline with a buffer: finish migration weeks before the final date, not the night before.
Two things worth knowing about the window. First, providers sometimes freeze the model — no more updates — and occasionally change pricing to push users off. The economics of the old model can turn hostile before the endpoint disappears. Second, the window is the cheapest time to make mistakes. An eval that fails in week two is a finding. An eval that fails on shutdown day is an incident.
3. The brownout period
Some providers run temporary outages on the deprecated model in the days before shutdown — short "brownouts" designed to surface any remaining traffic. The pattern is deliberate: force the stragglers to notice before the real date.
Brownouts are a gift disguised as an outage, if your monitoring is good enough to interpret them. If your error tracker catches a burst of model failures that resolves itself within hours, check the deprecation calendar before you blame your own code. A clean little cluster of model_not_found errors on a Tuesday morning is the provider tapping you on the shoulder. Say thanks and migrate.
4. Shutdown day
The endpoint stops responding. Depending on the provider, requests return a hard error, or — the nastier variant — the model ID silently maps to a different model, and your outputs change shape without any error to catch.
When OpenAI-style APIs kill a model, the response looks roughly like this: HTTP 404, a JSON body with "code": "model_not_found", and a message along the lines of "the model does not exist." There is no fallback, no automatic substitution, no helpful redirect to the replacement. Your code either handles that error or your users see a broken feature. Anthropic's deprecation docs say the same thing in plain language: requests to retired models will fail. Loud. Immediate. No grace.
What actually breaks
Model shutdowns break more than the obvious API call. A real inventory of the damage usually includes:
- Hard-coded model IDs scattered across services, scripts, and cron jobs — the ones nobody remembers pinning. The .env entry from 2024. The serverless function config someone set in the console and never committed.
- Framework defaults you never chose. LangChain and LlamaIndex have long defaulted to gpt-3.5-turbo when no model is specified. Code that never mentions the model at all still breaks when the default retires. Search your dependency configs, not just your source tree.
- Prompt behavior changes even when you migrate "cleanly." The replacement model has different instruction-following quirks, different verbosity, different refusal boundaries. Same prompt, different personality. The prompts your team tuned by trial and error against the old model are calibrated to a brain that no longer exists.
- Embeddings and vector stores. Switching embedding models invalidates existing embeddings. You cannot swap text-embedding-ada-002 for a new model and keep your old vectors — they live in different mathematical spaces. Re-embedding an entire corpus is a project, not a config change. Budget the compute and run both indexes in parallel during the transition.
- Fine-tunes. Fine-tuned variants are tied to their base model. OpenAI's rule is explicit: inference on fine-tuned models keeps working only until the base model is deprecated. When the base retires, the fine-tune goes with it, and you retrain — or re-engineer the prompt.
- Cost models. Replacement models are priced differently. Token prices, context-window usage, and output verbosity all move the number. A migration that "works" can still blow up your unit economics if you skip the pricing math. Run a week of real traffic numbers before the deadline, not after.
A scenario to make it concrete
Picture a small SaaS team — entirely hypothetical, but the shape is one we've seen described again and again. They ship a support chatbot in early 2024, pinning gpt-4o-2024-05-13 because pinning was the responsible thing to do. Two years of quiet success. Nobody touches the model config because nothing is broken.
In April 2026, OpenAI posts the deprecation notice. The email goes to the founder's old address. The changelog entry sits in a feed nobody reads. The model keeps working — that is the cruel part of the sunset window; everything looks fine while the deadline approaches.
October 23 arrives. The bot starts returning 404s at 00:00 UTC. The on-call engineer, who joined in 2025, has never heard of the model ID in the config. It takes them four hours to find the pinned snapshot, another two to pick a substitute, and a weekend to discover that the new model answers support tickets in a noticeably different tone — the prompts were tuned against quirks the new model doesn't share. One deprecation, three distinct problems: the dead endpoint, the missing announcement, and the uncalibrated replacement. All three were preventable. None of them were prevented by anything that existed in their stack.
Why teams get caught
It is almost never ignorance. It is diffusion of responsibility: the model ID was pinned by someone who left, the changelog feed was on a Slack channel nobody reads, the "we'll migrate next quarter" note died in a backlog. Deprecation is a slow-motion incident, and slow-motion incidents lose to every urgent fire — until shutdown day converts them into a fast one.
There is also a quieter cause: the migration that "worked" was never verified. A team swaps the ID, runs three manual test prompts, ships. Two weeks later the support queue fills with complaints about a tone shift nobody measured. The endpoint migration took an hour; the behavior migration was never done.
FAQ
What is the difference between a deprecated and a retired AI model?
Deprecated means the provider has announced the model is going away and set a shutdown date — it still works until that date. Retired (shut down) means requests to it fail outright. OpenAI puts it plainly: at the time of the shut down, the model or endpoint will no longer be accessible.
What happens to API calls after a model is shut down?
Requests naming the retired model ID fail — typically with an HTTP 404 and a model_not_found error body. There is no automatic substitution; your code must catch the error and route to a replacement, or the feature breaks for users.
Can a deprecation break things other than API calls?
Yes. Embeddings produced by a retired model can't be compared against vectors from a new one, fine-tunes die with their base model, prompts tuned against the old model's quirks may misbehave on the replacement, and per-token pricing differences can change your unit economics.
The takeaway
A deprecation is a project with a hard external deadline, not a maintenance chore. The teams that survive them share three habits: an inventory of every model ID in production, a watched feed of provider announcements, and a standing migration playbook they can execute on demand. Build those before you need them — the next announcement is already on someone's roadmap.