← Back to Insights

Insight

The Off Switch Lives Elsewhere

Ariel Agor
The Off Switch Lives Elsewhere

Listen · Read by Leo · click any word to jump

0:00 / · loading…

On Friday morning, June 12, 2026, engineering leaders at hundreds of enterprises woke up to a specific kind of dread. The two most capable AI models on the market, Claude Fable 5 and Claude Mythos 5, had been dark for hours. Not throttled. Not rate-limited. Off. Anthropic had disabled them worldwide for every customer, including customers with signed contracts, negotiated SLAs, and enterprise-tier support.

Anthropic did not choose to do this. The US Department of Commerce did. Three days after the June 9 public launch of Fable 5, security researchers had published a jailbreak that could strip the model's safety guardrails. Commerce Secretary Howard Lutnick sent a letter to CEO Dario Amodei on June 12 directing Anthropic to suspend access to Fable 5 and Mythos 5 for any foreign national, anywhere in the world, including foreign-national employees working inside Anthropic itself. Because nationality cannot be filtered in real time at the API layer, the practical response was global suspension.

The order was withdrawn on June 30. Anthropic restored access on July 1. Nineteen calendar days. Long enough for the finance team at a boutique investment bank to lose the reasoning model behind its underwriting workflow. Long enough for the ops team at a European SaaS company to watch its production incident-triage agent fall back to its "no model available" branch and page a human every seven minutes. Long enough for anyone who had built anything that mattered on a hardcoded Anthropic SDK call to learn a lesson worth documenting.

That lesson is not the one most enterprise buyers think it is.

The playbook you were handed

For roughly a decade, the corporate discipline of avoiding AI vendor lock-in has been framed as a two-party problem. There is a buyer. There is a vendor. The buyer worries about the vendor changing prices, discontinuing products, changing terms of service, getting acquired, or going out of business. The recommended defenses are the same defenses procurement teams learned to apply to enterprise SaaS in the 2010s. Negotiate exit clauses. Insist on data portability. Keep a hot second-source. Diversify the SKU count.

The Snowflake and ServiceNow deals from earlier in 2026 look like current best practice under that frame. Snowflake committed $200 million to OpenAI while running simultaneous production partnerships with Anthropic, Google DeepMind, Meta, and Mistral. ServiceNow signed multi-year deals with both OpenAI and Anthropic in January 2026 and told analysts on the earnings call that customer optionality was the explicit feature. This is competent behavior inside the two-party model. Hedge against any single vendor. Give your customers choice. Do not wire yourself to one throat to choke.

Then May 13 happened. OpenAI launched a 30-day promotion offering two months of free Codex enterprise access to any team migrating off a competitor, plus a one-click import tool for Claude Code prompts, skills, and MCP configurations. Anthropic responded within hours by raising Claude Code weekly quotas by 50% through July 13. Pricing wars are a normal two-party phenomenon. Enterprises noted the free trial. Some took it. Analysts wrote it up. Nothing about the incident violated the assumptions of the old playbook.

Then June 12 happened, and the playbook broke.

The third party never signed your contract

Nothing about the Fable 5 shutdown fit inside a two-party contract dispute. Anthropic did not choose to breach its agreements. Its customers did not choose to migrate. The event was driven by an actor who had never signed anything with either party. A Commerce Department letter, from a person with no contractual relationship to the buyer, took the buyer's core model offline in every region simultaneously.

The three-party problem is now the actual problem. Governments can pull a model. Courts can enjoin a specific use case. Standards bodies can deprecate a spec. Upstream compute providers can throttle. Foreign regulators can block. The specific mechanism does not matter. What matters is that the risk register your general counsel maintains for AI vendors is missing the party who will actually take your system down.

If your real strategic goal is avoiding AI vendor lock-in, and you want that goal to survive a live event, then the buyer has to architect for events that no vendor could have contractually prevented. Anthropic could not have refused the Commerce letter. OpenAI could not either. Neither can any other US-hosted lab. Neither can a Chinese lab hosted in China with respect to that government's directives. Neither can Mistral in France if Brussels issues an emergency directive under the AI Act. The vendor is a passenger on this particular train.

The buyer has to build the train.

What the multi-provider architecture actually is

Here is where the abstract argument meets a shipping stack. In 2026, the practical architecture for surviving a third-party model shutdown has three layers. Each of them predates June 12. Each of them is being adopted at a different rate.

The gateway layer

An AI gateway is a control plane that sits between application code and the actual model providers. Application code calls the gateway with a unified request format. The gateway decides which provider, which model, and which region actually gets the request. It handles authentication, cost tracking, semantic caching, retries, and failover. Three products dominate the space. Portkey went open source under Apache 2.0 in March 2026, so the routing and guardrails core can be self-hosted without a managed subscription. LiteLLM is the incumbent open-source Python proxy, running as an in-process library or a standalone server. OpenRouter is a hosted marketplace with a single API key and access to more than 200 models on token billing. Any of the three, chosen for the buyer's actual constraints, converts a Fable 5 outage from a code deployment into a config change.

The portable interface layer

The Model Context Protocol, which Anthropic donated to the Linux Foundation's Agentic AI Foundation in December 2025, is now the closest thing the industry has to a vendor-neutral standard for connecting AI agents to the tools, data, and services they act on. AWS, Google, Microsoft, OpenAI, Bloomberg, and Cloudflare backed the transition to independent governance. The Registry lists more than 9,600 latest server records as of May 24, 2026. Downloads run around 97 million a month. Every major AI provider ships native MCP support. MCP is also technically elegant. What matters more for portability is that a tool integration written to MCP is portable across model providers. A tool integration written directly to a proprietary agent framework is not.

