On the thirteenth of June, Anthropic published a statement about a US government directive to suspend access to Fable 5 and Mythos 5. The models went offline worldwide. The directive was lifted eighteen days later.
The politics of that are above my pay grade and outside what this journal is for, so I will stick to the engineering question.
What would eighteen days do to what you have built?
Three companies, same outage
Company A had wired one provider directly into their product path. Their feature was fully down for eighteen days, with a support queue and a public status page.
Company B had an abstraction layer and a second provider configured. They switched in an afternoon and shipped a quality regression they are still tuning out, because prompts do not port cleanly and nobody had ever run the eval suite against the fallback.
Company C had the same abstraction and ran their evals against both providers monthly. They switched in an hour, took a small measured quality hit they could quantify, and told their customers exactly what changed.
B and C had the same abstraction. C had tested the thing they were relying on.
An untested fallback is a belief
This is the general form and it is older than AI. A backup you have never restored from is a hope. A failover you have never failed over to is a story you tell in the architecture review.
The abstraction layer makes you feel safe, which is what makes it dangerous. It converts an unknown risk into a felt certainty without changing the underlying facts.
The cheap version of the fix
A full multi-provider strategy is expensive, and most teams should skip it.
You need to have run the fallback once. Point the thing at the fallback, run your evaluation set, write down the number, and put that number somewhere a decision-maker will find it during an incident. Now the fallback is a known quantity.
That is an afternoon of work, and it converts eighteen days of outage into eighteen days of degraded service.
Anthropic's statement is here. Go and find out whether your fallback has ever run.
One email when we publish. Research, product decisions, and what teams report back.
