The model we built on is being deprecated. What now?

On Friday, the model that launched the ChatGPT API stopped answering

At some point on Friday, 23 October 2026, gpt-3.5-turbo stopped answering. So did gpt-4, gpt-4-turbo, o1, o1-pro, o3-mini, o4-mini, gpt-4.1-nano, the original May 2024 gpt-4o, gpt-image-1, and every model fine-tuned on top of them. OpenAI had announced it six months earlier, emailed the people still using them, and switched them off on the day it said it would.[1]

Nothing unusual happened. That is the point of this page. A model being switched off is not an incident any more. It's how the platform works, and it happens every few weeks: Claude Sonnet 4.5 goes on 30 November, the original gpt-5 on 11 December, and the GPT-4o, GPT-4o mini and GPT-4.1 snapshots that a great many production apps still run on, on 14 January.[2][1]

We wanted to know how often it happens, how much warning you get, and what actually breaks. So we measured it four ways:

1. Lifespans. Every text model the OpenAI, Claude and Gemini APIs have retired or scheduled for retirement — 78 of them — from each provider's own deprecation page, with release dates read off the date in the model ID or from the launch.
2. Platforms. The same models' retirement dates on Azure and Amazon Bedrock, which set their own.[3][4]
3. Dependencies. We downloaded the latest release of 2,083 AI-related packages from npm and PyPI and parsed their code for hard-coded model IDs.
4. Migration. We ran one fixed test set, unchanged, across successive generations of the same model family, to see what an upgrade breaks.

The median model lived 15.7 months

Across all three APIs, the median retired model was switched off 15.7 months after it was released. OpenAI's ran longest, at a median of 18.2 months; Anthropic's 15.5; Google's 6.5, because most of what Gemini has retired so far were previews it never promised to keep.[5]

The tail matters as much as the middle. gpt-4-0613 lived for more than three years. The Codex variants of GPT-5.1 lasted eight months. gemini-3.1-flash-lite-preview lasted twelve weeks. Anthropic's page now reads like a contract. Every active Claude model carries a "not sooner than" retirement date, and for each one whose launch date we could check, it falls exactly one year after release. All four Claude 4-generation models retired or scheduled so far went between 12 and 14 months after launch.[2]

Read this as a planning number. If your product depends on one model, budget a migration per model per year, not per decade. And one caution about the chart: it only counts models that have actually been retired. Newer models can't have long lives in it yet, so don't read a trend into the left-hand dots.

And the warning keeps getting shorter

Lifespans are only half of it. The other half is how long you get between hearing about it and losing it.

OpenAI's 2023 announcements gave a median of 312 days' notice; its 2026 ones gave 182. That is now its published floor: at least six months for generally available models, three months for "specialised variants" such as gpt-5.1-chat-latest or gpt-5.3-codex, and as little as two weeks for anything with preview in the name.[1] Anthropic went further. Retiring Claude 2 and Claude 3 Sonnet in early 2025, it gave six months. Every Claude retirement announced in 2026 has given 60 to 62 days, the minimum its policy promises.[2]

Sixty days is enough to change a string. It's not much time to evaluate a replacement, re-tune your prompts, get a security review and ship, especially when the email lands on someone who left in the spring.

Three ways a model dies, and only one is loud

Everyone pictures a deprecation as the first kind: the date passes, requests fail, an alert fires, someone fixes it. That's the good outcome. The other two are worse because nothing fires.

The hard stop. The OpenAI and Claude APIs reject a retired ID outright. Azure returns 410 Gone.[6] Bedrock fails the request after end of life, and says migration "will not happen automatically".[4] Loud, annoying, and easy to diagnose.

The silent swap. Google's deprecation table lists gemini-3.5-flash and gemini-3.7-flash with a note that "the endpoint is not shutting down and automatically routes API requests" to the next model.[5] Your code keeps asking for 3.5. It gets 3.6. Azure does the same thing on purpose: Standard deployments are upgraded automatically when a version retires, so on 9 December every Standard deployment of gpt-4o 2024-05-13 becomes gpt-5.6-sol under the same deployment name.[6] Nothing throws. The answers just change. Researchers showed back in 2023 that the "same" model name could swing from 84% to 51% on a task between two snapshots three months apart.[7] A silent swap is that, on purpose, in production.

The quiet lockout. This one is the nastiest, because it only shows up on a bad day. On Bedrock, once a model enters its legacy period "new customers can't use" it and "existing customers may lose access to Legacy models after 15 days of inactivity", and for the last stretch of that period the provider can raise the price.[4] On Azure, a deprecated model is blocked for any subscription that has never deployed it, and the rule is per subscription: "a new subscription under the same tenant doesn't inherit access".[6] Your production region works fine. Then you fail over to the disaster-recovery region, or spin up a fresh account for a customer, or the monthly batch job that ran 30 days ago runs again, and the model isn't there.

