On 9 June Anthropic released Claude Fable 5, the first public version of its Mythos model. We made it our Flight Plan model within days: the model that reads a workshop transcript, drafts the reverse brief and argues with us about the architecture. It was slow and it was expensive, at $10 per million input tokens and $50 per million output, double Opus 4.8. It was also the best reasoning we had used.
On 12 June the US government added Mythos and Fable to its export-controlled technologies list, requiring a licence before either could be provided to foreign nationals. Anthropic said complying at that scale was impractical and pulled public access the same day. Eighteen days later, on 30 June, the Commerce Secretary announced the restriction was lifted, and on 1 July Fable 5 came back.
We are foreign nationals. This post is about what we did for eighteen days and what it changed in how we design client systems.
What Actually Happened
The trigger was a real finding. Researchers at Amazon found a way to prompt Fable 5 past its safeguards into identifying software vulnerabilities and, in one case, producing code that exploited one. Anthropic's public response was blunt: it disagreed that "the finding of a narrow potential jailbreak should be cause for recalling a commercial model deployed to hundreds of millions of people". Security researchers quoted in the press suspected the restriction was as much political as technical. Either way, the access was gone.
The model that returned on 1 July is the same model behind a new classifier. Anthropic says it blocks the reported bypass in over 99 percent of cases and reroutes anything it flags to Opus 4.8. It also warns that the classifier may catch benign requests during routine coding and debugging. Included allowances came back too: up to half of a subscriber's weekly limit through 7 July, then usage credits. Availability through AWS, Google Cloud and Microsoft's cloud is promised without a date.
Eighteen Days Without Our Planning Model
Here is what we learned, in the order we learned it.
Nothing broke, because nothing in production depended on it. Every AI feature we ship for a client runs on models behind an abstraction, mostly Amazon Bedrock, with the model name in configuration. Fable 5 had not made it into any client's production path yet. That was luck as much as policy. It is now policy.
Our own workflow was the weak point. The Flight Plan process had quietly grown a dependency on one model's judgment. The first workshop synthesis after 12 June ran on Opus 4.8 and was fine. Not the same, but fine. The difference was in the arguing, the part where the model pushes back on a scope decision, and that was where we had come to rely on it.
Fallback is a design, not a setting. Swapping a model is easy. Knowing whether the swap is acceptable is not. We had no written way to answer "is Opus good enough for this step?" beyond reading the output and shrugging. We do now, and it is the most useful thing to come out of the whole episode.
What Changed in Our Architecture Overviews
Every Flight Plan now produces an architecture overview with a section that did not exist in May.
No model names in promises. A proposal describes a capability and a quality bar, never a specific model. "The assistant summarises a support ticket to a standard our eval set defines" is a promise we can keep through an outage. "Powered by Fable 5" is not.
A named fallback chain per capability. For each AI step in a system, the overview lists the primary model, the fallback, and the fallback's fallback, with the conditions for moving down the chain. For most reasoning-heavy steps right now that reads Fable 5, then Opus 4.8, then Sonnet 5, which Anthropic shipped on 30 June at $2 and $10 per million tokens with agentic coding scores close to Opus. Sonnet 5 uses a new tokenizer that produces around 30 percent more tokens for the same text, which is exactly the kind of detail a fallback plan has to carry, because it moves the cost line.
An eval set from the acceptance criteria. The Flight Plan already defines what "working" means for each feature. We now turn those criteria into a small test set that any candidate model runs against. A fallback is acceptable if it passes. That replaces the shrug.
Classifier variance in the tests. A model that reroutes flagged requests to a different model produces different output for the same input depending on what a classifier decided. For coding assistants that is fine. For anything customer-facing it needs a test that checks the output, not the model that produced it.
Budgets that survive a swap. Each rung of the chain has a different price and a different token count for the same work. Cruise & Maintenance cost guardrails are now set per capability, with the ceiling calculated on the most expensive rung the chain allows.
The Uncomfortable Part
There is a geopolitical layer to this that a studio in Australia cannot design away. The most capable models are American, the restrictions are American, and "foreign national" is us. We do not think that argues for avoiding those models. It argues for treating availability as a risk with a probability and a plan, the way we already treat a cloud region going down.
For a founder, the practical question is whether the person building your product has thought about this. Ask them what happens to your assistant if its model disappears for three weeks. If the answer is a shrug, that is your risk, not theirs.
Where We Are Now
Fable 5 is back in our Flight Plan workflow, behind a classifier we are watching for false positives on ordinary debugging. Opus 4.8 stays warm. Sonnet 5 is doing more implementation work than we expected, and the cost line shows it. And every architecture overview we produce from here carries a fallback chain, because the next eighteen days could come from a regulator, an outage or a pricing change, and the design should not care which.
Want a Product That Does Not Depend on One Model?
At Dev Force One, the architecture overview in every Flight Plan now names a fallback chain and an eval set for each AI capability, so your product keeps flying when a model does not.
What you get:
- Model-agnostic design: capabilities and quality bars in the proposal, model names in configuration
- A tested fallback chain for every AI step, with the cost of each rung in the budget
- Cruise & Maintenance guardrails that hold through a swap, an outage or a price change
Building something with a model on the critical path? Book a Pre-flight call and we will show you the chain.