Migrating to Claude Fable 5.1 from Fable 5 or Opus 5: Every Breaking Change

Moving to Claude Fable 5.1 is mostly a model-ID swap. The API surface, limits, per-token pricing, tokenizer, always-on adaptive thinking, and refusal handling all match Fable 5. But three changes return errors Fable 5 never did, and one of them, the history-editing check, can silently degrade an agent harness that worked fine for a year. Coming from Opus 5 adds four more items.

This guide is the checklist with the exact error text and fix for each item, in the order you will hit them, built from Anthropic’s migration guide and What’s new in Claude Fable 5.1. Every snippet can be pasted into Apidog and run against the real endpoint before it reaches production. For the model overview, start with what Claude Fable 5.1 is.

Step 0: Confirm you should migrate at all

Anthropic’s docs say to start with Opus 5 and use Fable 5.1 “for demanding reasoning and long-horizon agentic work, or when your evals on Claude Opus 5 at higher effort still fall short.” If Opus 5 passes your evals, the migration doubles your per-token price for no measured gain. If you are on Fable 5, it is the same price with cheaper cache reads and better claimed numbers, so the question is only how much harness work it takes. The Fable 5.1 vs Fable 5 and Fable 5.1 vs Opus 5 comparisons cover the decision.

Three eligibility checks first:

Data retention. Fable 5.1 requires 30-day retention and is not available under zero data retention unless Anthropic expressly authorizes it. A ZDR org gets 400 invalid_request_error on every request with no other hint. Opus 5 is available under ZDR.
Priority Tier. Not supported on Fable 5.1. Fable 5 supports it.
Rate limits. Fable 5.1 shares one “Fable 5.x” pool with Fable 5, so a gradual cutover draws from the same headroom.

Step 1: Update the model name

model = "claude-fable-5"    # Before
model = "claude-opus-5"     # Or before
model = "claude-fable-5-1"  # After

On Amazon Bedrock the ID is anthropic.claude-fable-5-1. Google Cloud, Microsoft Foundry, and Claude Platform on AWS use claude-fable-5-1. If you use Claude Managed Agents, this is the only change required.

Breaking change 1: forced tool use returns a 400

Fable 5 accepted tool_choice values auto, none, any, and tool. Fable 5.1 rejects the last two, on the Messages API, the Batches API, and the token-counting endpoint:

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

Anthropic’s reason: thinking is always on, and a forced call would skip it, so the model would write its working-out into the tool arguments.

Before (Fable 5):

response = client.messages.create(
    model="claude-fable-5",
    max_tokens=16000,
    tools=[record_summary_tool],
    tool_choice={"type": "tool", "name": "record_summary"},
    messages=[{"role": "user", "content": "Summarize: The meeting moved to Thursday."}],
)

After (Fable 5.1): leave tool_choice at auto, name the tool in the instruction, and set strict: true (strict tool use) so the arguments still match your schema.

record_summary_tool["strict"] = True
record_summary_tool["input_schema"]["additionalProperties"] = False

response = client.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    tools=[record_summary_tool],
    tool_choice={"type": "auto"},
    messages=[{"role": "user", "content": "Summarize: The meeting moved to Thursday. Call the record_summary tool with your result."}],
)

Migrate by intent. If you forced a tool to get JSON back, replace it with structured outputs (output_config.format). If the application requires the call on this turn, append a role: "system" message after the latest user turn that names the tool and says the call is required, and keep it in the history afterwards. If you relied on any for “exactly one tool,” disable_parallel_tool_use: true still works with auto but now means at most one call. Delete any retry-on-missing-tool loop; Anthropic says Fable 5.1 follows explicit tool instructions reliably. In a CMEK organization, strict: true and structured outputs are not available on Fable models, so rely on the instruction alone.

Breaking change 2: older models cannot read Fable 5.1 thinking blocks

Every thinking block records the model that produced it. Fable 5.1 reads blocks from Opus 5, Fable 5, Mythos 5, and earlier models, so a conversation moving onto Fable 5.1 keeps its reasoning. Apart from Mythos 5.1, no other model can read a Fable 5.1 block.

