How to keep working when a model gets retired

Something you set up eight months ago stops working. An automation that summarised your inbox starts returning an error you have never seen. A script that tags invoices fails at 6am and you find out on Thursday when a client asks where their paperwork went. The cause is almost never interesting. The model name you typed into a box back in January was retired, on a date that was published months in advance, in a table you did not know existed.

This is a maintenance problem wearing the costume of an outage. Every major vendor now runs models on a lifecycle with named states and a published calendar, and each publishes a minimum notice period [1][2][3]. Nothing here requires you to predict anything. The work is knowing where you wrote down a model name, and checking that list against the vendors’ pages two or three times a year. This guide is for a solo operator or small team who has wired a model into something that runs without a human watching: an automation, a script, a scheduled job, a product you built for a client. If you only ever type into a chat window, most of the machinery below is more than you need, though the section on what still goes wrong applies to you anyway. Prices quoted are list prices taken from the vendors’ own pricing pages on 4 September 2026 [4][5].

Retirement is scheduled, and the schedule is published

The vocabulary is worth learning once because the vendors use it consistently. OpenAI defines deprecation as the process of retiring a model or endpoint, and a model becomes deprecated the moment the announcement goes out; sunset and shut down are used interchangeably to mean the model or endpoint is no longer accessible; legacy marks models and endpoints that no longer receive updates [1]. Anthropic uses four states. Active means fully supported and recommended. Legacy means the model will no longer receive updates and may be deprecated later. Deprecated means it still works but has a retirement date and a named replacement. Retired means requests fail [2].

Then there is the number that actually governs your week: how much warning you get. OpenAI commits to a minimum of 6 months for generally available models and at least 3 months for specialised variants of them, naming chat, Codex and deep research variants as its examples; preview models can go with much shorter notice, such as 2 weeks, and OpenAI says it does not recommend them for business-critical production workloads unless you can migrate on short notice [1]. Anthropic commits to at least 60 days for publicly released models and says it notifies customers with active deployments [2]. Google gives at least 2 weeks’ notice before deprecating a preview Gemini model, and if you point at a “latest” alias, a breaking change to the version behind it also comes with 2 weeks’ notice by email [3]. In the ChatGPT app the rule is different again: models generally remain available for 90 days after a successor is released [6].

The concrete version is easier to hold in your head than the policy. On OpenAI’s deprecations page today, 23 October 2026 takes gpt-3.5-turbo-0125, gpt-4-0613, gpt-4-turbo, o1-2024-12-17 and o1-pro-2025-03-19, among others, all pointed at the GPT-5.6 family as replacements; 11 December 2026 takes gpt-5-2025-08-07, gpt-5-mini-2025-08-07, o3-2025-04-16 and o3-pro-2025-06-10 [1]. Anthropic retired claude-opus-4-1-20250805 on 5 August 2026 and names claude-opus-4-8 as the replacement [2]. None of that was a surprise to anyone who had the page bookmarked.

Model names hide in more places than your code

If you have a codebase, the model strings in it are the easy part, because you can search them. The failures come from the places where a model was chosen through a user interface and then never thought about again.

Go and look at the model dropdown in Cursor. Look at the OpenAI or Anthropic step inside each Zapier Zap you have published, and the model field on each node in your n8n workflows, and the same in any Make scenario still running. Look at environment variables on whatever host runs your scheduled jobs. Look at the notebook you used once for a client report and left on a shared drive. Look at any custom assistant or saved automation inside a product you pay for. Each of those is a place where a model name was set by a human who is not thinking about deprecation calendars.

There is a shortcut to finding out what you are genuinely calling, as opposed to what you believe you are calling. Anthropic’s console has a Usage page with an Export button that produces a CSV showing usage broken down by API key and model, and the docs give exactly those steps for identifying usage of deprecated models [2]. Start from that list, because it is factual, then work backwards to find which of your setups produces each line. A model name in the export that you cannot account for is the one that will break something.

Pinning and floating fail in opposite ways

There are two ways to name a model, and both have a failure mode. You can pin a dated snapshot, like claude-haiku-4-5-20251001 [2] or gpt-5-2025-08-07 [1]. Behaviour then stays put until the retirement date, at which point the call stops working entirely, because requests to models past that date fail [2]. Or you can use a floating alias. Google’s documentation describes a latest alias as pointing to the latest release for a specific model variation, with 2 weeks’ notice by email before a breaking change to the version behind it, and says most production apps should use a specific stable model instead [3].

The pinned version fails loudly, on a date you can read in advance. The floating one changes quietly, on a schedule someone else sets, and the first sign is usually that output shape or tone shifted and nobody can say when. For anything that runs unattended and feeds a client, pin the version and put the shutdown date in your calendar. For exploratory work in a chat window, floating is fine and saves you the maintenance.

Parameters age out too, which catches people who assume only model names expire. Anthropic lists temperature, top_p and top_k as deprecated, returning a 400 error when set to a non-default value on Claude 4.7 and later models, and recommends omitting them and using prompting to guide the model instead [2]. That is a code change, not a string swap, and it will not show up in a search for model names.

