Claude Fable 5.1 Migration Guide: Fix Tool-Choice 400s

Migrating from Claude Fable 5 to Claude Fable 5.1 is not always a one-line model-name change. The new model rejects forced tool choice, binds preserved thinking blocks to the conversation prefix that produced them, and cannot send its thinking blocks back to older Claude models. An integration can therefore pass a single-turn smoke test and still fail on its first structured-output request, compacted conversation, or fallback.

The safe migration has three parts: replace forced tool calls with automatic selection plus schema enforcement, keep multi-turn history append-only, and test every route that can switch the conversation back to an older model. If you use the OpenAI-compatible route, start with the Claude Fable 5.1 request guide; the native examples below use Anthropic's Messages API so each breaking change is visible.

Quick answer

• Change the native model ID to claude-fable-5-1, then remove forced tool_choice modes; any and named tools return HTTP 400.^[1]
• Keep the system prompt, tools, and earlier message prefix unchanged after a Fable 5.1 thinking block. Append new instructions instead of rewriting history.^[1]
• Test every fallback: older Claude models cannot read Fable 5.1 thinking blocks, so the API drops them before continuing.^[1]
• Adaptive thinking stays on. Replace manual token budgets with effort, and exercise prefix mismatches in CI before rollout.^[1]

First, inventory the code path you are actually migrating

Search more widely than the literal model ID. A wrapper may translate a generic “required tool” setting into Anthropic's tool_choice: {"type":"any"}, retain thinking blocks in a conversation store, or alter the system prompt on every request. The OpenCode issue that surfaced shortly after release is a useful example: its structured-output adapter selected required tool use, which became Anthropic's unsupported any mode and produced a 400.^[6] That issue demonstrates a real integration pattern; Anthropic's migration guide is the authority for the API behavior.

Audit these components before editing:

Do the inventory at the serialized request boundary if possible. Application objects can look unchanged even when an SDK or provider adapter rewrites them.

Step 1: update the model ID, but keep the rest observable

The native ID is claude-fable-5-1. Fable 5.1 retains the one-million-token context window, supports up to 128,000 output tokens, and uses always-on adaptive thinking.^[2] Start with the same production traffic shape and log request IDs, status codes, stop reasons, token usage, tool calls, and fallbacks.

Do not use this migration to change effort, compaction, prompt wording, and the tool framework at the same time. A narrow first deployment makes a 400 or behavior shift attributable. Once compatibility is established, sweep low, medium, high, xhigh, and max on the workload rather than assuming the old setting is optimal. Anthropic documents high as the default.^[1]

Also remove either of these configurations if a predecessor integration supplies them:

# Both are invalid for Claude Fable 5.1.
thinking={"type": "disabled"}

thinking={"type": "enabled", "budget_tokens": 12000}

Fable 5.1 decides when and how much to think. A trailing assistant message used as a prefill also returns a 400, so express output instructions in the system or user content instead.^[1]

Step 2: replace forced tool choice

The compatibility boundary is exact:

The check applies to Messages, Message Batches, and token counting. The reported error says that tool-choice types tool and any are unsupported for this model.^[1] Retrying the same body will not help.

Here is the common pre-migration pattern:

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

For Fable 5.1, use automatic selection, put the requirement in the current instruction, and make the tool strict:

record_summary_tool = {
    "name": "record_summary",
    "description": "Record the structured meeting summary.",
    "strict": True,
    "input_schema": {
        "type": "object",
        "properties": {
            "summary": {"type": "string"},
            "action_items": {
                "type": "array",
                "items": {"type": "string"},
            },
        },
        "required": ["summary", "action_items"],
        "additionalProperties": False,
    },
}

response = client.messages.create(
    model="claude-fable-5-1",
    max_tokens=4096,
    tools=[record_summary_tool],
    tool_choice={"type": "auto"},
    messages=[{
        "role": "user",
        "content": (
            "Summarize the meeting notes, then call record_summary "
            "with the summary and action items."
        ),
    }],
)

strict: true constrains the arguments if the model calls the tool; it does not recreate a transport-level guarantee that the tool must be called. Your application must still verify that the response contains the required tool-use block. Anthropic also recommends JSON outputs through output_config.format when the forced tool existed only to obtain schema-valid JSON.^[1]

If the application must require one named tool halfway through a conversation, append a role: "system" message after the latest user message. Name the tool, state that it is required for this turn, and tell the model to begin with the call. Keep that system message in later history. This preserves the earlier prefix; rewriting the top-level system prompt would not.^[1]

Treat “the model ignored the instruction” as a handled outcome. Reject the turn, retry under a bounded policy, or fail safely. Do not describe prompting as an absolute enforcement mechanism.

Step 3: preserve thinking in the direction the API supports

Every Fable 5.1 thinking block carries model and conversation binding information. Compatibility is one-way:

Fable 5 thinking  ───────► Fable 5.1 can read it
Opus 5 thinking   ───────► Fable 5.1 can read it

Fable 5.1 thinking ──X──► Fable 5 cannot read it
Fable 5.1 thinking ──X──► Opus 5 cannot read it

Claude Mythos 5.1 is the documented exception that can read Fable 5.1 blocks. When a router, refusal fallback, or client retry sends the conversation to an older model, the API removes blocks that the target cannot read. The request can still succeed, and the removed input tokens are not billed, but the target must plan again without that reasoning.^[1]

This matters for fallback evaluation. A first request on Fable 5 and a first request on Fable 5.1 are not equivalent to a mid-conversation switch from 5.1 to 5. Measure both. Log input_transformations with the thinking-binding beta enabled; model_binding_mismatch identifies blocks dropped because the model changed.