A Fable 5.1 conversation lands on an older model through a router switch, a client-side retry, or a classifier refusal fallback. In every case the API drops the blocks that model cannot read before it sees them. The request succeeds, the dropped tokens are not billed, and the target model re-plans without the reasoning, which raises cost and latency on the first turn after the switch.

Nothing to fix in code. Keep passing thinking blocks back unchanged; stripping them yourself can trigger signature 400s. For visibility, send the thinking-binding-controls-2026-08-01 beta header and the response carries an input_transformations array naming each dropped block with reason: "model_binding_mismatch".

Breaking change 3: editing earlier turns invalidates thinking blocks

This is the item to budget time for. A Fable 5.1 thinking block is valid only against the exact system prompt, tools array, and message history that preceded it (preserved thinking). Where the check is enforced, a request that replays a block after any of that changed is rejected:

messages.5.content.0: Invalid `signature` in `thinking` block. The block is bound to a different conversation. Remove the block, or set `thinking.block_binding.prefix_mismatch_behavior` to "drop_block". That setting requires the `thinking-binding-controls-2026-08-01` value in the `anthropic-beta` header.

Who is enforced. Accounts created on or after August 31, 2026. Older accounts record the mismatch but only act on it if the request sets thinking.block_binding.prefix_mismatch_behavior. Anthropic says future models will enforce it for every account. If you ship a tool that others run with their own API key, test with the field set: your users on new accounts are enforced before you are. Claude Code, claude.ai, Managed Agents, and the Agent SDK keep the prefix intact for you; Mythos 5.1 does not run the check at all.

What invalidates every later block: editing, reordering, or removing an earlier turn (including deleting old tool results); injecting per-request text you remove next request; rebuilding system or tools between requests; an image URL that serves different bytes later. What keeps blocks valid: append-only histories, removing a leading run of thinking blocks oldest first, changing any parameter outside system, tools, and messages, moving cache_control markers, and server-side compaction or context editing.

The escape hatch. Send the beta header and set the field to "drop_block":

response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    thinking={"type": "adaptive", "block_binding": {"prefix_mismatch_behavior": "drop_block"}},
    betas=["thinking-binding-controls-2026-08-01"],
    messages=history,
)
for t in response.input_transformations or []:
    print(t.path, t.reason)   # prefix_binding_mismatch or model_binding_mismatch

The API drops the first mismatched block and every thinking block after it, proceeds, and reports each drop. It applies to that request only, so keep sending the field. Set "error" explicitly in CI so a history edit fails the run. The preserved thinking guide has the three-step audit and the compaction shapes that break. The fix table:

You were doing	Do this instead
Editing `system` mid-session	Freeze it at session start; append a `role: "system"` message where the change becomes true
Editing `tools` mid-session	Declare the full set up front; send `tool_addition` / `tool_removal` blocks in a system message (beta `mid-conversation-tool-changes-2026-07-01`)
Injecting a per-turn reminder and deleting it	Turn-scoped system message with `clear_at: "next_user_message"` (beta `mid-conversation-system-clear-at-2026-08-21`), left in the history
Deleting old tool results client-side	Server-side context editing
Client-side compaction keeping recent turns verbatim	Server-side compaction, or one summary message plus the new user turn, replaying nothing else
Referencing an image by URL across turns	Upload once to the Files API and send the `file_id`

Coming from Opus 5: four more items

1. Thinking cannot be disabled at any effort. Opus 5 accepted thinking: {"type": "disabled"} at high or lower. Fable 5.1 returns a 400 at any effort. Remove the field, control spend with lower effort, and revisit max_tokens for routes that ran without thinking.

2. Between-tool narration moves into thinking blocks. On Opus 5, text between tool calls came back as text blocks. On Fable 5.1, it comes back as progress-update thinking blocks that are empty under the default display: "omitted". If your UI rendered that narration, set thinking: {"type": "adaptive", "display": "updates"} with the thinking-display-updates-2026-08-18 header.

3. The classifier set is broader. Opus 5 runs cyber-only classifiers. Fable 5.1 covers cyber, bio, frontier_llm, reasoning_extraction, and general_harms. Handle stop_reason: "refusal" before reading content, and opt into fallbacks: "default" with the server-side-fallback-2026-07-01 header. The permitted targets are Opus 4.8 and Opus 5, so a refused request can fall back to the model you migrated from.