The replacement is usually cheaper than the thing it replaces

Migration reads like a chore, and it is, but the arithmetic is often in your favour. Anthropic retired claude-opus-4-1-20250805, and Claude Opus 4.1 is listed at $15 per million input tokens and $75 per million output; the named replacement, Claude Opus 4.8, is listed at $5 and $25 [2][5]. Claude Sonnet 5 is listed at $2 and $10, below Claude Sonnet 4.6 at $3 and $15 [5]. On OpenAI’s side, the models named as replacements in the October and December 2026 waves are GPT-5.6 Sol at $5 input and $30 output, GPT-5.6 Terra at $2 and $12, and GPT-5.6 Luna at $0.20 and $1.20 [1][4].

That means the migration you have been putting off may reduce a bill rather than raise one, and it gives you a reason to do the work that is not fear of an outage. Two discounts are worth checking at the same time, since you are already in the pricing page. Cached input is much cheaper than fresh input, at $0.50 per million against $5 for GPT-5.6 Sol, and the Batch API saves 50% on inputs and outputs for work that can run asynchronously over 24 hours [4].

Test the replacement on your own work, inside the notice window

The vendors tell you to do this and most people skip it. Anthropic’s guidance is to test your applications with newer models well before the retirement date of your current model, and to update your code to the recommended replacement as soon as possible [2]. OpenAI’s deprecations page carries a replacement for nearly every retiring model, so the mapping is handed to you [1]. What the mapping cannot tell you is whether your particular prompt still behaves on the new model.

The practical version costs an afternoon. Keep a folder of 10 real inputs for each automation you run: 10 actual invoices, 10 actual support emails, 10 actual meeting notes, whatever the job takes. When a replacement is named, run those 10 through the old model and the new one and read both sets side by side. You are looking for the specific things your downstream steps depend on, which usually means format rather than quality. If a later step expects a JSON field or a line beginning with a particular word, that is what breaks, and it breaks in a way that looks like the model got worse.

Do this in the middle of the notice window, not at the end. A 60-day window [2] gives you plenty of room, and the last week of it is when you will discover the replacement writes slightly longer summaries and your character limit now truncates them.

Some retirements are rewrites, not string swaps

The retirements that hurt are the ones where an entire endpoint or product goes, rather than a model behind a stable interface. OpenAI’s Assistants API was sunset on 26 August 2026 and is no longer available [1][7]. Migrating off it is not a name change: assistants become prompts, which hold the model, tools and instructions and are created in the dashboard rather than through the API; threads become conversations, which store items rather than only messages; runs become responses, where you send input items and get output items back instead of polling; and run steps become generalised items [7]. That is a rebuild of the orchestration layer, and if you had shipped something on Assistants for a client, the notice period was the budget you had to do it.

The same page shows the shape recurring. The Videos API along with sora-2 and sora-2-pro is listed for 24 September 2026 with no replacement named, and the v1/prompts API, the Evals platform and Agent Builder are all listed for 30 November 2026, pointed not at drop-in successors but at application code, Promptfoo and the Agents SDK [1]. When the migration path is “write it yourself”, your options are to rebuild elsewhere or to stop offering that feature, and both take longer than swapping a model name.

Consumer apps do this too, on a shorter clock and without asking you. In ChatGPT, GPT-4o, GPT-4.1, GPT-4.1 mini and o4-mini were retired on 13 February 2026, GPT-4.5 was retired on 26 June 2026 following a 30-day sunset period, and when GPT-5.2 went on 12 June 2026 existing conversations that used it automatically continued on the corresponding GPT-5.5 model [6]. If your team has written instructions that say “use GPT-4o for this”, those instructions decayed months ago.

What still goes wrong

The replacement is not the old model. Vendors name a successor and publish notice periods, but nobody promises identical output, and the differences show up in the details your downstream steps rely on rather than in anything a benchmark would catch. If a prompt was tuned over months against one model, expect to re-tune it, and expect that to be the real cost of the migration rather than the code change.

Preserved is not the same as available. Anthropic has committed to preserving the weights of all publicly released models, and all models deployed for significant internal use going forward, for at minimum the lifetime of Anthropic as a company, and to interviewing a deprecated model about its own development, use and deployment and recording its responses [8]. Keeping select models available to the public after retirement is described on the same page as a more speculative complement to the existing process, as the cost and complexity of doing so come down, rather than as a commitment [8]. So a retired model is not deleted from the world, but that is no help to a job that needs to call it on Tuesday.

Third-party tools sit on their own clock and mostly do not email you. Anything that wraps a vendor’s model, whether that is an editor, an automation platform or a small app you bought, can drop support for a model before or after the vendor retires it, for its own reasons. The vendor’s deprecation page does not cover them and your audit list should record which tool each call goes through, not just which model. And none of this helps if your vendor is fixed by a client contract or a procurement policy that names a specific model. In that case the deprecation date is a conversation with the client, and it is better had six months early than on the morning it stops working.