Every failover plan rests on an assumption you never notice until it breaks. The backup is equivalent to the primary. Networks honour that assumption. Models do not, and they fail it in two different ways. One is obvious once you see it. The other is the one that will actually hurt you.
In networking we spend real effort making the assumption true. A redundant path carries the same packets as the primary. When it takes over, nothing downstream can tell. That is the entire point. You design the backup to be indistinguishable, you probe it to confirm it stays that way, and a clean cutover is one nobody notices. Equivalence is not a nice property of the design. Equivalence is the product.
Two kinds of redundancy
Reliability engineering has always had two answers to a single failure, and they are not the same answer.
The first is replication. You run identical copies. They protect you against random, independent faults, a power supply that dies, a link that is cut. They do not protect you against a fault in the design itself, because the flaw sits in every copy at once. Engineers have a name for that. Common-mode failure. It is the exact failure replication cannot touch.
The second is design diversity. You build deliberately different implementations of the same job, hoping they do not share the same flaws. Avionics and nuclear protection systems have leaned on dissimilar implementations for decades, precisely because identical copies share identical blind spots.
A backup network path is replication. It is meant to be a copy. A backup model cannot be. It refuses different requests, formats output differently, and reasons its way to different answers. Whether you intended it or not, model failover is design diversity, not replication. The trouble is that almost everyone is managing it with a replication mindset, expecting an invisible cutover from something that was never a copy.
The difference leaks upward
That is the first violation, and it is the visible one.
Because a backup model behaves differently, the change does not stay in the infrastructure layer where you put it. It travels all the way up. Prompts tuned for one model now hit another. A parser that expected one shape gets another. Output calibrated against one set of refusals meets a different set. Users who were talking to one correspondent now talk to someone else with a different voice. None of that was visible at the layer where you made the swap.
A network cutover is silent. A model cutover is a product change, shipped mid-incident, with no review, at the worst possible time. You did not restore service. You replaced the thing under the service and hoped no one downstream would mind.
Diversity is not independence
Here is the second violation, and it is the one the design-diversity tradition already warned us about.
The whole appeal of diversity is independence. Different implementations, different faults, so whatever takes one down leaves the other standing. In 1986 Knight and Leveson tested that assumption directly. They had independent teams build the same program, and the versions failed together far more often than independence would predict. The reason was simple and unwelcome. The hard cases are a property of the problem, not of the implementation. Different builders still trip on the same hard inputs.
Frontier models are that result at scale. They are trained on overlapping data with similar methods, so they share blind spots and they share classes of jailbreak. The thing one frontier model finds hard, the next one tends to find hard too. Swap one for another and the behaviour changes completely, which feels like independence. It is not.
Fable is the live example. According to the Wall Street Journal, Amazon researchers flagged a jailbreak to the US government. Anthropic disputes how serious it was. For redundancy it does not matter who is right. What took the model offline was not a serving fault you could fail away from. It was an export-control directive, and it pulled Fable and its sibling Mythos down together, the same model class, on one order, at the same instant.
The rest of the lineup stayed up, so a same-vendor fallback happened to work. That was the shape of this particular order, not a guarantee. The thing to design around is the reach, not the outcome. An authority that can take two models on one letter can take the next one beside them, and brand does nothing to stop it.
You bought a second path and ran it through the same trench. It looks different, and it dies together.
Diversify the axis that actually fails
This is the part worth designing for, because it is where most fallbacks are quietly wrong.
Independence does not come from variety you can see. It comes from varying the dimension that actually takes you down. If your real exposure is regulatory, a behaviourally similar model in a different jurisdiction buys you more than an exotic model that shares your primary's jurisdiction. If your real exposure is a shared blind spot or a shared class of jailbreak, then a different vendor logo over the same kind of model buys you almost nothing, and you need genuine architectural difference instead.
Most teams diversify on brand. Brand is the axis that buys the least. Match the diversity to the failure you are actually exposed to, or you are paying for independence you do not have.
The test
So before you call anything a fallback, run the test, and make it sharp. Name your backup model. Name the most likely reason your primary disappears. Then check whether that same reason takes your backup with it. If it does, you have not built redundancy. You have a copy with a different accent, sitting in the same trench, waiting for the same letter.