Tracking model availability, when a model vanishes overnight

On 9 June 2026 Anthropic launched Claude Fable 5, a class above Opus. On 12 June it was gone, worldwide for everyone, because a US export control blocked access after a reported jailbreak. Three days after launch, anyone who had nailed a workflow to Fable was staring at a dead model name and a pipeline that returned nothing. Fable came back on 1 July, globally and in the EU too, but nobody knew that on 12 June. Almost three weeks of dead production, and in the moment of the outage you could not know whether it would be three days, three weeks or never.

That is not an isolated case, that is the normal state of 2026. Models get retired on schedule (Claude 4 was retired on 15 June), suspended overnight, blocked regionally or tightened in their rate limits. The question is not whether a model will drop out from under you, but when. This playbook shows you how to set yourself up so that losing a single model does not knock you over.

1. Understand how many ways a model can disappear

There is not just "retired". Four cases you have to keep apart, because they come with different warning times:

Planned deprecation. The provider announces a shutdown date weeks ahead. Here you have time, if you catch the announcement. Overnight suspension. Export control, legal dispute, security incident. Zero warning, as with Fable. Regional block. The model runs, just not from your location. Rate limit tightening. The model is there, but your quota suddenly is not enough. All four lead to the same result from your workflow's point of view: the call fails. Only the warning time differs.

2. Never nail yourself to a single model

That is the core mistake. A hardcoded model name in a single place, with no plan B. When that name dies, your workflow dies with it.

The mindset you need: a model is an interchangeable resource, not a fixed component. You do not build "with Fable", you build "with the strongest available model, and right now that is Fable". The difference sounds academic but it is the whole point. Once you think that way, losing a model is a switch, not a break.

3. Define a fallback chain, across providers

A fallback chain is an ordered list: if the first model does not work, take the second, then the third. What matters is that the chain does not stay within one provider. If an export stop hits all models of one provider, a fallback to the same house does not help you.

A robust chain therefore mixes the houses. For example: at the top the flagship model you actually want, below it the solid middle class of a different provider, at the very bottom a cheap model that almost always runs. That way you also survive the case where an entire provider drops out. Which model classes the big three have and what they are good enough for is in the lesson Model landscape 2026.

4. Check availability actively, do not notice it at the outage

Do not wait until a customer complains. Most providers have a status page and an endpoint that lists the currently available models. A simple call against that model list, once a day or before an important run, tells you whether your primary model is still there before you rely on it.

You do not have to build anything big for that. A small check that fetches the list of available models and looks whether your desired model is in it is enough to start. If it is gone, you know it on your terms, not on the outage's terms.

5. Centralise model names in exactly one place

If your model name sits in five places in the code or in five different tools, a switch becomes a search operation with an error rate. Put the model choice in a single place, a config file, an environment variable, one central field. Then a model switch is a change in one place, not five.

That is the same discipline as with Claude Code and the fallbackModel setting. What that looks like concretely there is shown in the playbook Setting up fallback models. But the principle holds everywhere, no matter which tool: one source of truth for the model choice.

6. Graceful degradation, weaker beats nothing

When your flagship model drops out, a weaker model is almost always better than no answer. A classification task also runs on the middle class, just maybe a touch less precisely. A summary comes out a little flatter on the budget model, but it comes.

So build your chain to degrade downwards instead of aborting. The technical term for that is graceful degradation. For the genuinely hard tasks, deep code architecture, long multistep thinking, it may be that only the flagship will do. Then the honest answer at that point is not "any model" but "wait until the good one is back". But that is the exception, not the rule.

7. Test the switch before things burn

You do not want to find out during a real outage whether your fallback chain works. The pragmatic test: briefly set a model name that does not exist as your primary, or one you have no access to, and see whether your system jumps cleanly to the next entry in the chain. If that works, you know the mechanism holds. Then put the correct model back.

That is a mini chaos test. Break it on purpose once, watch, put it straight again. Five minutes that save you a sleepless night when it counts.

8. Keep an eye on cost and quality during fallback

A fallback chain almost always points downwards, from the expensive flagship to the cheaper one. That is good, during an outage it gets cheaper rather than more expensive. Just make sure you do not accidentally enter a more expensive model as fallback, otherwise exactly the outage you wanted to insure against costs you the most.

And keep in mind that a fallback changes quality. If your system quietly jumps to a weaker model and nobody notices, the output can be worse for weeks without you knowing. Which is why the next step exists.

9. Monitoring that tells you when the chain kicks in

A fallback that happens silently is only half the solution. You want to know when your system switched to a substitute model, especially when it fell all the way through to the last entry in the chain. A single notification, an email, a Telegram message, an entry in a channel, with the information "primary model gone, now running on fallback X" is enough.

Do not make it too loud. If every little hiccup sends you a message, you stop looking after three days. Report the case that really counts: the chain is on the last model, or the flagship has been gone for hours. The principle is the same as alerting for automations, described in the lesson When automations fail.

10. When none of this concerns you

The honest conclusion. If you only use AI occasionally in a chat window and do not run a pipeline that has to keep going, you do not need a fallback chain. If your model drops out, you just pick another one by hand. All the effort here only pays off once something runs automatically and must not stall, an agent, a workflow, a service for others.

But that is exactly the threshold from AI user to AI operator. A user notices the outage and waits. An operator has prepared and barely notices it. When the expensive flagship class is worth it at all and when the middle class is enough is explored in the playbook Mythos model class, when is it worth it.

Sources

• Claude Fable 5: launch (09.06.2026), worldwide suspension via US export control (12.06.2026), lifting and global return including the EU (01.07.2026): the model landscape lesson documents the course of events, Anthropic announcements at https://www.anthropic.com/news
• Claude model overview and deprecation notes: https://platform.claude.com/docs/en/about-claude/models/overview
• OpenAI model release and retirement notes: https://help.openai.com/en/articles/9624314-model-release-notes
• Gemini model overview: https://ai.google.dev/gemini-api/docs/models

Model names and availability change fast. If you read this months later, check the current state via the links above.