Claude Fable 5.1 vs Fable 5.0: What Changed, What Breaks

Anthropic has shipped Claude Fable 5.1, the successor to Claude Fable 5. The model ID is claude-fable-5-1, it is available to all customers on the Claude API and on every partner platform, and Project Glasswing participants get the matching claude-mythos-5-1.

Migrating is one line. Un-migrating is not — for any conversation already in flight, changing the model ID is a one-way door, and that is the third of the three things that break. Five things are new, seven behaviours moved without any code change at all, and one price fell by 75%.

(A note on the name: Anthropic calls the previous model "Claude Fable 5", not "Fable 5.0". Everyone searching for this comparison types 5.0, so that is what this headline says, but the official string is claude-fable-5.)

The short version

The headline for anyone paying the bill is the last price row, and it is not a rounding adjustment.

Pricing: one line changed, and it is the one that compounds

Base input, both cache write tiers and output are all identical to Fable 5. Cache reads bill at 0.025× base input instead of the 0.1× that every other Claude model charges — $0.25 per million tokens against $1.00.

That sounds small until you think about what a long agentic session actually does. It re-reads the same cached prefix on every single turn. A coding agent with a 200K-token context that runs for two hundred turns pays that read charge two hundred times, and on Fable 5.1 it pays a quarter of what it used to. Anthropic's own framing is precise: "Long agentic sessions that re-read a cached prefix pay a quarter of the Claude Fable 5 rate."

Batch processing is $5 and $25 per million. Cache writes and the 512-token minimum cacheable prompt length are unchanged — worth remembering that Fable's minimum is 512, not the 1,024 that applies elsewhere.

Anthropic's guidance on whether to reach for this model at all has not moved: start with Claude Opus 5 for most workloads, and use Fable 5.1 for demanding reasoning and long-horizon agentic work, or when your evals on Opus 5 at higher effort still fall short.

First: what a thinking block actually is

Two of the three breaking changes are about thinking blocks, so it is worth thirty seconds on what one is.

Thinking is always on for this model family. When Claude reasons, that reasoning comes back in the response as content blocks of type: "thinking", sitting in the same content array as the text and tool_use blocks. Reasoning between tool calls arrives the same way.

Here is the part that catches people. The raw chain of thought is never returned, and the default thinking.display on Fable 5, Fable 5.1, Opus 5, Opus 4.8, 4.7 and Sonnet 5 is "omitted" — which means the block comes back with its thinking field as an empty string. It looks like nothing. It carries a signature, and that signature is the whole mechanism: it is what the API checks to confirm the conversation is unchanged and that the current model is allowed to read the block.

So the rule that matters is: store the content array exactly as returned and send it back unchanged, every block type in the order received, including thinking blocks whose text is empty. The common way to break this is not malice but plumbing — reserialising the response through your own message type that drops unknown block types or strips empty fields. Your integration then looks like it is editing history, because it is.

Two things that do not change with the display setting: thinking happens either way, and it is billed either way. "summarized" returns a readable summary of the reasoning, and "updates" — new in 5.1 — returns the progress notes while keeping the reasoning hidden.

What breaks

Forced tool use returns a 400

tool_choice: {"type": "any"} and {"type": "tool", "name": "..."} are both rejected:

tool_choice: type "tool" and "any" are not supported for this model.

{"type": "auto"} (the default) and {"type": "none"} are unaffected, and the same validation applies to the token counting endpoint.

The reasoning behind it is worth understanding rather than working around. Thinking is always on for this model, and a forced tool call would skip it — the model would end up writing its working-out into the tool arguments, which makes the arguments worse. The replacements Anthropic points at are strict: true with strict tool use, or moving the schema into structured outputs. If what you actually wanted was "call a tool rather than reply in prose", say so in the prompt; the docs claim Fable 5.1 follows explicit tool instructions reliably.

Thinking blocks now belong to the model that made them

Every thinking block records which model produced it, and it travels in one direction only. Fable 5.1 can read thinking blocks from earlier models; no earlier model can read Fable 5.1's.

So a conversation that migrates up onto Fable 5.1 — from Opus 5, from Fable 5, from anything earlier — keeps its reasoning intact. Moving in the other direction does not.

