Claude Fable 5.1 succeeds Fable 5 in the same tier, at the same per-token price, with the same 1M token context window and the same tokenizer. Existing Fable 5 prompts are expected to work as they are. On the surface this is a point release.
Underneath it there is a change worth understanding even if you never call this model, because it says something about where long-running agents are going: the transcript of a session has stopped being a scratchpad you can quietly rewrite.
First, the thing most write-ups skip: it is not the default upgrade
Anthropic's own guidance is that Opus 5 remains the target for a general "move to the latest model" request. Fable 5.1 is positioned for demanding reasoning and long-horizon agentic work, or for when your evaluations on Opus 5 at higher effort still fall short.
The price difference is the reason to take that seriously rather than treat it as modesty. Fable 5.1 is $10 per million input tokens and $50 per million output, against $5 and $25 for Opus 5. You are choosing to pay double, and the case for it has to come from your own evaluations rather than from a tier name.
It also gives things up. There is no Priority Tier on Fable 5.1, and it is a Covered Model: 30-day retention is required, and it is not available under zero data retention unless Anthropic expressly authorises it. If your organisation runs ZDR, that is a procurement conversation, not a config change.
What actually got better
The improvements over Fable 5 are concentrated in six areas, and the gap is widest at the higher effort levels:
- Agentic coding over long sessions: multi-file features, large refactors and migrations, debugging and review across sessions that run for hours rather than minutes.
- Knowledge work with documents, spreadsheets and slides, from a first question through to a finished deck or a live-formula spreadsheet built from nothing.
- Multistep research and search, where the model follows up on what it finds rather than running one query and stopping.
- Vision on dense material: charts, filings and tables nested inside PDFs. It is strongest when it has tools to crop and zoom rather than being handed one flat image.
- Retrieval deep inside the 1M context window, and computer use, where the improvement is less about doing the step and more about recovering from a step that failed.
Multilingual performance is described as on par with Fable 5 rather than better. That is a useful kind of honesty in a release note, and worth noticing because it tells you the gains are aimed at long autonomous work specifically rather than spread evenly.
The price is identical except for one number, and that number matters
Input, output, cache writes and batch pricing are all unchanged from Fable 5. Cache reads dropped to $0.25 per million tokens, which is a quarter of the Fable 5 rate and half of Opus 5's.
Every other current model prices a cache read at a tenth of its base input rate. Fable 5.1 prices it at a fortieth. That is not a rounding adjustment, it is a statement about the workload the model is for: a session that runs for hours re-reads the same prefix on every single turn, and the cost of doing so has been cut sharply.
The second-order effect is the one to plan for. When a hit is that cheap, a miss becomes proportionally far more expensive, so keeping the cache warm stops being hygiene and starts being the main cost lever. Two of the new features exist largely to avoid resetting it.
Three breaking changes, and the third one is the interesting one
The first two are small. Forced tool use is gone: asking for a specific tool with tool_choice now returns a 400, and you steer with an instruction plus strict schemas instead. And thinking blocks are bound to the model that produced them, so if a request routes to a different model, the API silently drops the reasoning rather than passing it along.
The third is a genuine change in what a conversation is. A thinking block's signature now records the conversation prefix that produced it: the system prompt, the tool set, and every message before it. When the transcript comes back, the API checks that prefix is unchanged. Edit an earlier turn and every thinking block after it is invalid.
Concretely, all of these now break a session: rewriting the system prompt between requests, rebuilding the tools array, deleting old tool results client-side, snipping a turn out of the middle, and injecting a per-request reminder that you remove on the next call. Every one of those is a normal thing for a harness to do, and none of them raised an objection on previous models.
Who this bites, and when
If you use Claude Code, claude.ai, Managed Agents or the Agent SDK, the harness keeps the prefix intact for you and there is nothing to do. If your code assembles the messages array itself, this is the part of the migration to budget time for.
Enforcement is staged rather than universal. Accounts created on or after 31 August 2026 are enforced now. Older accounts have the mismatch recorded but not acted on unless the request opts in, which is also how you test from an organisation that is not yet enforced. Anthropic has said it plans to enforce it for everyone on future models, so an older account is a reprieve rather than an exemption.
There is a detail worth knowing if you ship a tool other people run with their own API key: your users on new organisations are enforced before you are. Your integration can be broken for them while passing every test you run.
The migration itself is mechanical once you accept the rule. Freeze the system prompt and append a system message where the change becomes true. Declare the full tool set up front and change it with tool-change blocks. Use server-side context editing or compaction instead of deleting turns yourself, since neither counts as an edit. Leave per-turn reminders in the history rather than removing them.
What you get in return
Three additions, all behind beta headers, and the first two are direct answers to the constraint above.
Per-message effort lets you change the effort level mid-conversation with a system message rather than a new top-level value, so a single session can spend heavily on the hard step and cheaply on the routine ones without resetting the cache. Turn-scoped system messages solve the per-turn reminder problem: mark one to clear at the next user message and it renders once, then stays in the transcript costing nothing, so nothing earlier ever changes.
The third is a user-experience fix. Fable 5.1 writes fewer user-facing updates during long tool-calling turns than Fable 5, which means an agent can go quiet for minutes. It is still writing short progress notes between tool calls, but they arrive as thinking blocks, and the default setting returns those empty. Asking for progress updates explicitly turns the silence back into a status line.
That last one is worth calling out because it presents as a regression and is really a default. If you have a harness that felt chatty on Fable 5 and feels dead on 5.1, this is almost certainly why, and the second step is to delete the prompt text you wrote telling older models not to narrate.
Should you move?
If you are on Fable 5 and your harness is already append-only, this is close to a free upgrade: same price, better long-session behaviour, and cache reads at a quarter of what you were paying.
If you are on Opus 5, the honest answer is probably not yet. You would be doubling your per-token cost, giving up Priority Tier and ZDR, and taking on the history rule, and the case has to come from your own evaluations rather than from the release notes. The guidance in Anthropic's own documentation is to reach for Fable only when Opus 5 at higher effort has already been measured and found short.
One number does complicate that, and it is worth testing before deciding: at low effort, Fable 5.1 is described as often competitive with Opus and Sonnet on cost per completed task while performing better. Cost per task is not cost per token. A cheaper request that needs three more turns to finish the job was never cheaper.
The part that generalises
Strip out the version numbers and this release is about one thing: work that runs for hours instead of seconds. The capability gains are in long sessions. The pricing change rewards holding context rather than restarting. The breaking change exists because reasoning carried across hours has to be anchored to something.
That last point is the one I would keep. Once a model's reasoning is bound to the exact history that produced it, a conversation stops being a buffer you manage and becomes a record you extend. The habits that survive are append-only ones: correct by adding, not by going back and quietly changing what was there.
Which is a slightly uncomfortable mirror. We have spent two years treating context as something to trim, summarise and rewrite behind the model's back. The tooling is now saying that if you want an agent to work coherently for six hours, you have to stop editing its past.