Same model, different funeral

Here's something that trips up teams running on more than one cloud: there's no single retirement date for a model. Anthropic's page says so plainly. Its dates apply to its own platforms, and Bedrock and Google-managed Vertex "set their own retirement schedules".[2]

Claude 3 Haiku stopped working on the Claude API on 20 April 2026. On Bedrock it kept going until 10 September in nine regions, and has until 13 November in six more, so the same model ID dies in three stages over 207 days.[4] o4-mini went dark on OpenAI on Friday and keeps working on Azure until 19 November.[3] And it runs the other way too. Google retired gemini-2.5-pro, gemini-2.5-flash and gemini-2.5-flash-lite on Vertex AI last Tuesday, 20 October.[8] On the Gemini API, the same three IDs have no shutdown date at all. They're just closed to anyone who wasn't already using them.[5] Same company, same model, two answers.

That spread cuts both ways. It's a buffer if you know it's there. It's a trap if your fallback route sends traffic to a different provider and nobody wrote down that the fallback model dies on a different day from the primary.

The dead models hiding in your dependencies

Your own code is the easy part. You can grep it. Harder is every library that picks a model for you when you don't pass one.

So we checked. We took the most-downloaded AI-related packages on both registries: the top 1,500 npm packages matching AI keywords such as openai, anthropic, llm and mcp,[9] and every package among PyPI's 15,000 most downloaded that depends on an LLM SDK or framework.[10] We downloaded the latest published release of each, 2,083 in total, and parsed the code itself, skipping comments, docstrings, tests, examples and type definitions. We counted a package when its running code picks a model for you: a model ID as a parameter default, as the fallback after ||, ?? or or, as the default in a .get(), as a constant named like DEFAULT_MODEL, or as the initial value of a model field on a class. Model catalogues, pricing tables and comparisons don't count. Then we checked every ID against the providers' own deprecation tables.

Of the 2,083 packages, 277 pick a model for you somewhere in code that runs. 104 of them, 38%, include a model that's already switched off. Another 85 include one that's scheduled to go within six months. Only 85 of the 277 default to nothing but current models. And this isn't a graveyard of abandoned projects: 62 of the 104 published a new release in the last 30 days, dead default included.

The most common dead default, in 23 packages, is gpt-3.5-turbo, the model that stopped answering on Friday. We read the source for the ones we name here. The chat class in @langchain/openai 1.7.0, published on 22 October, still declares model = "gpt-3.5-turbo" as the value it uses when you don't pass one. Its completions class defaults to gpt-3.5-turbo-instruct, retired in September. llama-index-llms-openai 0.8.3 does the same through a DEFAULT_OPENAI_MODEL constant. instructor's llm_validator and deepeval's RAGAS metrics both default to gpt-3.5-turbo. crewai 1.15.30, released on Saturday, defaults its Gemini provider to gemini-2.0-flash-001, which Google switched off on 1 June on both the Gemini API and Vertex.[5][8]

None of this matters if you always pass a model explicitly. That's the point: it only bites the code that didn't, usually an evaluator, a validator or a helper that someone wired up once and never looked at again. When the default dies, either that helper starts throwing in production, or worse, it's an evaluation metric that quietly fails and gets caught by a try that logs and moves on.

What a migration actually breaks

Say you've found every reference and swapped in the recommended replacement. The newer model is better, so you're done, right?

We tested that. You can't run a before-and-after on gpt-4 any more (that's the point), so we used open models where every generation is still downloadable. We wrote a 300-item test set that looks like ordinary production work: 100 customer emails to turn into a three-field JSON object, 100 support messages to route to one of four teams, and 100 order totals to compute with vouchers and shipping. Each task had a system prompt of the kind you'd write for the model you launched on. Then we ran it with identical prompts and greedy decoding through successive generations of the Qwen family: Qwen2 → Qwen2.5 → Qwen3 at the 0.5–0.6 billion parameter size, and Qwen2.5 → Qwen3 at 1.5–1.7 billion.[11]

We scored each answer twice. Strict asks whether your code could use it as is: valid JSON with exactly the three keys, the bare label, a bare number. Lenient asks whether the right answer is in there somewhere.

Three upgrades, three different stories, and none of them was "nothing changed".

Every upgrade broke answers that used to be right. Qwen2 → Qwen2.5 broke 26 of the 74 answers the old model got right, 35%, while fixing 36 others, so the headline score went up. At the 0.6B size, Qwen3 broke only 2 of 84. Then at the larger size the newer model was simply worse on our prompts: 181 correct down to 141. It broke 50 of the 181 answers that used to work and fixed 10. If you'd read the release notes and swapped the model ID, you'd have shipped a 22% drop in correct answers.

