Your AI Tool Can Be Cut Off Overnight: The Fallback Plan to Have

If your business runs on the API of a single AI provider, you have a single point of failure that nobody puts a number on. Covering it costs one layer of code and a second tested model, not a migration. Here is how to go about it as a freelancer or a small agency, starting from a concrete case.

Take Atelier Lumen, a four-person web agency (an invented case, like everything about the agency in this article). It sells its clients an assistant that answers visitors' questions on their website, wired to the API of one model. One Friday evening, access to that model stops. No outage, no unpaid bill: a decision made somewhere else. On Monday morning four clients call, and nobody at the agency knows how long it would take to plug in something else.

This scenario has a real precedent. On 12 June 2026, Anthropic received a directive from the US government, citing national security, asking it to suspend access to Fable 5 and Mythos 5 for anyone of foreign nationality. Anthropic switched both models off for all its users, as Blog du Modérateur and Siècle Digital report (both in French). Fable 5 had launched three days earlier. On Vercel's AI Gateway, access only came back on 1 July 2026, almost three weeks later.

What can cut off a provider, besides an outage

Unavailable does not only mean down. A model can disappear for reasons that have nothing to do with its technical reliability:

• A regulatory or political decision, like the shutdown of Fable 5 and Mythos 5.
• A version retired by the vendor, who pushes its customers toward a newer model and unplugs the old one.
• A change in terms of use that excludes your use case or your industry.
• A break in the contractual relationship decided on the provider's side.

In each of these cases, your service stops without you having made a single mistake. The problem is not the model you chose. It is having only one, with no exit door.

Three questions to size the risk, use by use

Not every use of AI deserves the same fallback. For each one, answer three questions:

• What impact if this model stops tomorrow morning? A little less convenience, or a client losing inquiries?
• How long to switch to an alternative, with your code as it is today?
• Who decides whether this service stays available, and under what rules that can change without you?

Here is what it looks like for Atelier Lumen, use by use:

The level of precaution follows the stakes, like an insurance policy: a convenience feature can stop for a day without harm, a service you bill to a client cannot.

Three levels of fallback, from simplest to most committing

A fallback plan does not mean rewriting everything or moving it all onto your own server.

Level 1: isolate the model call behind a single function. Instead of calling the provider's API in twenty places in your code, you go through one function that calls the model. The day you change providers, you edit that one file. My estimate, with no measurement behind it: a few hours to a few days depending on the state of your code, far less than a migration done in a hurry. The skeleton fits in a few lines:

// llm.ts: the only file that knows the providers
type Provider = (prompt: string) => Promise<string>

export async function askModel(
  prompt: string,
  providers: Provider[],
): Promise<string> {
  for (const call of providers) {
    try {
      return await call(prompt)
    } catch (error) {
      console.error('Provider unavailable, switching to the next one', error)
    }
  }
  throw new Error('No provider available')
}

Level 2: keep an alternative that is tested, not just identified. A second name in a document is not enough. An alternative is only a fallback if it has already run on your real requests, with your prompts, and you know how it behaves. Run ten real requests through the second model and compare the answers with the first one: differences in tone, format or accuracy get fixed the same day, not during the crisis. Some gateways do the switching for you: Vercel's changelog recommends using AI Gateway's "model fallbacks", which tries each model in a list in order when the first one refuses the request.

Level 3: host in-house whatever cannot be allowed to stop. Running an open model on your own infrastructure removes the dependency on a third party. This level takes real investment, and an open model is often less capable than a recent commercial one on hard tasks: test it on your cases before committing. It is only justified when the stakes call for it, for example client documents that must not leave. I covered this option, with its real running cost, in the backend of a sovereign AI product.

A fallback sheet to fill in for each use

Fill it in once per use, in the order of the table. Ten minutes per use is enough to see where you stand.

Use: [e.g. answering assistant on a client's website]
Current provider and model: [provider name, model name]
If it stops: [convenience lost, or client losing inquiries]
Call isolated in a single file: [yes, no]
Chosen alternative: [provider and model]
Alternative tested on real requests: [yes on (date), no]
Where my prompts and data live: [in my repository, in the provider's tool]
Who switches, and how: [name, steps]

Dependency does not stop at the model

Changing the model is not enough if everything else stays captive. If your prompts, your reference data and your business logic live in the proprietary format of a single tool, you stay dependent even with a spare model. Keep your prompts in your repository and your data in a format you know how to export. If your automation lives in a tool like n8n, Make or Zapier, note it on your sheet: that choice of tool is a dependency too. Where your data goes is another question, which I cover in the French alternative to ChatGPT.

If you already have an automation or an agent wired to a single provider, adding the Level 1 layer and testing a second model is a small dev project I take on.

Key takeaways

• The risk is not the quality of the model, it is dependency on a single point.
• A shutdown can come from a political decision, a retired version or a change in terms, through no fault of yours.
• Three levels: a single layer, a tested alternative, self-hosting for what is critical.
• The concrete action: before wiring an important use onto a model, isolate the call in one function and test a second model.

FAQ

Do you need a fallback for every use of AI?

No. The level of precaution follows the impact. A newsletter draft that can wait a day needs nothing special. A service you bill to a client deserves at least a single layer and a tested alternative. Rank your uses with the table above before deciding.

Is the single layer complicated to set up?

It is simple work if done at the start, and painful if added under pressure. It means routing every model call through one function. I do not give a standard duration without knowing your code: count the places where you call the provider, and that gives you the order of magnitude.

Is a self-hosted model as good as a commercial one?

Not always on the most demanding tasks. For some simple functions it can be enough, with the advantage of removing the dependency on a third party. The decision is made case by case, by testing on your real requests and weighing the result against the cost of hosting.

How do I know which uses to handle first?

Ask one question for each: if this service stops tomorrow morning, is it an inconvenience or a blocker? Blockers come first, especially when they affect a client.

Sources

• Blog du Modérateur, Le gouvernement des États-Unis force Anthropic à couper l'accès à Fable 5 et Mythos 5, June 2026 (in French)
• Siècle Digital, Anthropic contraint de couper en urgence ses IA jugées les plus dangereuses, 15 June 2026 (in French)
• Vercel, Claude Fable 5 access restored on AI Gateway, 1 July 2026

The next step is knowing where your clients' data goes when you use ChatGPT. I share this kind of breakdown in my newsletter, you can sign up right below.