Do Not Single-Source Your AI: A Second-Source Playbook

AI vendor resilience stopped being a theoretical risk at 5:21 PM Eastern on June 12, 2026, when a US government export-control directive ordered Anthropic to suspend Claude Fable 5 and Mythos 5 for all foreign nationals. Because the company could not verify user nationality in real time, both models went offline globally — for everyone, US customers included.

That is the scenario every multi-vendor strategy is supposed to survive, and most teams have never run the drill. A single API key pointed at a single provider is a single point of failure, and on June 12 that failure mode moved from slideware to a live outage with no published restoration date. As of June 21, 2026 — the day this was written — Fable 5 and Mythos 5 remained dark, with Anthropic stating it was confident access would return in the coming days.

This guide treats that episode as the case study it is. We cover the three distinct ways a vendor can vanish, the three capable open-weight models that shipped as fallbacks within roughly ten days, a head-to-head comparison matrix to qualify a second source, and a four-step playbook — router layer, fallback chain, warm open-weight backup, contractual exit — that converts an overnight blackout into a routing decision.

At 5:21 PM ET on June 12, 2026, a US export-control directive ordered Anthropic to suspend Claude Fable 5 and Mythos 5 for all foreign nationals. Anthropic could not verify user nationality in real time, so it took the safe-but-total action: both models went offline globally, for every user. Customers who had built directly against those models had no model to call the next morning.

Anthropic publicly disagreed with the action. It described the demonstrated jailbreak technique — broadly, instructing the model to read a codebase and fix any software flaws — as relatively simple, and noted that similar capabilities exist in other frontier models. More than 100 cybersecurity leaders signed an open letter opposing the controls, arguing they would hinder legitimate security research. For the purposes of this playbook, the merits of the dispute matter less than the operational fact: the model was gone, and a customer had no say in when it came back.

We covered the capability the ban removed in our Fable 5 and Mythos 5 release benchmarks write-up, and the sovereignty and policy dimensions in our analysis of the US export controls and AI sovereignty. This piece is the operational sequel: not what happened, but what an engineering team should have had in place before it did.

Most contingency planning assumes the only thing that goes wrong is a transient outage. That framing is too narrow. Industry analysis of the Fable incident groups vendor-disappearance risk into three distinct modes, each with a different shape and a different mitigation. A backup that only survives mode two is not a second source.

Here is the original lesson of June 12: the failure that actually took teams down was mode one, the mode almost nobody had hardened against. A multi-region deployment, a generous rate-limit budget, and a snapshot pin — the standard mode-two and mode-three defenses — did nothing, because the model itself was withdrawn by directive across every region at once. Resilience that only covers operational wobbles is resilience against the wrong risk.

The reason the Fable episode is a usable case study and not just a cautionary tale is that the open-weight ecosystem responded before access was restored. A June 18 analysis framed the moment as the live test of open-weight fallback strategies, naming a cluster of models that were available — and self-hostable — while the primary stayed dark. Three stand out as genuine second-source candidates for coding and agentic work.

Choosing a second source is not about which model wins a leaderboard. It is about license type, sovereignty status, the hardware needed to self-host, context parity with your primary, and a benchmark floor you can verify. The matrix below puts the three post-ban open-weight candidates on exactly those dimensions, drawn from each vendor's own model card.

Read down the license row first. All three carry permissive licenses — and crucially, MIT and Apache 2.0 weights carry no regional restriction a directive can switch off, because once the weights are downloaded they run on hardware you control. That is the structural property that makes an open-weight model a genuine second source against mode-one risk, where a same-vendor API fallback fails. For a deeper build-or-buy treatment, our open-weight vs closed-source trade-offs piece walks the full decision, and the self-hosting open-weight LLMs guide covers the deployment mechanics.

The goal of a second-source strategy is narrow and concrete: when a primary provider disappears for any of the three reasons above, production keeps serving requests on a qualified alternative without a code rewrite or a frantic all-nighter. Four steps get you there, in order. The first two are cheap and you should already have them; the second two are where most teams stop short.

Sequencing matters. Steps one and two protect you against operational failure on day one and cost almost nothing to stand up. Step three is the only one that addresses mode-one risk, and it is the step the Fable incident exposed as missing in most stacks — because a fallback that routes back through the same vendor, or the same jurisdiction, carries the same exposure that took the primary offline. Step four is the slow, unglamorous work that determines whether a planned migration is a quarter of effort or a week.

Here is the structural blind spot that almost no contingency plan names out loud. A team running a vendor's mid-tier model in production will often set the same vendor's flagship as the backup — same provider, same account, same legal jurisdiction. That configuration handles a per-model glitch, and absolutely nothing else. A gateway that routes primary and secondary through the same provider offers no protection from a geopolitical shutdown, because a same-vendor backup shares the exact policy and legal exposure that takes the primary down.

The fix is a rule, not a feature: at least one link in the fallback chain must be a different vendor or a self-hosted open-weight model. Routers earn their keep here. A well-built gateway deprioritizes any provider showing a recent outage and weighs the remaining options by health and cost over a rolling window — but it can only route to providers you have qualified, which is why step three of the playbook cannot be skipped.

A practical detail teams worry about: does the gateway hop add latency? In the LiteLLM case, reported gateway overhead is on the order of a few milliseconds, with throughput well into the hundreds of requests per second on a single core — negligible against model-inference time. The cost of the abstraction is close to zero; the cost of not having it is a rewrite under pressure. For multi-vendor orchestration patterns that build on this routing layer, our look at multi-agent orchestration with open-weight models covers how a pool of models can sit behind one coordination layer.

Vendor dependency is usually argued as a risk. It is also a number. At list output pricing, the proprietary frontier models cost several times more per million tokens than the open-weight fallbacks that shipped during the ban window — so single-vendor dependency is not only a continuity exposure, it is a recurring premium paid for the privilege of having no alternative. The table normalizes output price against the cheapest open-weight option in our set.

The multiples are computed against Kimi K2.7-Code at $4.00 per million output tokens as the cheapest open-weight option in the set: GLM-5.2 at $4.40 is 1.1×, Claude Opus 4.8 at $25.00 is roughly 6.3×, and GPT-5.5 at $30.00 is 7.5×. The point is not that open weights are always the right primary — proprietary frontier models still lead on many tasks, and these open-weight scores remain largely vendor-stated. The point is that the gap between a proprietary primary and a self-hostable second source is wide enough that qualifying a fallback frequently pays for itself on routine traffic alone, before it ever earns its keep as insurance.

The teams that came through June 12 with the least disruption were the ones that had built an abstraction layer into their first AI deployment — and industry analysis suggests that early abstraction meaningfully cuts the effort of adding or switching providers later, compared with building directly against a single-vendor API. The forward signal is straightforward: regulatory action against live models is now a precedent, not a hypothetical, and the second-source discipline that semiconductor procurement has used for decades is arriving at AI infrastructure.

Concretely, this quarter: stand up an OpenAI-compatible gateway if you do not have one; add an ordered fallback chain with at least one non-primary-vendor link; qualify one open-weight model end to end — run your own evals, deploy it to a surface you control, and confirm it serves real traffic acceptably; and put portability and deprecation-notice terms into your next vendor contract. None of these is exotic. The reason most stacks lacked them on June 12 is not difficulty — it is that the failure mode they guard against had never actually fired before.

If you want a partner to run the comparative evaluation and stand up the routing layer, our AI transformation engagements start with exactly this kind of resilience review — benchmark your workloads against open-weight second sources, design the fallback architecture, and qualify a warm backup before you need it rather than during an outage.