The first time I watched a production system go dark because of a government order, I was holding a coffee I never finished. A platform team I advise woke up to 401s across every call to a closed frontier model they'd built three years of workflow on top of. Not a rate limit. Not an outage. Access revoked, globally, overnight, because AI export controls reached into the provider's account and pulled the model offline for everyone. No migration window. No deprecation notice. A blog post and a wall.
If you're a CIO or a technical lead with real money riding on a single closed API — and if you built around something like Fable 5 or its siblings, you are — this is the lesson nobody put in the architecture diagram. Your dependency isn't just a vendor. It's a vendor whose product can be switched off by a third party you never signed a contract with.
I'm not here to tell you the regulators are wrong or right. I'm here because the people who sell you the model don't talk about this, and the people who write the compliance memos don't run your inference. Somebody has to sit in the middle and say plainly: this is a design problem now, and you can solve it like one.
What most people do
Most teams treat a frontier model API the way they treat the electricity in the building. It's there. It bills monthly. You wire everything to it and you stop thinking about it. I did this too, for a while, because the economics are seductive — the best model, no GPUs to babysit, no fine-tuning ops, a clean SDK, and a roadmap that keeps getting better while you sleep.
So the workflows get deep. Not just a chat box. Document extraction, internal agents, the thing that drafts customer responses, the classifier that routes tickets, the pipeline that summarizes contracts before legal sees them. Six months in, the model isn't a feature. It's load-bearing. And the prompts are tuned to its specific quirks, its specific refusal patterns, its specific token behavior, so swapping it out is no longer a config change. It's a project.
Here's the part most people genuinely don't price in: they assume the only failure modes are commercial or technical. The provider raises prices, you negotiate. The provider has an outage, you wait it out, SLA credits arrive. Both of those are recoverable because both of those are the provider's decision. What almost nobody plans for is the third party — a government deciding, for reasons of national security or trade policy that have nothing to do with your business, that a specific model may not be served. When that happens, your provider isn't negotiating with you. They're complying with someone above them, and you're downstream of a decision you can't appeal.
That's the gap. People model vendor risk. Almost nobody models regulatory revocation as an operational event with a runbook attached.
What the evidence suggests
This already happened, more than once, and the pattern is what matters.
In March 2026, the Department of Defense abruptly cut ties with a major frontier AI provider. That was a procurement decision — government as customer walking away — but it taught a specific lesson: the relationship between frontier AI and the government is not stable, and a provider you consider best-in-class can become persona non grata in a department's stack with little warning. Plenty of enterprise leaders read that as a story about the Pentagon. It was actually a story about how fast the ground can move.
The Fable 5 and Mythos 5 blockade was the harder version of the same lesson. This time it wasn't a customer leaving — it was the government compelling the provider to stop serving specific models to everyone, citing export-control concerns. The provider, to its credit, was upfront that it was acting on an order and didn't fully detail the rationale, which tells you something: even the company serving you may not be able to give you a clean explanation, because the reasoning lives in a classified or sensitive lane they're not allowed to narrate.
Strip away the names and the syllogism is plain. A government can compel a closed-API provider to stop serving a model. It has done so. The trigger can be a security incident, a trade-policy shift, or a classified determination you'll never see. Therefore: any single closed model, no matter how good, is access you rent under terms that can be rewritten by a party you don't control. That's not a knock on the provider. The best engineering org on earth cannot honor an SLA that a regulator has voided.
The evidence doesn't suggest you should flee closed models. They're often the best tools available, and that's a real advantage you'd be foolish to throw away out of fear. The evidence suggests you should stop treating their availability as a constant in your equations and start treating it as a variable with a non-zero chance of going to zero on any given morning.
What I actually do
I run a hybrid posture now, and I treat it as plumbing, not philosophy. Three concrete things.
I put an abstraction layer between my application and any model. Nothing in the business logic calls a provider SDK directly. Everything goes through an internal interface — a thin gateway that takes a request and decides which model serves it. This is unglamorous work and it pays for itself the first time you need to reroute traffic without a code freeze. If your prompts are welded to one provider's exact behavior, you don't have a product, you have a hostage situation.
I keep a working fallback I have actually tested under load. Not a sticky note that says "we could switch to another vendor." A second provider, or an open-weights model I host myself, that real traffic has flowed through in a drill. The closed frontier model handles the work it's best at on a normal day. The fallback exists so that "the primary is gone" is a degraded-mode event, not an outage. A degraded answer your customers still get beats a perfect answer they can't reach.
I keep at least one genuinely sovereign option — a model whose weights live on infrastructure I control. It will not be as sharp as the frontier model. Accept that trade. The point of a self-hosted open-weights model is not parity. It's that no order from any government can reach into my account and pull it, because there's no account to reach into. For the workflows that absolutely cannot go dark — the ones tied to revenue or to a regulatory obligation of my own — that's where they live, or where they fail over to.
Here's the trade laid out honestly:
| Posture | Capability | Availability you control | When I use it |
|---|---|---|---|
| Single closed API | Highest | Lowest | Never for anything load-bearing |
| Closed primary + closed fallback | High | Medium | Most workflows |
| Closed primary + self-hosted fallback | Mixed | High | Revenue- or compliance-critical paths |
| Self-hosted only | Lower | Highest | The few things that must never stop |
The honest cost is real. The abstraction layer is engineering time. The fallback is duplicated integration work. The sovereign option means you own GPUs or a hosting bill and the ops that come with them. I'm not going to pretend that's free, because the people who pretend resilience is free are the reason you got blindsided in the first place.
Your next step tonight
Open the system that would hurt the most if its model vanished before morning. Answer one question on paper: if that exact API returned 401 for the next two weeks, what happens to the business? If the answer is "we stop," you've found the workflow that earns a fallback first. Don't boil the ocean. Pick the one that bleeds and start there.
You didn't get into this mess because you were careless. You got into it because the tooling rewarded centralization and nobody drew the regulator into the threat model. That's fixable, and it's fixable by you, with the same skills that built the dependency.
The rule of thumb: if a model going dark tonight would stop your business by morning, it doesn't get to be your only model.
