Claude Fable 5.1 rejects forced tool use, and one of its rules depends on when your account was created
Anthropic shipped Fable 5.1 on September 1 with the same $10/$50 pricing and a one-line migration: change claude-fable-5 to claude-fable-5-1. Three documented things break on that line. tool_choice type any or tool now returns a 400. Thinking blocks get dropped silently when a router falls back to an older model. And the third check is enforced only for accounts created on or after August 31, 2026, so the same code passes on your account and fails on a colleague's. Here are the greps and the probe.
Anthropic released Claude Fable 5.1 on September 1. The migration instruction in the documentation is a single line:
model = "claude-fable-5" # Before
model = "claude-fable-5-1" # After
Input and output prices are unchanged at $10 and $50 per million tokens. Cache reads dropped from $1 to $0.25 per million, which is 0.025x the base input price where every other Claude model charges 0.1x. For an agent loop that re-reads a large cached prefix on every turn, that is the largest cost line in the run getting cut to a quarter.
The same page that gives you the one-line change also lists three breaking changes. Two of them fail loudly. The third one is the reason to read further, because whether it fails at all depends on something that is not in your code.
The grep to run before you change the model ID
Forced tool use is gone. On Fable 5.1 and Mythos 5.1, tool_choice set to {"type": "any"} or {"type": "tool", "name": "..."} returns a 400 invalid_request_error:
tool_choice: type "tool" and "any" are not supported for this model.
{"type": "auto"} (the default) and {"type": "none"} are unchanged. The same validation applies to the token counting endpoint, so a pre-flight cost estimate fails too.
This matters more than most breaking changes because forcing a specific tool is how a lot of people get schema-valid JSON out of a model. If that is your pattern, find it first:
grep -rn --include='*.py' --include='*.ts' --include='*.js' --include='*.go' \
-E 'tool_choice' . | grep -vE '"auto"|"none"'
Anthropic's stated reason is worth keeping, because it generalises beyond this model. Thinking is always on for Fable 5.1, and a forced tool call skips it. The model writes its working-out into the tool arguments instead, which makes the arguments worse. Forcing the call buys determinism and pays for it in argument quality.
The replacements are both documented. Keep tool_choice: {"type": "auto"} and set strict: true with strict tool use, or move the schema to structured outputs. If what you actually needed was for the model to reach for a tool rather than answer in prose, say so in the prompt: "Use the get_weather tool to answer." The documentation states plainly that Fable 5.1 follows explicit tool instructions reliably.
There is a small billing side effect. The tool-use system prompt has always cost more tokens under any and tool than under auto and none — on Claude Opus 5 it is 406 tokens against 286. Moving to auto gives that difference back on every request.
The failure that does not raise anything
Every thinking block Fable 5.1 produces records which model wrote it, and preservation runs one direction only. Fable 5.1 reads thinking blocks from Opus 5, Fable 5, and earlier models. No earlier model reads Fable 5.1's.
So a conversation that moves up to Fable 5.1 keeps its reasoning. A conversation that moves down — the fallback in your router, the cheaper model you switch to after the hard step, the retry path when a request gets refused — loses it for the turns that run there.
The part to plan for is how that loss is delivered. When a request carries a block the target model cannot read, the API removes it before the model sees it. The block does not count toward input_tokens and you are not billed for it. You get a normal 200 and a normal-looking answer, produced by a model that silently received less context than your code sent.
There is a beta header that makes this observable:
-H "anthropic-beta: thinking-binding-controls-2026-08-01"
With it, every drop is reported in a top-level input_transformations array on the response. Without it, the drop is silent. If you run any kind of model router, turn it on and log that array before you trust a fallback path. This is the same class of problem as a prompt cache miss you never see: the request succeeds, the cost or the quality moves, and nothing in the response says why.
The check that behaves differently on two accounts
The third breaking change is that editing anything earlier in the conversation invalidates every Fable 5.1 thinking block after it. Rebuilding the system prompt between requests counts. Rebuilding the tools array counts. Injecting a status line into an earlier turn and removing it on the next request counts. So does an image or document URL that serves different bytes later, because the check covers the bytes rather than the URL — a rotating signed URL for the same file is fine.
Where it is enforced, replaying an invalidated block returns a 400 reading The block is bound to a different conversation.
Now the sentence that is easy to skim past in the release notes:
The check is enforced for new accounts created on or after August 31, 2026. For accounts created earlier, the API records the mismatch but acts on it only when the request sets
thinking.block_binding.prefix_mismatch_behavior.
Two engineers can point identical code at the identical model ID and get different behaviour, decided by the age of the account behind the key. On an older account, an integration that rebuilds system on every request works, quietly accumulating a dependency on not being checked. On an account created for a new project last week, the same integration returns 400s. Claude Mythos 5.1 does not run the check at all.
Nothing in your codebase, your model ID, or your API version tells you which side you are on. That is the generalisable part, and it is worth carrying past this release: enforcement of an API rule can be keyed to account provenance, so "it works in my environment" stops being evidence about the code.
You do not have to guess which side your integration is on. Run a session with the drop behaviour opted in and read what comes back:
curl https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: thinking-binding-controls-2026-08-01" \
-H "content-type: application/json" \
-d '{ "model": "claude-fable-5-1", "max_tokens": 1024,
"thinking": {"block_binding": {"prefix_mismatch_behavior": "drop_block"}},
"messages": [ ... your real conversation ... ] }'
Any turn where your code edited history shows up in input_transformations with reason: "prefix_binding_mismatch". An empty array across a full session means your history is already append-only and the enforcement date is irrelevant to you.
If the array is not empty, the fixes are structural rather than defensive. Per-turn reminders you currently inject and delete move to turn-scoped system messages, which stay in messages and stop rendering after the next user message (clear_at: "next_user_message", beta header mid-conversation-system-clear-at-2026-08-21). Changes to system and tools move to mid-conversation system messages instead of rebuilds. Trimming happens server-side through context editing or compaction, neither of which counts as an edit. Removing a leading run of thinking blocks oldest-first is allowed; removing one from the middle invalidates everything after it.
Those patterns also keep the prompt cache warm, which is where the $0.25 cache read actually pays out. Append-only history is now both the correctness rule and the cost rule.
Claude Code, claude.ai, Claude Managed Agents, and the Agent SDK maintain the prefix for you. This section is for code that builds the messages array itself.
Behaviour that changes without any error
Six differences from Fable 5 show up with no code change and no failed request. The two most likely to reach your bill:
Parallel tool calling is more variable. Fable 5.1 may issue one tool call per turn where Fable 5 batched several. Answer quality does not drop; the extra turns cost tokens, round trips, and wall-clock time. Requests that name several things to fetch still run in parallel, so the fix is a one-line batching instruction in the system prompt.
When editing text files, the model is more likely to rewrite the whole file than make a targeted edit. Same result, more output tokens at $50 per million.
The rest: fewer progress updates during long tool runs, especially at high effort, which can make an agentic turn look silent to your users unless you set thinking.display to "updates" (beta header thinking-display-updates-2026-08-18); answering from memory rather than searching at low effort; denser prose; and less formatting in chat, which means anti-formatting rules you wrote for an earlier model may now suppress structure the content needs.
What is worth doing this week
Fable 5 is not deprecated. It remains Active with a retirement date no sooner than June 9, 2027, so there is no deadline pushing you. The reason to move is the cache read price and the long-session coding work, not a clock.
Which makes this the good case: a migration you choose the timing of. Run the grep for tool_choice, run the drop_block probe against a real conversation, and read input_transformations. Three commands, and you find out whether your integration has been depending on a check that was not being enforced.
For the broader pattern — model IDs and defaults moving underneath running code — see model IDs change under you. For the vocabulary, /glossary covers cross-model handoff and tool use.
Get the next post when it ships
One email on Sunday with the new post and a short list of what shipped that week — new guides, tool updates, and a couple of links worth reading.