Step 4: make the conversation prefix append-only

A Fable 5.1 thinking block is valid against the exact system prompt, tool set, and message history that preceded it. Changing any of them before replaying the block can produce a 400 for an invalid thinking signature.^[1]

Common accidental edits include:

• rebuilding the system prompt with a fresh timestamp;
• adding or removing a tool from the top-level tools array;
• deleting an old tool result to save tokens;
• inserting a summary before recent turns while retaining their thinking blocks;
• removing a per-turn reminder on the next request;
• fetching different image or document bytes from the same URL.

The last case is easy to miss: the binding covers file bytes rather than only the URL string. For a file reused across turns, Anthropic recommends a stable Files API file_id or base64 content.^[1]

Prefer these patterns:

• append new turns without altering earlier bytes;
• append mid-conversation system messages for changed instructions;
• use supported tool-addition and tool-removal blocks for tool changes;
• use server-side compaction or context editing;
• if compacting on the client, replace the entire history with one summary and the new user turn, carrying no old thinking blocks.

That final client-side shape is deliberately simple. Keeping recent turns behind a new summary is safe only if their thinking and redacted_thinking blocks are stripped, because those blocks were created against the pre-summary history.^[1]

Diagnose prefix mismatches before users do

Anthropic enforces the conversation-prefix check by default for accounts created on or after August 31, 2026. Older accounts may not fail unless they opt into the control, which creates a dangerous “works with our key” test gap for libraries used with customer keys.^[1]

Use the beta control in a staging session:

response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=4096,
    thinking={
        "type": "adaptive",
        "block_binding": {
            "prefix_mismatch_behavior": "drop_block"
        },
    },
    messages=conversation,
    betas=["thinking-binding-controls-2026-08-01"],
)

for change in response.input_transformations or []:
    print(change.path, change.reason)

With drop_block, the API removes the first mismatched thinking block and every later thinking block, then reports prefix_binding_mismatch. With the default error, it rejects the request. Use drop_block when a degraded continuation is preferable to failure; use error in CI to expose a history mutation immediately.^[1]

An automatic retry of an identical invalid body cannot repair the mismatch. Either restore the original prefix, remove the affected thinking blocks, or explicitly request drop behavior once.

Recheck behavior that does not produce a 400

Compatibility tests should also cover quieter changes. Anthropic says Fable 5.1 may issue fewer parallel tool calls in long agent loops, produce fewer progress messages, and call search or retrieval less often at low effort.^[3] None of these necessarily indicates a defect, but each can alter latency or product behavior.

Build assertions around what the application needs:

• For parallelizable reads, record calls per turn and total round trips.
• For a progress UI, require user-facing updates at defined intervals rather than assuming they appear.
• For retrieval-grounded answers, make retrieval criteria explicit and fail answers that lack required evidence.
• For edit agents, verify the changed-file list and discourage whole-file rewrites when a small patch is required.^[4]

Keep refusal handling too. Fable 5.1 can return stop_reason: "refusal" with a stop_details.category; do not treat empty answer text as a transport failure. Any fallback must account for the one-way thinking compatibility.^[2]

FAQ

Why does Fable 5.1 return a 400 for my structured-output request?

Inspect the serialized Anthropic request. A framework may implement structured output by forcing a synthetic tool with tool_choice: any. Fable 5.1 rejects both any and a named tool choice. Switch to automatic tool choice plus a strict schema and explicit instruction, or use Anthropic's JSON output mechanism.

Does strict: true guarantee that Claude calls the tool?

No. It guarantees schema-conformant arguments when the tool is called. The instruction can require a call, but your application still needs to confirm that the expected tool-use block exists and handle its absence.

Can Fable 5.1 continue a Fable 5 conversation?

Yes. Fable 5.1 can read preserved thinking from Fable 5 and other documented earlier Claude models. The reverse direction is not compatible: the older target receives the conversation after Fable 5.1 thinking blocks are dropped.

Can I change the system prompt between turns?

Not by rewriting the prefix while replaying later Fable 5.1 thinking blocks. Append a mid-conversation system message and retain it in history. If the application intentionally starts a new conversation, it can use a new system prompt because there are no old thinking blocks to preserve.

What is the safest client-side compaction strategy?

Replace all prior history with one summary message plus the new user turn, and do not replay old thinking blocks. If you retain a recent tail, remove thinking and redacted-thinking blocks from that tail or use documented drop behavior.

Does the migration lower every API bill?

No. Input and output list prices remain $10 and $50 per million tokens. Cache reads are cheaper, but task cost also depends on output, number of turns, effort, retries, and whether the cache remains valid.^[5] The Fable 5.1 cost breakdown handles that calculation separately.

Release gate: do not deploy until every row passes

A green single-turn response proves only that the model ID and credentials work. A green migration exercises the conversation after a tool call, after a history change, and after the fallback that usually runs only when production is already under stress.

References

1. Anthropic, Migrating to Claude Fable 5.1 and Claude Mythos 5.1, accessed September 7, 2026.
2. Anthropic, Claude Fable 5.1 overview, accessed September 7, 2026.
3. Anthropic, What's new in Claude Fable 5.1, accessed September 7, 2026.
4. Anthropic, Prompting Claude Fable 5.1, accessed September 7, 2026.
5. Anthropic, API pricing, accessed September 7, 2026.
6. OpenCode, Issue #46735: Claude Fable 5.1 structured output tool-choice error, accessed September 7, 2026. The issue is cited as an integration example; API behavior is sourced from Anthropic.