4. Price and retention. $10 and $50 instead of $5 and $25, with cache reads at $0.25 instead of $0.50. ZDR is lost. The pricing breakdown has the math.

Coming from Opus 4.8 or earlier, first apply the Opus 4.8 to Opus 5 migration, then this guide. Integrations written for Opus 4.8 often truncate old turns or rebuild the system prompt each request, and Opus 4.8 never objected.

Behavior changes to test for

None return errors, and each has a one-line fix in the prompting guide. In long loops Fable 5.1 may issue one tool call per turn where Fable 5 batched several; measure the share of multi-call turns and add the batching nudge if it dropped. It writes fewer progress messages, so set display: "updates" and remove prompt lines telling it to hold findings. At low effort it calls search tools less often, so raise effort for turns that need fresh data.

Recommended changes

Per-message effort (beta mid-conversation-output-config-2026-07-01). Change effort with an empty-content role: "system" message carrying output_config instead of changing the top-level value, which resets the cache.
Start at high and sweep. Gains over Fable 5 are largest at xhigh and max; Anthropic says medium roughly matches Fable 5 at lower cost. Level names do not carry across models.
Trim context on the server. Server-side compaction (beta compact-2026-01-12) and context editing do not count as history edits.

The migration checklist

[ ] Confirm 30-day data retention and no dependency on Priority Tier.
[ ] Update the model name to claude-fable-5-1.
[ ] Replace every tool_choice of type any or tool with auto plus an instruction and strict: true, or structured outputs.
[ ] From Opus 5: remove thinking: {"type": "disabled"} and revisit max_tokens.
[ ] Pass thinking blocks back unchanged on every turn, including empty ones.
[ ] If your code builds messages, run a session with prefix_mismatch_behavior: "drop_block", log input_transformations, and fix every prefix_binding_mismatch.
[ ] Freeze system and tools at session start; move per-turn reminders to turn-scoped system messages you never delete.
[ ] Pick a production prefix_mismatch_behavior and monitor it.
[ ] Handle stop_reason: "refusal"; add fallbacks: "default".
[ ] If your UI renders between-tool text, set display: "updates".
[ ] Re-run the effort sweep from high and re-baseline cost. Token counts are unchanged from Fable 5; cache reads are a quarter of the price.

Running the checklist in Apidog

Build a collection with one request per breaking change: a forced tool_choice call (expect the 400 above), a thinking: disabled call (expect a 400), and a two-request sequence that edits the system prompt between turns with the thinking-binding header set (expect a prefix_binding_mismatch entry). Add the passing versions next to them with assertions on stop_reason and an empty input_transformations array, and run it in CI through the Apidog CLI on every harness change. Download Apidog to build it; the API walkthrough has the request bodies.

FAQ

Is migrating from Fable 5 to Fable 5.1 a drop-in change? Mostly. Forced tool_choice returns a 400, older models cannot read Fable 5.1 thinking blocks, and editing earlier turns invalidates later thinking blocks on enforced accounts. Everything else carries over.

What does “bound to a different conversation” mean? Your code changed something before a Fable 5.1 thinking block and then replayed the block. Stop editing history, or send the thinking-binding-controls-2026-08-01 header with prefix_mismatch_behavior: "drop_block".

Does my account enforce the history-editing check? If it was created on or after August 31, 2026, yes. Older accounts enforce it only when you set prefix_mismatch_behavior.

Can I keep my Fable 5 prompts? Yes. Anthropic says they should perform well without changes. Re-run the effort sweep and expect fewer parallel tool calls in long loops.

What breaks when I migrate from Opus 5? Everything in the Fable 5 list, plus thinking: disabled returns a 400 at any effort, between-tool narration moves into thinking blocks, the classifier set is broader, the price doubles, and ZDR is lost.

Do Bedrock and Google Cloud have the same breaking changes? The model changes, yes. The thinking-binding controls were on the Claude API and Claude Platform on AWS at launch and arriving per model on Bedrock and Google Cloud. Without the controls, the recovery is to strip thinking blocks and retry once.