Anthropic shipped Claude Fable 5.1 this week. It is the same model as Claude Mythos 5.1 with a different set of safeguards, and Mythos stays behind trusted-access programs for a set of US organisations. Fable is the version the rest of us get, and by Anthropic’s own benchmarks it is the most capable model they have released widely.
The two previous launches in this series each broke something in my setup. When Fable 5 landed in June, my routing table needed a new top tier, and the disciplined move was to route down, not up. When Opus 5 landed in July, half my instructions turned out to be compensations for weaknesses that no longer existed, and the work was deleting them.
This time I went looking for the thing that broke, and the routing table was not it. Fable 5.1 sits in the same tier as Fable 5 at the same list price: ten dollars per million input tokens and fifty per million output. The line between advanced work and frontier work, which I drew against that price in June and redrew against Opus 5’s price in July, does not move. For the first time in this series, nothing in my routing table changed.
Everything that changed sits around the model. That is the story, and it is a better story than a benchmark.
Four changes, none of them in the model’s weights
The discount is conditional. Anthropic estimates Fable 5.1 costs about a quarter less than Fable 5 on typical workloads and nearly half less on highly agentic ones. Not one cent of that comes from the list price. All of it comes from cache reads, which dropped to a quarter of a dollar per million tokens. A cache read happens only when the start of your request is byte-identical to the previous one: the same system prompt, the same tool list, the same records in the same order. A setup whose context is assembled fresh and differently on every call pays full price for the same model. The saving is a property of how stable the layer around the model is.
The transcript became append-only. Fable 5.1 introduces what Anthropic calls preserved thinking. Each thinking block is bound to the conversation that produced it, and editing, reordering, or deleting an earlier turn invalidates every block after it. New accounts created from launch day onward are enforced now, and the migration guide says future models will enforce it for everyone. Anthropic’s reason is anti-distillation. The consequence for a builder is the same either way: a harness that rewrites its own history breaks, and a harness that only appends keeps working. If that rule sounds familiar, it is the one this blog has been arguing for business records since August. A correction ledger is append-only for a different reason, and now the model’s own transcript is too.
You can no longer force a tool call. Telling the API that the model must call a tool, or must call this particular tool, now returns an error. The replacement is an instruction in the prompt, a strict schema on the tool, or structured output when the forced call only ever existed to get JSON back. One line of my own harness broke on this: the Anthropic adapter in my LLM library forces a tool call whenever a caller marks tools as required. That line was written for a model that needed forcing. This one does not, and refuses it.
A refusal is a stop reason, and the fallback is a policy. Fable 5.1 can decline a request on safety grounds, and it does so with a normal response whose stop reason says refusal. A harness that reads the content without checking the stop reason treats the refusal as an answer. Anthropic also ships an opt-in fallback that reruns a declined request on a different model by category. In its own testing, cyber tasks completed on Opus 4.8 and biology tasks on Opus 5. Read that twice. The vendor now treats “which model answered” as a governed decision made after the request went out, not a fixed fact you set in a config file.
Four changes. A cache rule, a history rule, a tool-call rule, and a refusal rule. Not one of them is a capability. All four are contracts between the model and the layer around it.
The layer that did not move
Here is the part I can only report from my own setup.
In June, less than a month after launch, Fable 5 went offline under an export-control directive. The directive was lifted at the end of the month, and my own access came back in late July. In between, on July 12, I wrote an operating manual for working on Opus instead: eight procedural rules covering how to scope a task, what evidence a claim needs, when not to overwork a simple job, how to recompute a number rather than repeat it, and when to stop.
The file is still called fable-to-opus. Its header now says the method outlived the occasion. The model went away, came back, and this week shipped a new version, and the manual did not change, because it was never about the model. Neither did the routing rules in my global instructions: the frontier tier is earned by the nature of the work, a delegated task names its model tier explicitly rather than inheriting the session’s, and a verification claim is not evidence unless something actually ran. All three held through three launches.
What did break was one line in a harness. That is the pattern worth noticing. Across three launches the maintenance keeps landing in the same place: the routing table, the instruction layer, the harness contract. Never the business truth, never the rules, never the records of what was checked and who approved it. The maintenance lands in the part around the model, and the part you own is the only part that was ever going to compound.
What this means if you run a business rather than build one
You do not have a harness, but you have the same layer, and this launch is a chance to see it.
A stronger model produces better candidates. It does not know your current price, the claim you retracted in March, or which of last month’s drafts you sent back and why. If those things live in a prompt file you paste into each session, a better model reads the same prompt file and makes the same mistake more fluently. If they live somewhere the next draft can be checked against, the upgrade touches nothing you own, because nothing there had to change.
Anthropic’s launch page is full of customer quotes about unattended work: a 38-hour run, a prototype whose next phase was finished by morning, a team saying the model is more comfortable with long, unattended work than its predecessor. That is real. It also means the model can now produce far more than one person can responsibly review, which moves the bottleneck to exactly the layer this article is about. More output is only useful when something other than your attention decides most of it.
Try this now (10 minutes)
Run the experiment the launch makes cheap.
- Pick one correction you have made to an AI draft more than once this month. A price, a positioning claim, a rule about how you open an email, a thing you never promise a client.
- Switch to Fable 5.1, or to whichever model is new for you, and ask for the same kind of draft.
- Watch whether the correction comes back.
If it comes back, you have learned where the problem is not. It is not in the model, because you just changed the model. It is in the absence of a place where the correction lives and a check the next draft can fail against.
If you build with AI, add a second experiment. Search your harness for forced tool calls and for any code that rewrites conversation history between requests: reminders you inject and delete, tool lists you rebuild mid-session, compaction that keeps recent turns verbatim. Each one is now a contract violation. The fixes are all append-only forms, and the migration guide lists them. That is the software-engineer track version of the same afternoon.
Where to go next
The two earlier launch posts carry the routing argument and the instruction argument: route down, not up and half the instructions in your setup just expired.
The append-only rule for business records is the correction ledger, and the record of what was checked and who approved it is the audit trail.
Why a stable, well-placed context beats a large one, with Anthropic’s own numbers, is in context is an architecture problem.
And if the correction came back in the experiment above, The Three Fixes turns one recurring correction into a rule, a hold, and a retirement condition. That is the smallest version of the layer that did not move.
Frequently asked questions
What is Claude Fable 5.1 and how does it differ from Claude Mythos 5.1? They are the same model with different levels of safeguards. Fable 5.1 is generally available with standard safeguards. Mythos 5.1 is available only through Anthropic’s trusted-access programs, currently to a set of US organisations, with safeguards designed for cybersecurity and life-sciences work. Fable 5.1 is Anthropic’s most capable widely released model, with a one-million-token context window and list pricing unchanged from Fable 5.
Is Fable 5.1 cheaper than Fable 5? The list price is unchanged. Anthropic estimates typical workloads cost about 25 percent less and highly agentic workloads about 45 percent less, and the entire saving comes from cache reads, which now cost a quarter of a dollar per million tokens. You collect the saving only when the start of each request is identical to the previous one, so it rewards a stable system prompt, a fixed tool list, and records loaded in a consistent order.
What breaks when I move code from Fable 5 to Fable 5.1? Three things. Forced tool choice returns an error, so tool calls are steered by instruction, strict schemas, or structured output instead. Thinking blocks are bound to the model that produced them. And thinking blocks are bound to the conversation that produced them, so editing, reordering, or deleting earlier turns invalidates every later block. New accounts are enforced from launch day; Anthropic says future models will enforce it for everyone.
Should I switch my whole setup to Fable 5.1? Route the work, not the setup. Fable 5.1 sits in the same tier at the same list price as Fable 5, so the same rule applies: reserve it for genuine invention and long-horizon agentic work, and keep routine work on cheaper tiers. The more useful move this week is the experiment above. Switch one workflow and watch whether your recurring correction returns, because that tells you whether your problem was ever the model.