The evaluation layer

This is the piece most enterprises get wrong, because the vendors ship it wrong. Every provider's evaluation dashboard is optimized to make their own models look good on their own benchmark suite. If your team's promotion criteria for a new model is "did it score higher on the vendor's eval than the last one," you have a lock-in problem you did not know you had. The evaluation suite that matters is the one built on your production traces, your domain vocabulary, and your users' actual workflows. That suite has to run against any provider you might route to, on demand, in under an hour. This is boring, unfashionable infrastructure work. It is also the layer that decides whether portability is a live property or a talking point.

The cost of not architecting this

Reporting from the Fable 5 window paints two clear pictures.

Companies that had wired the Anthropic SDK directly into their application code, without a gateway, spent the first 48 hours after the shutdown writing emergency migrations. The reasoning models in their pipelines went to fallback GPT-4o or Gemini 2.5 routes that had never been production-hardened for those exact prompts, and quality regressed in ways their evals did not catch, because their evals only ran against Claude. Public post-mortems from midsize firms landed in the range of $315,000 in engineering time plus an unknown quantity of missed customer commitments during the outage window.

Companies that had a gateway in front of their model calls treated the outage as a routing change. The gateway noticed Fable 5 was returning errors, fell back to the next model in the list, logged the switch, and paged an on-call reviewer for eval regression. The specific quality delta was tracked in real numbers, not vibes. Some traffic was pinned to Fable-only paths, because that was the only model that met a specific reasoning threshold on their internal eval, and those paths degraded gracefully with a user-facing "reasoning mode temporarily reduced" banner. That is what a working portability architecture looks like under fire.

The difference between the two outcomes had nothing to do with the size of the company, the maturity of its procurement function, or the cleverness of its lawyers. It had to do with whether the buyer had internalized that portability is an internal engineering property. A legal clause is not portability. A vendor promise is not portability. Portability is code, running, that switches under fire.

Buying a multi-model tool is not portability

This is the part where a lot of enterprise buyers get talked into the wrong answer.

Vendors are aware of the three-party problem. They have been aware for at least a year. The commercial response is a marketing category commonly labeled "multi-model" or "any model" or "model choice." A vendor sells you an application-layer product, some combination of agent platform, retrieval stack, and enterprise copilot, and tells you it works with OpenAI, Anthropic, Google, Meta, and every other name you might ask about. The pitch is: you buy this from us, we handle the vendor problem for you.

The problem with that pitch is that the multi-model vendor is itself a single vendor. If the multi-model vendor gets acquired, changes its pricing, deprecates its API, or (this is the case that matters) is subject to its own third-party event, you now have the same lock-in problem one layer up the stack, in a layer you can no longer see into. You have paid to have your portability abstracted away from you. What you actually bought is a portability-shaped subscription. The three-party risk is still there. You just cannot see it anymore.

The architecturally honest version costs more up front. You run your own gateway. Your own MCP integrations. Your own eval suite. You keep the primitives inside the perimeter you actually control. When a third-party event hits, you route around it, and you know exactly what the route is.

What this changes for the strategy conversation

For any company at the point of writing a real AI strategy, the June 12 event is not a footnote. It is a data point about the shape of the risk. The specific facts to update on are these.

Every AI vendor contract you sign is a three-party contract now, even when the third party never signs. Your general counsel should be pricing that in. Your CIO should be building for it. Your board audit committee should be asking about it in the same terms it asks about ransomware readiness.

Portability is an internal architecture property. If your team cannot demonstrate a working failover from provider A to provider B in a live drill, you do not have portability. You have a paragraph in a master services agreement.

Evaluation is the layer that decides whether the failover works. Without evals that run across providers on your own traces, your team cannot make a confident switching decision under pressure. Under pressure is when the switch has to happen.

The gateway pattern belongs in the reference architecture as a core primitive. It is the reason the AI stack keeps working when the model layer stops. Treat it as the perimeter, not a plugin.

The next Fable 5 will not be a jailbreak on a US model. It will be something else. A data protection ruling. A hostile foreign directive. A court order. An insurance carrier exclusion. A compute contract dispute. The specific mechanism is unknowable. The class of event is now well documented.

The argument for architecting, not buying

This is a moment in the AI cycle where the honest strategic answer is unglamorous. The vendors on stage at every industry conference this quarter will tell you their multi-model platform solves your portability problem. It does not. It moves the problem up one abstraction layer and hides it from you. The three-party risk is still there. You just cannot see it anymore.

Architecting portability is a discipline. It requires an engineering team that can run a live failover drill and know what breaks. It requires a leadership team that treats the gateway, the tool interface layer, and the evaluation harness as strategic assets, on the same tier as the customer data warehouse and the identity system. Every enterprise that survived the Fable 5 window with dignity had that discipline. Every enterprise that scrambled through it was one abstraction layer away, believing they were safe because a vendor said "multi-model" in the pitch deck.

Agor AI Advisory works with companies at exactly this decision point. The right architecture in July 2026 is not more expensive than the wrong one. It is measured in weeks of engineering focus, not tens of millions of capital expense. What it requires is a set of choices the company has probably deferred, because the pitch decks kept saying they did not have to make them. The next third-party event will decide, quickly, which companies made those choices and which ones did not.

The window to architect this before you need it is short. The window to architect it during a fire is closed by definition.

Sources

Want this kind of automation working for your business?

Agor AI designs and ships the systems these posts describe, scoped in weeks, not quarters.

Book a Free Strategy Call