Which makes migrating a live session a one-way door. Once a conversation has run turns on Fable 5.1, you cannot move that conversation back to Fable 5 or Opus 5 and have the older model see what 5.1 was thinking. New conversations on the old model are fine — this is about sessions already in flight. If your rollback plan is "flip the model ID back if 5.1 misbehaves", it works for the next conversation and silently degrades every one already running.

Silently is the operative word. The API drops unreadable blocks before the model sees them; they cost nothing and are not billed. There is no error, no warning, and no change in your bill — the older model simply picks up the thread with less context than you think it has. The thinking-binding-controls-2026-08-01 beta header surfaces each drop in a top-level input_transformations array, and on this model that header is worth turning on for that reason alone.

Two live paths hit this without anyone deciding to. Refusal fallback is one of them, and it is the one to check first: the permitted fallback targets for Fable 5.1 are Opus 4.8 and Opus 5, both earlier models, so every fallback that fires mid-conversation hands the rescuing model a history with the Fable 5.1 reasoning stripped out of it. Cost-optimising routers are the other — anything that switches between 5.1 and a cheaper model turn by turn is degrading the cheap turns in a way that produces no signal at all. Anthropic's docs name both cases explicitly.

Editing earlier turns invalidates thinking blocks

This is the one most likely to bite an existing integration, and it is a genuine change in what a conversation is.

Why it exists is worth a sentence, because it is not housekeeping. When you send a thinking block back, the API checks its signature — that the prefix is unchanged, and that the current model can read it. Anthropic's stated reason: "so that reasoning produced under one set of instructions can't be replayed under another, potentially adversarial set of instructions." It is a prompt-injection defence. Reasoning the model produced while following your system prompt cannot be lifted out and replayed underneath somebody else's. One signature does both jobs, which is why the one-way rule and the append-only rule arrived together — they are two halves of the same check.

What it is scoped to is the conversation — not your session, your app, or your account. A block is bound to the exact prefix it was produced under: the top-level system, the tools array, every message before it, and an unbroken chain of earlier thinking blocks. That is why the error says the block is bound to a different conversation. Two neighbouring scopes are easy to confuse with it: enforcement is per account (new accounts from 31 August 2026), and prefix_mismatch_behavior is per request — a drop applies to that request alone, so once you start sending drop_block you keep sending it for the rest of the session. Server-side compaction restarts the checked prefix at the most recent compaction block.

Modify anything ahead of a Fable 5.1 thinking block — the system prompt, the tools array, an earlier message — and the next request errors. Replaying an invalidated block returns a 400 reading The block is bound to a different conversation.

The four patterns that invalidate everything after them:

• editing, reordering or removing an earlier turn while keeping later ones
• injecting per-request text into an earlier turn (a reminder, a status line) that you delete on the next request
• rebuilding the top-level system prompt or tools array between requests in the same conversation
• an image or document URL that serves different bytes on a later request — the check covers the bytes, not the URL, so a rotating signed URL for the same file is fine

And the four that are safe: dropping a leading run of thinking blocks oldest-first (never from the middle), letting server-side compaction or context editing trim history, moving cache_control markers, and changing effort between requests.

One clarification, because the rule is narrower than it first reads: client-side compaction is not banned. What is banned is keeping a thinking block behind a prefix you have rewritten. The simple shape — summarise the session into one message and start the next request with that summary plus the new turn, replaying no earlier turns and no thinking blocks — is fine, and Anthropic says it performs comparably to more elaborate schemes. It is keep-tail compaction (summarise the old, keep recent turns verbatim) and background compaction that break, and both are fixed by stripping thinking blocks from the turns you carry across, or by sending drop_block and letting the API strip them.

Two mitigations matter. If you want to drop the block and continue rather than error, the thinking-binding-controls-2026-08-01 header plus thinking.block_binding.prefix_mismatch_behavior: "drop_block" does that, and reports it in input_transformations. And enforcement is staged: it applies to accounts created on or after 31 August 2026, while older accounts have the mismatch recorded but not acted on unless they opt in. If you built the messages array yourself, running a session with drop_block and logging input_transformations is the cheap way to find out whether your code edits history without meaning to.

Claude Code, claude.ai, Managed Agents and the Claude Agent SDK all preserve the prefix for you. This is a problem for hand-rolled integrations specifically.

What is new

Per-message effort (beta, mid-conversation-output-config-2026-07-01). You can change the effort level mid-conversation without invalidating the prompt cache — raise it for a hard step, drop it for routine ones. An effort-only system message takes effect from the next user turn. Fable 5.1, Mythos 5.1 and Opus 5 support it.

