How to keep working when your AI model gets switched off

You spent a month getting one model to do a job properly. The prompt is tuned, the output lands in the right format, and you stopped checking it every time. Then one morning the call returns an error, or the app answers in a slightly different voice and your reliable little machine starts producing work you have to read line by line again. Nothing broke. The model reached the end of its published life and was switched off on a schedule that was set before you ever started using it.

Every hosted model gets retired eventually, and all four of the large providers publish a policy that says so [1][2][3][4]. Anthropic is the most direct about why, stating that it “currently deprecates and retires models to ensure capacity for new model releases” [1]. This is not a rare disaster, and it is not a reason to avoid AI. It is a maintenance fact, like a supplier discontinuing a part. This guide is for solo operators and small teams who have real work sitting on top of a named model. It is not for people running their own weights on their own hardware, who have a different and mostly harder set of problems.

Your model already has an expiry date, and it is published

The useful thing about model retirement is that it is documented in advance, on pages you can read today. Anthropic publishes a table of Claude models with each one’s state, deprecation date and retirement date, and commits to “at least 60 days’ notice before model retirement for publicly released models” [1]. OpenAI commits to at least 6 months for generally available models, at least 3 months for specialised variants such as chat, Codex and deep research versions, and as little as 2 weeks for preview models [2]. Microsoft gives at least 60 days for generally available models in Foundry and at least 30 days for previews [4].

Those pages also carry the floor dates for models that are still current. Anthropic lists claude-opus-5 as retiring “not sooner than July 24, 2027” and claude-fable-5-1 not sooner than 1 September 2027 [1]. Google is blunter about what a date means: the shutdown dates in its Gemini table “indicate the earliest possible dates on which a model might be retired”, with the exact date communicated later, in advance [3]. So the honest reading of any of these numbers is a floor, not a promise, and on Anthropic’s current table the floors sit more than a year out [1]. That is enough runway to plan with, if you go and look.

Look now, and put the date somewhere you will actually see it. A notice period only helps if the notice reaches you, and every one of these promises is delivered as a message to whatever address sits on the account.

The chat app tells you less than the API does

If your work happens in the chat window rather than through an API key, you get a worse deal on warning. Those dated tables cover API models. Removals from ChatGPT show up in the release notes instead, sometimes flagged as previously announced and sometimes recorded as already done [6]. GPT-4o, GPT-4.1, GPT-4.1 mini and o4-mini were retired from ChatGPT on 13 February 2026; GPT-5.1 models on 11 March 2026; GPT-5.2 models on 12 June 2026; GPT-4.5, including for custom GPTs, on 26 June 2026 [6]. That is four removals in under five months.

The failure mode here is quieter than an API error, which makes it worse. When a model disappears from a chat product, existing conversations carry on automatically: threads that used GPT-5.2 continued on GPT-5.5, and threads that used GPT-4.5 continued on GPT-5.5 [6]. Your saved work keeps answering. It is just being answered by something else. Nothing turns red, the only signal is that the output feels slightly different, and you can ship several pieces of work before you register the change. Where you named the model yourself, as in a custom GPT, it stops being on the menu instead [6].

The same asymmetry shows up on hosted platforms. In Microsoft Foundry, standard deployments are auto-upgraded to the replacement model on a rolling basis, while provisioned deployments are not, and any deployment left unmigrated at the retirement date returns 410 Gone [4]. Silent substitution and a hard failure are both switch-offs. One of them tells you.

The off switch is not always the vendor’s to hold

Scheduled retirement is the common case. The rarer case is worth knowing about because it removes the notice period entirely. On 12 June 2026 Anthropic said a US export control directive left it no option but to pull two models globally: “The net effect of this order is that we must abruptly disable Fable 5 and Mythos 5 for all our customers to ensure compliance” [8]. The company said it disagreed with the finding behind the order and was “working to restore access as soon as possible” [8]. It disabled the models anyway. Fable 5 is listed as active again on Anthropic’s model table today, with a retirement date not sooner than 9 June 2027 [1], so the outage was survivable. It was also unscheduled, and nobody got 60 days.

Treat that as one example of a category rather than a prediction. The category is any reason a model becomes unavailable that has nothing to do with a deprecation calendar: a regulator, a region-level restriction, a safety hold, a billing dispute, an account flagged by an automated system. OpenAI’s own policy allows for it, stating that if safety or compliance concerns require retiring a model sooner, it will provide “as much notice as reasonably possible” [2].

