Your AI Vendor Has an Off Switch. You Do Not Control It.
This month the US government ordered Anthropic to cut off all foreign-national access to its two most capable models, Fable 5 and Mythos 5. To comply, Anthropic had to disable both models for every customer overnight, with no warning, by forces it did not control and could not reverse. Access disappeared. Workflows stopped. Teams scrambled to migrate to something, anything, that still worked. If your business runs on a single model you cannot replace in an afternoon, you do not have an AI strategy. You have a dependency, and dependencies get called in at the worst possible time.
The specific event will probably get resolved. That is not the point. The point is that it happened at all, and that it can happen again, to a different model, for a different reason, on a day you did not pick. The companies that felt nothing were not lucky. They were built differently.
What actually happened, and why should you care?
Two state-of-the-art models that a large number of businesses and partner companies had built real work on became unavailable, abruptly, by a government directive made far outside any of their walls. The order targeted foreign nationals, but to comply the vendor had to pull the models for every customer, not just some. The vendor did not choose it. The customers did not see it coming. And the businesses that had wired their operations to those models had nothing to fall back to.
You should care because the trigger is almost irrelevant. It could be a policy decision, a pricing change, an outage, a deprecation notice, a geopolitical line drawn through a map. The category of risk is the same in every case: you do not own the off switch on the intelligence your operations now depend on, and you were quietly counting on a switch that someone else controls.
What is single-model risk?
Single-model risk is the exposure you take on when one model, from one vendor, becomes load-bearing for how your business runs.
The word that matters there is load-bearing. Plenty of companies use one model and are fine, because if it went away they would lose a convenience, not a function. The risk shows up when the model stops being a convenience and starts being structural, when invoices do not get processed, tickets do not get routed, or analysis does not get produced without it. At that point the model is not a tool you use. It is a supplier you cannot operate without, and you have exactly one of them. No procurement leader would accept a single supplier with no backup for a critical input. Most of them are doing precisely that with AI and have not noticed, because it never came with a purchase order.
Why is this risk hiding in plain sight?
Because the thing that makes a model easy to adopt is the same thing that makes it expensive to leave.
You start with one provider because it is the fastest path to results. Then you tune your prompts to its behavior. You wire your context and your tools to its interface. You build workflows around its specific quirks. None of those choices feel like lock-in while you are making them. They feel like progress. But each one raises the cost of leaving a little, until one day switching is not a swap, it is a rebuild, and the rebuild is exactly the project nobody has time for in the middle of an emergency. Lock-in rarely arrives as a decision. It accumulates as a series of conveniences.
What does swap-ready architecture look like?
A swap-ready architecture is one where changing the model underneath is a configuration change, not a rebuild.
The principle is simple to state and is most of the battle. The valuable, hard-won assets are your prompts, your context, your data, and the workflows around them. Those are yours. The model is a replaceable part. So you put your own layer between your operations and any single provider, so that the model sits behind your architecture rather than your architecture being built on top of one model. Done right, swapping providers, or routing different jobs to different providers, or falling back to a privately hosted option when it makes sense, becomes a setting you change, not a quarter you lose.
Notice that vendors are now happy to talk about portability, because portability sells. Treat that as a signal, not a solution. The fact that the word is suddenly everywhere tells you the risk is real. It does not tell you that buying one more vendor's version of portability fixes it. The fix is structural and it lives in your architecture, not in their marketing, which is precisely the kind of unglamorous foundation work that separates the companies that shrugged off this month's disruption from the ones that lost a week to it.
What should you do about single-model risk?
Run a fire drill. Assume your primary model goes dark on Monday morning, no warning, no timeline for return. Then answer three questions out loud. What stops working immediately. How long until you have something else running in its place. And how much of that switchover is configuration versus how much is a rebuild.
If the honest answer to the second question is measured in weeks, and the honest answer to the third is mostly rebuild, you have just found the most important AI project on your roadmap, and it has nothing to do with adding capability. It has to do with making sure the capability you already depend on cannot be taken from you on someone else's schedule. The model is rented. Your ability to keep running when the rental ends has to be owned.
YOR.AI builds AI systems where the model is a replaceable part, so a change of provider is a configuration change and not a fire. If your operations are quietly load-bearing on a single model and you want a swap-ready architecture underneath them, reach us at contact@theyor.com.