Turn-scoped system messages (beta, mid-conversation-system-clear-at-2026-08-21). Set clear_at: "next_user_message" on a role: "system" message and its text carries system-prompt authority for one turn, then stops rendering. It stays in messages and you keep sending it back verbatim, so nothing earlier changes, the cache keeps matching, later thinking blocks stay valid, and a cleared message costs no input tokens. This is the sanctioned replacement for the inject-then-delete reminder pattern that the binding rule now forbids.

Readable progress updates (beta, thinking-display-updates-2026-08-18). Fable 5.1 writes short progress notes between tool calls, each arriving as its own thinking block. Under the default display: "omitted" those come back empty — so a long agentic turn looks silent to your users. display: "updates" returns the progress text while keeping reasoning hidden; any thinking block with non-empty text is then a status line you can show.

Content provenance. Text from Fable 5.1 and Mythos 5.1 carries Anthropic's statistical text watermark on every platform, and image and video files it produces carry signed C2PA Content Credentials when retrieved through the Files API. The watermark adds no tokens, no hidden characters, and no information about you or your organisation.

Seven things that changed without you changing anything

This is the section most launch posts skip, and Anthropic wrote it down: behaviours that differ from Fable 5 with no code change at all. Each has a prompting fix in the Fable 5.1 prompting guide.

None of these are bugs, and the honest read is that a point release moved the model's defaults. If you have prompts tuned against Fable 5, they are now tuned against something slightly different.

What got better

The capability gains, per Anthropic, concentrate in six areas, and the gap over Fable 5 is widest at higher effort levels: agentic coding over long sessions; knowledge work with documents, spreadsheets and slides; research and multistep search; vision on dense charts, filings and tables nested in PDFs; long-context reasoning across the full 1M window; and computer use, including recovering from failed steps.

Multilingual performance is on par with Fable 5 — stated as parity, not improvement.

No benchmark numbers accompany any of this, in the what's-new page at least, and none are reproduced here. We have not run Fable 5.1 on our own hardware or harnesses; everything above is what the vendor documents about its own model. That is a different kind of claim from a measurement taken in this room, and it is worth keeping the two apart.

Refusals, fallback and availability

Fable 5.1 carries the same safety classifiers and stop_details categories as Fable 5, so it can still return stop_reason: "refusal" on an HTTP 200. Handle it. The permitted server-side fallback targets are Claude Opus 4.8 and Claude Opus 5; fallbacks: "default" (beta) routes by refusal category. A refusal arriving before any output is not billed, and fallback credit refunds the prompt-cache cost of switching models.

Availability is broad from day one:

Both models carry 30-day data retention and are not available under zero data retention without express authorisation from Anthropic. Mythos 5.1 remains restricted to Project Glasswing participants.

The migration, in order

1. Change the model ID. claude-fable-5 becomes claude-fable-5-1.
2. Remove every tool_choice of type any or tool. Move schema enforcement to strict tool use with auto, or to structured outputs.
3. Make your history append-only. Pass thinking blocks back unchanged. Move inject-then-delete reminders to turn-scoped system messages, move system and tools changes to mid-conversation system messages, trim context server-side. Then pick a production prefix_mismatch_behavior and monitor input_transformations.
4. Re-tune effort from the default high, and consider changing it mid-conversation rather than holding one level all session.
5. Watch your agent loops for one-call-per-turn where Fable 5 batched, and add the batching note.
6. Re-run your evals. Refusal handling, fallback, fallback credit and token counts all carry over unchanged.

Steps 1 and 2 are mechanical. Step 3 is the one that turns a version bump into an afternoon, and it is the reason to read the migration guide rather than just swapping the string.

Related reading

• Claude Opus 5: What's New — the model Anthropic still recommends starting with
• How Claude Will Mark AI-Generated Content — and Why Text Is the Hard Part — the watermark that now ships on Fable 5.1 output
• Claude Mythos Preview: Why Anthropic Locked Its Best Security Model Behind a Wall — why Mythos 5.1 is invitation-only
• Apricot Jam: Fable 5 vs Sonnet 5 — Which AI Makes the Better Retro Game? — Fable 5 doing real work, before the point release
• What a 256K (or 1M) Context Window Actually Costs You — the arithmetic behind why a cheaper cache read matters