You cannot plan around the specific cause. You can plan around the shape, which is always the same: capability you rent, withdrawn on a schedule that is not yours. The preparation for a surprise cutoff and for a 60-day notice is identical, which is convenient, because you only have to do it once.

Find the places where a model name is load-bearing

Before you can move, you need to know what is nailed down. Go through your setup and list every place a specific model is named: API calls in scripts, the model field in an automation step in Zapier, n8n or Make, the model selector in Cursor, the assistant you configured inside Notion, and any prompt whose wording was tuned to one model’s habits. For each one, write what breaks if that model stops answering tonight, and how long it would take to be running again.

While you are in there, check whether you pinned a version or an alias, because they fail differently. Anthropic describes older dateless IDs such as claude-sonnet-4-5 as “a convenience pointer that resolves to the most recent dated snapshot for that minor version”, while from the 4.6 generation onward the dateless ID “is not an alias. It is the snapshot”, and “Anthropic does not update the weights or configuration of an existing model ID” [7]. A pinned snapshot gives you a stable model and a hard stop on the retirement date. An alias gives you a moving model and no stop at all. Both are defensible. Choosing one by accident is not.

Keep this list short and boring. Six lines in a text file beats a diagram you make once and never open again.

Run a real week’s work through the backup before you need it

A fallback you have never tested is a guess. Pick a second provider, take last week’s actual inputs, the real client email and the real messy spreadsheet rather than a tidy sample, and run them through. Read the output the way you would read a subcontractor’s first job: not “is this impressive” but “would I have sent this”. You are not looking for a match. You are looking for a floor you could ship from for two weeks while you retune.

Do this once per load-bearing workflow, and use the calculator below to size the job against your own numbers before you start. The output is something you did not have before: your actual recovery time, in hours, per workflow. That number is what turns a switch-off from an emergency into a chore, and it is worth re-checking every six months or so, because both your prompts and the models move underneath you.

Keep the inputs where the vendor cannot retire them

The model is the part that gets switched off, but it is rarely the expensive part to replace. The expensive part is everything you fed it: the prompt library, the examples of good output, the style notes, the reference documents, the corrections you accumulated over months. If that material lives only inside one vendor’s product, as saved chats or custom instructions or a project workspace, then you have a second dependency hiding behind the first, and it retires along with the model.

Keep the originals somewhere plain and portable. Text files, a Notion database, a folder in your drive, anywhere you can copy from without an export request. Write prompts that describe the job, the audience and the format rather than working around one model’s quirks, because a prompt that reads like a clear brief to a competent stranger tends to survive a provider change intact, and a prompt full of hard-won hacks for one model’s specific weakness does not.

It is also worth knowing that retirement no longer necessarily means deletion. Anthropic committed on 4 November 2025 to preserving the weights of all publicly released models “for, at minimum, the lifetime of Anthropic as a company”, and said it is “starting to keep select models available to the public post-retirement as we reduce the costs and complexity of doing so” [5]. That is a real commitment about the future and very little help on your Tuesday. Preserved is not the same as available.

What still goes wrong

The published dates are floors, not guarantees, and the policies say so out loud. Google’s Gemini shutdown dates are described as the earliest possible dates rather than the real ones [3], and OpenAI reserves the right to move faster for safety or compliance reasons [2]. A calendar reminder based on those dates is a good habit that can still be overtaken by events, as the June 2026 export control directive showed [8]. Plan for the notice period you are promised, and keep enough slack to survive not getting it.

The deeper problem is that a fallback is rarely equivalent. Models differ in the shapes of work they are good at, and the one you tuned around may genuinely be better at your particular job than anything you can switch to that afternoon. Portability buys you continuity, not parity. Plan for the first two weeks after a forced switch to produce worse work at the same price, and price that into your promises rather than discovering it in front of a client.

Finally, none of this helps with the version of the loss that has no technical fix. If you have spent a year with one model and built working habits around how it thinks, a retirement takes that away and no checklist gets it back. Anthropic’s own documentation acknowledges the cost, listing users who value specific models, researchers who lose access for ongoing and comparative studies, and safety- and model welfare-related risks among the downsides of retiring models [1]. Its preservation commitment records a retired model’s own reflections but states that “at present, we do not commit to taking action on the basis of such preferences” [5]. That is the state of the art. The rest is knowing the date and having somewhere else to go.