The failures weren't random. They clustered into two shapes you'll recognise:

• A prompt habit that stopped working. The routing prompt listed the four teams as billing, technical, account, or sales. Qwen2.5-1.5B handled it, at 70 of 100. Qwen3-1.7B sent 87 of the 100 messages to billing, and Qwen3-0.6B sent all 100. The new models leaned on the first option in the list. The old one didn't. Nothing in any changelog would tell you that.
• Right answer, wrong shape. Asked for "only the final number", Qwen3-1.7B got 43 of the 100 order totals right, but only 12 came back as a bare number. The rest showed their working (6 × €19.90 = €119.40…). A human would mark them correct. Your float(response) would throw on 31 of them.

Small open models exaggerate this. That's why we used them, and it's why you shouldn't take our percentages as a forecast for GPT or Claude. Take the shape. A better model is better on someone else's benchmark. On your prompts it's a different model, and you only find out which of your behaviours survived by running your own examples through it.

This has a name in the research literature: negative flips, examples that were right before an update and wrong after it. Apple researchers found them across every model update they studied, "even when the downstream task training procedures remain identical".[12] Even when the average goes up, individual behaviours break. Your users don't experience the average. They experience the ones that broke.

Check your own code in two minutes

Step one lists every model ID your repository mentions, including in .env and config files. Run it at the root:

grep -rhoE --exclude-dir={node_modules,.git,dist,build,.venv,venv} --include={*.py,*.js,*.mjs,*.cjs,*.ts,*.tsx,*.jsx,*.go,*.rb,*.java,*.yaml,*.yml,*.toml,.env*} '\b(gpt-[0-9][a-z0-9.-]*|o[134](-mini|-pro)?|chatgpt-4o-latest|claude-[0-9a-z][a-z0-9.-]*|gemini-[0-9][a-z0-9.-]*)\b' . | sort | uniq -c | sort -rn | tee models-used.txt

Step two checks the OpenAI ones against the API itself. OpenAI's List models endpoint carries a shutdown_date on every model with a retirement scheduled, and a retired model simply isn't in the list:[1]

curl -s https://api.openai.com/v1/models -H "Authorization: Bearer $OPENAI_API_KEY" > models.json

awk '$2 ~ /^(gpt-|o[134]|chatgpt-)/ {print $2}' models-used.txt | while read m; do printf '%-28s %s\n' "$m" "$(jq -r --arg m "$m" 'first(.data[] | select(.id == $m) | .shutdown_date // "no shutdown date") // "NOT SERVED"' models.json)"; done

Every line ends in a date, no shutdown date, or NOT SERVED. We tested it against a fixture repository with a dead gpt-4 call, a gpt-3.5-turbo buried in .env, a gpt-4o-mini default due to retire in January and a current model. It flagged each correctly and ignored the same IDs inside node_modules. The list only shows models your organisation can access, so run it with the production key. For Claude and Gemini IDs, compare models-used.txt against the two providers' deprecation tables. Neither list endpoint carries a retirement date today.

What to actually do on Monday

1. Write down your expiry dates. One line per model in production: the ID, every platform it runs on, and the shutdown date on each. Put the earliest in the calendar of someone who will still be here.
2. Keep a test set before you need it. A hundred real inputs with known-good outputs per feature is enough to show what a replacement breaks. Building one under 60 days' notice is the expensive way to do it.
3. Log the model that answered, not the one you asked for. OpenAI and Anthropic return a model field, and Gemini a modelVersion. Alert when it differs from the request. That's the only way to catch a silent swap.
4. Pin dated snapshots, and set Azure's versionUpgradeOption deliberately. An alias like gpt-4o moves under you. A snapshot fails loudly. On Azure, the upgrade options decide whether a retiring deployment is swapped to a new model for you or, with NoAutoUpgrade, simply stops working.[6] Choose one on purpose.
5. Exercise your failover monthly. Bedrock's 15-day idle rule and Azure's per-subscription access mean a backup region you never call may not have the model when you need it.
6. Never rely on a library's default model. Pass the model explicitly everywhere, including to evaluators, tokenisers and agent frameworks. If you didn't choose it, nobody is watching its date.

The one-line version

Models now live about 16 months. Notice has shrunk to six months at OpenAI and two at Anthropic. More than a third of the popular AI libraries that pick a model for you still pick one that's already dead. And a newer model, run on your old prompts, can break a third of what used to work. A deprecation isn't a string change. It's a release with a deadline someone else set. If you want help building the test set before the next email arrives, that's part of what the readiness audit covers. And if the code that calls these models was itself written by an agent, the AI slop security audit is the place to start.