So, Fable is back (for a while), and its disappearance and reappearance has triggered a lot of buzz about what it means to be dependent on one model or one provider. The standard wisdom, which sounds obviously true, is that we should build LLM-agnostic harnesses and workflows and plumbing that allows trivial swapping between them.
On the surface, that's easy to do: there are over 400 models on OpenRouter, which itself supports failover and other types of complex routing. You can set up the excellent LiteLLM to not only route to any model, but conform them all to the same API surface, saving a bunch of abstraction/implementation in your apps. This lets you route requests to different hyperscalers without a single vendor dependency - so if GCP's models are down, you can seamlessly switch over to AWS, etc.
But in practice, in Australia (where I operate — can't speak to the rest of the world), many organisations are not doing this. They are going heavily in on "strategic partnerships" with one provider (usually either one of OpenAI and Anthropic, and then a specific hyperscaler). Their AI agents are tightly coupled to a particular model provider (usually via the hyperscaler's model gateway because that is the reference pattern, but with only a small subset of models selected/enabled).
But why?
Understanding risk and diversification
With any handling of risk or its mitigation, you have to be clear about the most basic undesirable events you are talking about. This concept carries across most risk management disciplines: lawyers call them "heads of risk", actuaries call them "perils" and the cybersecurity folks call them "threats". Each one is an event - "a thing that can happen". It has a frequency, and a severity or impact. Sometimes, instead of frequency, people talk about likelihood over a fixed time horizon - this is just the integral under frequency, over exposure and time (same concept, different mathematical entry point). Severity is often expressed in "dollars of damage", which if you're my age might remind you of the bonus rounds in Street Fighter 2, where you had to smash up a car and every hit caused some dollar figure to float away.
In the case of LLM providers, there are a few risks worth discussing.
Technical outage
The most mundane, this is just error 503 on the API - "we are experiencing a high volume of requests", or "this service is temporarily unavailable" etc. If you have built anything with LLM APIs, you will know this happens a lot more often than you would expect from top-tier hyperscalers. Diversification of providers and failover routing is a sound approach to mitigating this.
However, we are mostly talking about getting the same model from different vendors here, for reasons that we'll cover later. So if Claude Sonnet is down on GCP, hitting the Bedrock API instead.
Unauthorised data access, excluding governments
This one is arguably less about API inference (although it can apply there too), and more about control plane and data storage. The usual mitigations here are vendor audits, certifications (SOC 2 Type II), encryption at rest of your data, and so on. Most of the top-shelf providers you could name do this. It's hard to argue you're better off with one hyperscaler over another (although in the early days of OpenAI, it clocked 2 breaches — which was a significantly worse track record than, say, Azure offering the same models at the time).
Diversification makes this risk worse, not better, because instead of auditing one provider you have to audit multiple, your resources for doing so are fixed, so necessarily the quality of your diligence will suffer. It's much of a muchness though, for most "serious" providers, it's all on trust anyway. No one I know has carried out a physical compliance audit of an AWS datacentre for themselves.
This is very relevant to AI startups though, whose risk posture is a lot more slanted towards growth than stability, and often fails to pass a test aligned to a large enterprise's risk appetite.
Sovereignty risk
This one comes in two types: unauthorised access by governments, and government-induced outage.
Unauthorised access by governments is usually through lawful (in their country) means. I still call it unauthorised because your organisation did not authorise it. For example, if the Chinese government compels DeepSeek to both log your prompts without telling you, and hand them over to their intelligence services on request, you didn't authorise that access. But neither is the Chinese government "hacking" DeepSeek - they are using means that are lawful in their jurisdiction. Cybersecurity hardening mostly makes no difference here, and nor do contractual provisions (can't contract away statutory obligations).
Similarly, if the US Government compels a model provider to take down a particular model, like recently happened with Fable 5, that's different to a technical outage. Diversification across providers doesn't help here, because if ordered to take down a model, all providers governed by that jurisdiction are obligated to comply all at once. Diversification across geographies may be possible, but usually implies different models.
"Models are just commodity infrastructure, like plumbing"
This view has come up a lot online recently, in threads discussing the events of Fable 5 and advocating for model-agnostic architectures. In practice, most people who have built solutions spanning multiple models know that, in unguided, non-interactive use, simply switching one model for another (e.g. flicking a switch in LiteLLM) almost never works. Prompts end up tailored to a particular model, and switching normally requires significant rework of prompts and sometimes even orchestration (e.g. one model might have been fine under open, LLM-guided orchestration for a particular task, but another may be too unreliable and need deterministic orchestration for the same task).
This, of course, can be designed and built in from the start - but it's a question of investment. How much do you front-load the cost of being able to switch instantly from Opus to GLM 5.2 or Qwen? What if you never need to, in the timeframe when GLM 5.2 is still relevant? What would be the damage of having to do it under duress during an outage (across all Opus providers)?
The illusion that it is as easy as changing the model selected by config comes from lack of real-world experience. Just like with plumbing (which is another word often used to describe LLMs now) - pipes are pipes but if you switch from LNG to Butane, it won't just work. You have to change the nozzles on your burners too.
What are you really diversifying (in Australia)?
If you are an Australian company with obligations regarding data storage and/or processing happening onshore, your choices of models when "diversifying" across providers aren't as diverse as the narrative makes out.
Let's look at the case of onshore processing, as this is a narrower field. The latest, most capable model offered in-region by GCP is Gemini 1.5 - approx. 2 years old now, and frankly not very good in 2026. On Azure, it's GPT-4.1 or 4o depending on exactly how you access it, unless you pay for provisioned capacity (PTUs). AWS is the only frontier offering, with Opus 4.8, Sonnet 4.6 and Haiku 4.5.
If you are OK with offshore "zero retention" processing, but require local storage, then your options are slightly broader: any of the cloud providers, plus ChatGPT Enterprise. But you are not really diversifying the sovereignty risk, since all that offshore processing happens in one country.
If you are building agentic systems, the common advice you hear is "build for the model you expect in 6 months" - if something is just out of reach of a model's capability today, it will be achievable by the time you finish building, and give you a strong (not obsolete) product right out of the gate. That rules out starting on a 2-year-old model.
You can, of course, build against open-weights models — at least those can't be taken away once given (although a common misconception is that Chinese firms will continue to release better and better open models — 6-12 months behind the frontier — forever... they can stop future releases anytime and will have less incentive to do so as future US releases get more closed through more stringent guardrails). But they are 6-12 months behind, and all of the performant ones also come from one country (the ones that don't are even further behind).
There is also Mistral, a seldom-considered alternative that does legitimately come from France, i.e. not the US and not China. However, the number of Australian companies I've come across who are using Mistral so far is ... a very small, round number.
The true cost of model-agnostic builds
So the net result of this discussion:
- You should build ahead of the current model capability, which means you are building against a frontier model
- That gives you a limited set of options, which you can diversify against provider risks, but not sovereignty risks. The rest of the world has more options, but compliance requirements preclude many of those for Australian companies
- All of those options relate to one country, and one sovereign government - and can be taken away anytime as we recently saw
- By not using the frontier models (and using e.g. open weights models instead), you are paying two additional costs:
- Extra prompt and harness engineering to compensate for weaker model capability, times the number of alternative models you use — your choice whether you pay that upfront or when the risk materialises
- Commercial risk of designing around an outdated capability frontier, making it more likely the differentiation in your product will be swallowed by frontier general purpose models at next release
What is the right strategy? It depends; there is not a one-size-fits-all answer. But at least we can start to properly recognise and understand the risks and trade-offs.