The handbook forFable 5.2

The essentials in one table

Fable 5.2 uses the same Messages API as other recent Claude models, with strict rules. Most 400 errors seen during a migration come from the rows below.

First call

The useful minimum: the model, a comfortable max_tokens, an explicit effort, and refusal handling before reading the text.

import anthropic

client = anthropic.Anthropic()  # reads ANTHROPIC_API_KEY

message = client.messages.create(
    model="claude-fable-5-2",
    max_tokens=16000,
    output_config={"effort": "high"},
    messages=[{"role": "user", "content": "Hello, Claude"}],
)

if message.stop_reason == "refusal":
    details = message.stop_details
    print("Refusal:", details.category if details else None)
else:
    # Thinking blocks come first: select by type.
    print("".join(b.text for b in message.content if b.type == "text"))

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2026-10-21" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-fable-5-2",
    "max_tokens": 16000,
    "output_config": {"effort": "high"},
    "messages": [{"role": "user", "content": "Hello, Claude"}]
  }'

Spec sheet

Fable 5.2 targets agent sessions that run for hours, deep multi-step research and analysis carried through to the final deliverable. Claude Mythos 5.2 offers the same capabilities, specs and pricing, but only to organizations verified through an Anthropic program such as the Cyber Verification Program.

Against the 5.5 models

US dollars, input / output. All four models have reliable knowledge through June 2026. The previous generation, Fable 5.1, cost $10 / $50.

Model IDs by platform

Pricing

Availability and limits

• Released November 9, 2026, status active. Retirement not before November 9, 2027.
• Its own rate limit, separate from the combined limit shared by Fable 5.1 and Fable 5. Against Opus 5.5, token limits are lower at every tier. Check them before moving traffic.
• 30-day data retention required. No ZDR without Anthropic's express authorization; an organization on ZDR can configure retention for a specific workspace.
• No Priority Tier. If you have a Priority Tier commitment, plan capacity separately.
• Fast mode on the Claude API, on Google Cloud (Anthropic managed and Google managed, with Google's pricing in the latter) and on Microsoft Foundry through the claude-fable-5-2-fast deployment, without speed. Remove speed: "fast" in Managed Agents.
• The Models API exposes the model's limits and capabilities, for example whether a given thinking value is accepted.

Features by platform

¹ With the InvokeModel API, the beta value goes in the body's anthropic_beta array. ² The beta header travels through the platform's own mechanism. ³ Pricing set by Google Cloud. ⁴ Through the claude-fable-5-2-fast deployment. "—": not listed in the pages consulted.

Adaptive thinking

Fable 5.2 thinks before answering when the task calls for it. You cannot turn that thinking off: you set its depth with effort and its visibility with display.

What each thinking value does

What you see: display

Things to remember

• Thinking is billed as output tokens, whatever display says. Hiding it lowers latency, not cost. With "summarized", you pay for all the thinking, not just the summary.
• It counts against max_tokens, along with the answer text. max_tokens is the only hard limit; effort is a hint.
• You never see the raw chain of thought. A block's text is a summary, written by a different model from the one you call.
• Each block carries a signature, encrypted and opaque. Do not parse it. Send blocks back unchanged, including when the thinking field is empty: any text you put there is ignored.
• At high and above, the model thinks before almost every reply, even a greeting. For a simple request at lower effort it may produce no thinking block at all.
• Interleaved thinking is automatic: the model thinks between tool calls with no beta header.
• Select content by type, never content[0].text: thinking blocks come first.
• In Managed Agents, the platform sets the thinking configuration; agent definitions have no thinking field.

response = client.messages.create(
    model="claude-fable-5-2",
    max_tokens=16000,
    thinking={"type": "adaptive", "display": "summarized"},
    output_config={"effort": "medium"},
    messages=[{"role": "user", "content": "How many Friday the 13ths are there in 2027?"}],
)

for block in response.content:
    if block.type == "thinking":
        print("Reasoning summary:", block.thinking)
    elif block.type == "text":
        print(block.text)

Progress updates between tool calls

Between two tool calls, Fable 5.2 can write a short note for the person following the agent: what it just found and what it will do next. Each note arrives in its own thinking block, right before the tool_use it introduces. There is at most one per tool call, and the model may skip any of them.

With the default display, these notes are empty. A client that only renders text blocks therefore looks silent during a long agentic turn. Switch to "updates" and render the non-empty thinking blocks.

with client.beta.messages.stream(
    model="claude-fable-5-2",
    max_tokens=64000,
    thinking={"type": "adaptive", "display": "updates"},
    output_config={"effort": "high"},
    betas=["thinking-display-updates-2026-08-18"],
    tools=tools,
    messages=messages,
) as stream:
    message = stream.get_final_message()

for block in message.content:
    # With "updates", a non-empty thinking block is a progress update.
    if block.type == "thinking" and block.thinking:
        print("›", block.thinking)
    elif block.type == "tool_use":
        print("tool:", block.name)

# Send the turn back unchanged, empty thinking blocks included.
messages.append({"role": "assistant", "content": message.content})

• For real-time display, handle the stream's thinking_delta events. Expect a pause of a few seconds before a progress block opens.
• The text you receive summarizes the note (a sentence or two), but usage.output_tokens counts the full note.
• The model writes fewer notes at high effort and in long tool chains. To get more, see Keeping users informed.
• If a response stops on max_tokens, model_context_window_exceeded or stop_sequence right after a tool, the last block can be a fixed note saying the response was interrupted. To resume, send the turn back unchanged and add a user message with a tool_result for every tool_use in the turn.

Effort

Effort sets how much work Fable 5.2 puts into a response: thinking, tool calls and text. Since thinking is always on, it is your main control over depth, latency and cost.

The bars only show the relative order of depth and spend, not measured values.

Choosing a level

• Most of the gain is already there at high. Above it, gains are uneven and task-dependent. Drop to medium wherever your evaluations show quality holds.
• Re-run your sweep. Levels keep the same order from one model to the next, but not the same amount of thinking. A setting tuned for Fable 5.1 or Opus 5.5 does not carry over.
• An "answer without deliberating" instruction does not stop thinking from medium up. If simple requests cost too much, lower the effort for those turns.
• Low levels cause more premature stops in agentic work. Add the "finish the job" instruction at low and medium.
• Effort barely changes answer length. Set length and tone through the prompt.
• Low effort means fewer, more consolidated tool calls, no preamble and short confirmations. High effort means more calls, an explained plan, detailed summaries and fuller code comments.
• Inside a tool loop, a request that only processes tool results may skip thinking at any level.
• Mix levels: plan and iterate at medium, then raise the effort for the long unattended phase.
• From high up, plan for a high max_tokens.

Changing effort mid-conversation

There are two ways. The first, per-message effort beta, keeps the prompt cache: append to messages a role: "system" message with empty content that carries the new level. The second, changing output_config.effort in the next request, works everywhere but restarts the cache.

first = client.messages.create(
    model="claude-fable-5-2",
    max_tokens=16000,
    output_config={"effort": "high"},
    messages=[{"role": "user", "content": "Propose a plan to migrate from SQLite to PostgreSQL."}],
)

follow_up = client.beta.messages.create(
    model="claude-fable-5-2",
    max_tokens=16000,
    output_config={"effort": "high"},  # unchanged: the cache stays valid
    betas=["mid-conversation-output-config-2026-07-01"],
    messages=[
        {"role": "user", "content": "Propose a plan to migrate from SQLite to PostgreSQL."},
        {"role": "assistant", "content": first.content},  # sent back unchanged
        {"role": "system", "content": [], "output_config": {"effort": "low"}},
        {"role": "user", "content": "Summarize the plan in one sentence."},
    ],
)

• Placement: right after a user turn that brings new input, the level applies to the reply to that turn. Elsewhere (between an assistant turn and the next user turn, or after a turn holding only tool_result blocks), it takes effect at the next user turn that brings new input. A running tool loop therefore keeps its level.
• Duration: the level stays in force until the next such message. Leave each message in place in later requests: it is now part of the history.
• Free placement: an effort-only message is exempt from the placement rules of system messages. It can even open messages.
• Without the beta header, the API returns a 400: the message's output_config field is rejected as unknown.
• Platforms: Claude API, Claude Platform on AWS, Google Cloud (Anthropic managed and Google managed), Amazon Bedrock. With Bedrock's InvokeModel API, the beta value goes in the body's anthropic_beta array. Microsoft Foundry is not listed.
• Changing effort between two requests does not invalidate preserved thinking: effort is not part of the checked prefix. Only the cache suffers.
• In Managed Agents, set effort on the agent's model object or in a session's model override.

Preserved thinking

A thinking block you send back is only valid in the exact context that produced it. Fable 5.2 enforces this check on every account, whatever its age: an edited history returns a 400 by default.

Nothing changes for you if Claude Code, claude.ai, Managed Agents or the Claude Agent SDK manage the history. Read this section if your code builds the messages array itself.

Three checks on every block

A single edit before a thinking block invalidates that block and every one after it. With "error", the request fails with a 400; with "drop_block", the blocks are dropped, the reasoning is lost and the cache restarts at the edit.

What the prefix covers

The checked prefix is the top-level system prompt, the full tools array and every message before the block. With server-side compaction, it starts at the latest compaction block. effort, max_tokens, output_config, tool_choice, metadata, thinking.display and cache_control markers are not part of it.

Earlier thinking blocks are not part of the prefix, but each one records the block that preceded it. You can drop the oldest ones, the newest ones, or all of them. A hole in the middle invalidates those that follow, and a dropped block must not come back: restoring it invalidates the blocks produced while it was gone.

Replacing each edit

Several betas in one request: separate them with commas in a single anthropic-beta header.

[
  { "role": "system", "content": "The workspace is now read-only. Do not write files until told otherwise." },
  { "role": "system", "clear_at": "next_user_message", "content": "Say in one line where things stand, then continue." },
  {
    "role": "system",
    "content": [
      { "type": "tool_removal", "tool": { "type": "tool_reference", "name": "delete_branch" } },
      { "type": "text", "text": "Branch deletion is disabled for the rest of this session." }
    ]
  }
]

Sending turns back unchanged

Store each response's content array and send it back without changes: every block type, in the order received, including thinking blocks whose text is empty. On Fable 5.2 that text is empty by default and the signature carries the reasoning.

• A serializer that drops unknown types or reorders blocks changes the prefix of every later turn.
• A serializer that drops the empty thinking field causes a 400. An empty signature fails too.
• A serializer that skips empty blocks raises no error, but the model loses its reasoning on every turn.
• If you parse the stream yourself, keep the block even with no text: it opens, receives its signature through a signature_delta, then closes.
• To resume a saved session, replay exactly what you sent and received. Do not regenerate anything from inputs that may have changed (date, instruction file, tool version). JSON formatting and key order do not matter; values do.

Choosing what happens on failure

The thinking.block_binding.prefix_mismatch_behavior field decides the fate of a failing block. It requires the thinking-binding-controls-2026-08-01 header and thinking: {"type": "adaptive", ...}; without the header, the API returns a 400.

In your logs, the error starts with Invalid `signature` in `thinking` block and usually ends with a sentence saying what changed, for example the system prompt or the tools list. A tampered signature also returns a 400, with no mention of the conversation; prefix_mismatch_behavior does not apply to it.

With the header, every response contains an input_transformations array (in message_start when streaming). Each entry names a block by its path, for example messages.3.content.0, and gives a reason:

• thinking_dropped + prefix_binding_mismatch: your code edited the history. Fix it.
• thinking_dropped + model_binding_mismatch: model switch. Expected, not a bug.
• thinking_dropped + organization_binding_mismatch: the block came from another account.
• thinking_mismatch_allowed: failing block let through. Only appears on models that still tolerate edits, never on Fable 5.2.

Ignore unknown types and reasons: new checks will add some. The token counting endpoint runs the same check. In the Message Batches API, an item without prefix_mismatch_behavior has its failing blocks dropped instead of a 400; with "error", it resolves as errored.

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

for t in response.input_transformations or []:
    # prefix_binding_mismatch: your code edited the history, fix it.
    # model_binding_mismatch: model switch, expected.
    print(t.type, t.path, t.reason)

Reacting to a 400 in code

Do not resend the same body. Retry once with the header and "drop_block", then store that choice with the session so every later request sends it too, including after a restart. If you cannot send the header, remove the block named by the error plus every later thinking and redacted_thinking block, leave them out, and continue. Then fix the edit that caused the problem.

Testing your integration before switching

1. Capture the request bodies of a few normal turns, including a compaction or a tool change.
2. Diff each pair of consecutive requests: system, tools and the shared messages must be identical up to the appended turns.
3. Replay a multi-turn session on claude-fable-5-2 with the thinking-binding-controls-2026-08-01 header and "drop_block".
4. Log input_transformations and fix every prefix_binding_mismatch entry. Do it even if your account never triggered the check on another model.
5. Pick the production setting: "error", or "drop_block" temporarily, with an alert on 400s and on input_transformations entries.

Switching models mid-conversation

Change model and keep sending the full history, thinking blocks included. The API drops, before the model sees them, the blocks it cannot read: no error, no charge, not counted in input_tokens. That drop does not count as an edit, and your messages array is never modified: if the conversation returns to a model that can read those blocks, it reads them again.

If you replay stored conversations from another account, go through the original account or a linked one: otherwise the API drops Fable 5.2's blocks.

Frequently asked questions

Prompting

Fable 5.2 follows instructions closely, including ones you wrote for other models. Start from the symptom you observe. The wordings below are examples to adapt, not Anthropic's official text.

Finishing the job

On long tasks, Fable 5.2 sometimes ends a turn too early: it lists what is left, offers to continue, or stops at an ordinary obstacle such as a timeout. This happens mostly at low and medium. The instruction must tell two kinds of obstacles apart: ordinary ones, to diagnose and work through, and deliberate blockers, to respect and report.

# Seeing the work through
Keep going while there is requested work you can still do.
Errors, timeouts, empty results and failing tools are not blockers: find the cause,
then get past it with what you have (wait and retry, fix the request, use another
tool or source).
Deliberate blockers are different: a file marked as off-limits, access withheld on
purpose, a safety guardrail. Leave them alone, say clearly what you found, and look
for another safe way to finish.
Stop only when the next step truly depends on the user's answer.
Risky or irreversible actions still need confirmation.

Anthropic's measurement, on coding sessions replayed at medium with an instruction of this kind: about half as many sessions ended with doable work left, for about 30% more output tokens. Endings that ask for permission nearly disappear; endings that list what is left and then stop do not. Since the model asks less often, keep your own confirmation for risky actions.

Approvals

• When you tell the model to continue, name what you approve. "Yes, apply the fix on the staging branch and rerun the tests" beats "go ahead" or a thumbs-up.
• In the system prompt, an approval rule must name the exact actions it covers: the model applies it to the letter. In an Anthropic test, a rule requiring approval for messages sent outside the conversation made the model hold back about half of its routine requests to colleagues.

Saying who owns the code

Fable 5.2 responds closely to what the prompt says about code ownership. If the prompt says nothing, or presents the code as someone else's, the model adds on top of the existing structure, even if that duplicates code, and reports nearby problems without fixing them. If you want it to improve the structure along the way, say the code is its own.

You own this codebase: its purpose and its design are your decisions, and you will
keep building on it.

• Anthropic's measurement on small tasks: duplicated code merged in about half the trials with the sentence, versus fewer than one in ten without. The requested feature worked almost every time in both cases.
• The trade-off: about 1.5× more output tokens, unrequested changes (tests, documentation), and existing behavior changed in one trial out of six to ten, more often at high effort. The final summary often leaves out small changes: review the diff.
• Leave the sentence out when the code belongs to the user and they want as few changes as possible. A scope rule elsewhere in the prompt does not cancel it: with a ban on drive-by refactors, the model still merged code in a third of trials.

Keeping users informed

During long runs of tool calls, Fable 5.2 sometimes writes little user-facing text, and may start its first tool without announcing what it is doing. First check that your client renders the progress updates: with the default display, they are empty.

1. Make the updates visible. display: "updates" (beta) or "summarized", then render the non-empty thinking blocks between tool calls.
2. Nudge from the harness. Count consecutive tool steps with nothing readable (no text block, no non-empty thinking block). After a few, append after the latest tool results a turn-scoped system message (clear_at: "next_user_message", header mid-conversation-system-clear-at-2026-08-21) asking for a short status. Leave every reminder in place in messages. Anthropic's measurement: the longest silent stretch roughly halved, with no notable increase in tokens or time.
3. Ask for an opening line and a recap. Useful when a human follows along live; about 20% more output tokens, and the model spoke before its first tool every time.

Harness reminder (turn-scoped system message):
You have been quiet for a while. Tell the user in a few words what you are doing,
then carry on.

System prompt, opening line and recap:
Begin with one line saying what you are about to do, and post short updates as you
work. End with a recap that stands on its own: what you found, what you changed,
what comes next.

Without harness access:
Every few tool calls, post a one-line status update for the user.

Even so, expect several tool calls between two updates. On asynchronous tasks, where the user comes back for the result, those gaps matter less.

Framing subagents

• Delegation depends on the harness: with a minimal subagent tool, Fable 5.2 rarely launches any; in a product whose prompts invite delegation, it delegates readily.
• First reread the lines asking for delegation in the system prompt, skills and agent files. Only rewrite the delegation tool's description if the model still launches too many subagents.
• A good description says, in this order: what a subagent adds to the session's cost, when delegating is worth it and when it is not, and how to brief the subagent. Anthropic's measurement: about a third fewer delegations, with the same success rate. Talk less about cost if the model delegates too little.
• At xhigh and max, the model may launch subagents to review its own work. It makes a good planner and orchestrator of other models. Check which model your harness runs subagents on by default: they can weigh heavily on cost.

Keeping caution from piling up

Cautious instructions accumulate wherever context carries over: memory, notes, instruction files, messages between agents. Fable 5.2 follows them closely and may ask for approvals it does not need or hold back routine work, especially in multi-agent systems.

• Delete notes you no longer need. In one test, a single "never retry" note among a dozen cut retries after a busy tool to about four trials in ten, versus nearly all without it.
• Name the steps that need no approval. A line listing retries among them moved retries from almost none to about half of trials; a general instruction to act more freely changed nothing. Only name retries for calls that are safe to repeat.
• Check what reviewer agents add. A "stop at the first error" from a reviewer was enough to block retries in a third of trials.
• Build the exception into the rule itself. An approved step under a "never" rule ran only one time in ten with a separate exception line, and nine times in ten when the rule itself said to get a go-ahead first.

Reviewing legacy instructions

Making reports readable

After long agentic work, the reader of the final report has seen neither the tool calls nor the files. Ask for text that stands on its own.

# Writing for the reader
Write for a capable reader who did not watch you work: they saw none of your tool
calls, reasoning or files, and may be coming back from something else.
Lead with the key points, then add detail in the order the reader needs it.
Do not use terms or abbreviations you coined during the work; describe things in
words any reader would understand.
Use short, complete sentences in the active voice, one idea per sentence, and the
same word for the same thing (in the spirit of ASD-STE100 Simplified Technical
English). Use prose where ideas connect and lists for separate items.
Be concise, but keep the context the reader needs.

Anthropic's measurement with an instruction of this kind: less dense reports, fewer semicolons and, on workflow automation, shorter sentences. Remove old style rules first.

Where to start

1. Set effort explicitly to high, then also run your evaluations at medium and xhigh.
2. Reread the system prompts, skills, agent files, memories, notes and harness text you carry over. Remove or test the legacy instructions listed above.
3. Run your longest agentic tasks. Note where the model stops too early, asks for needless approvals, goes quiet, delegates too much, or adds code where you wanted restructuring.
4. Apply one recommendation at a time and measure its effect and token cost on your own tasks.

Migrating to Fable 5.2

Pick your starting model. Each tab lists what breaks, what changes, then a checklist you can tick; your ticks stay in this browser.

Refusals and fallback

Fable 5.2 runs safety classifiers. When one declines a request, you get a normal response, HTTP 200, with stop_reason: "refusal". The same request usually succeeds on another Claude model: that is what fallback is for.

What a refusal looks like

{
  "model": "claude-fable-5-2",
  "content": [],
  "stop_reason": "refusal",
  "stop_details": {
    "type": "refusal",
    "category": "cyber",
    "explanation": "…"
  },
  "usage": { "input_tokens": 412, "output_tokens": 0 }
}

• category names the policy area. explanation is readable but unstable: display it, do not parse it. Both can be null, which is normal and permanent.
• recommended_model only appears with fallbacks: it names a model to try directly when the API skipped the fallback attempt, for example because of rate limits. A hint, not a guarantee.
• stop_details is null for every other stop reason. Branch on stop_reason or stop_details.type, never on content.
• A refusal can also happen mid-stream, after partial output. Treat that output as incomplete and discard it.

Categories and billing

• Before any output: billed at normal rates for bio, frontier_llm and reasoning_extraction, the categories where Anthropic measures few false positives (as of September 2026, subject to change). Free for the others and for a null category. In every case content is empty, usage gives the tokens and the request counts against your rate limits.
• Mid-stream: input and the output already streamed are billed.
• With a fallback: the triggering refusal is billed if it happened mid-stream or belongs to a billed category, on top of the fallback request. Fallback credit keeps you from paying twice for caching the conversation.

Choosing a fallback approach

Server-side fallback

• fallbacks: "default" with the server-side-fallback-2026-07-01 header: the API reruns the request on the model Anthropic recommends for the refusal category. Without a recommendation for the category, the refusal stands; that is the case for reasoning_extraction.
• Or a list of at most three models, tried in order, distinct from each other and from the requested model. For Fable 5.2 the allowed targets are claude-opus-4-8 and claude-opus-5; the Models API publishes them as allowed_fallback_models. Each entry may override max_tokens, thinking, output_config and speed for its attempt. The request must stay valid for every named model, or it is rejected up front.
• Only a classifier refusal triggers fallback. A rate limit, overload or server error comes back as is. If the fallback model is saturated, the attempt is skipped and the refusal returns with recommended_model: size its limits for the refusal volume you expect.
• The fallback model does not receive Fable 5.2's thinking.

response = client.beta.messages.create(
    model="claude-fable-5-2",
    max_tokens=16000,
    output_config={"effort": "high"},
    fallbacks="default",  # or [{"model": "claude-opus-5"}, {"model": "claude-opus-4-8"}]
    betas=["server-side-fallback-2026-07-01"],
    messages=messages,
)

if response.stop_reason == "refusal":
    details = response.stop_details  # the whole chain refused
    print("Refusal:", details.category if details else None)
else:
    fallback_ran = any(
        it.type == "fallback_message" for it in response.usage.iterations or []
    )
    if fallback_ran:
        print("Response served by", response.model)

What the response contains

• model names the model that served the response.
• A fallback content block marks each handoff, with from.model, to.model and trigger (type refusal and its category). On a refusal before any output, it is the first block.
• usage.iterations details every attempt: a message entry per model that declined, a fallback_message entry for the one that served. It is the record of what you are billed, each attempt at its own model's rates. The top-level usage counts only describe the returned attempt.
• Streaming: on a refusal before output, message_start already names the fallback model and the time to first byte includes the declined attempt. On a refusal mid-output, the open block closes, a fallback block marks the boundary and the fallback continues from the text blocks already produced; read the serving model in to.model or in the last message_delta.
• Without streaming, a mid-output refusal looks like a refusal before output: the partial output is omitted.
• Sticky routing: after a fallback, the API remembers for about an hour, per organization, which model served the conversation (a fingerprint of the prefix, not the content). Later requests with fallbacks go straight to the fallback model, without a fallback block: spot them through the fallback_message entry. Best effort only: your code must accept that the requested model may be tried again at any time.

Continuing the conversation after a fallback

SDK middleware, on every platform

The middleware retries refused requests made through client.beta.messages, in the order of your list. If every model refuses, it returns the last refusal instead of raising an error. It sends the fallback-credit-2026-07-01 header itself, adds the fallback blocks and handles them on later turns. Share one BetaFallbackState across a conversation's requests: later turns stay pinned to the model that accepted.

from anthropic import Anthropic, BetaFallbackState, BetaRefusalFallbackMiddleware

client = Anthropic(
    middleware=[BetaRefusalFallbackMiddleware([{"model": "claude-opus-5"}])],
)
state = BetaFallbackState()  # one state per conversation

with state:
    message = client.beta.messages.create(
        model="claude-fable-5-2",
        max_tokens=16000,
        messages=messages,
    )
print("Served by:", message.model)

Hand-written retry

1. Detect the refusal with stop_reason == "refusal".
2. Resend the same request with model set to a fallback model, for example claude-opus-5. Without credit, you can keep or remove the old thinking blocks: the fallback model does not read Fable 5.2's, and the API drops them without billing. With a fallback credit, send the body with no change at all: the credit requires an exact match.
3. Stay on the fallback model for the rest of the conversation instead of returning to the original model.

A hand-written retry writes the fallback model's whole cache; the fallback credit refunds that extra cost. In Message Batches, a refused item comes back as result.type: "succeeded" with stop_reason: "refusal", with no fallback credit, and fallbacks is not accepted there: collect the refused items and resubmit them on a fallback model.

The reasoning_extraction case

This refusal usually comes from a prompt that asks the model to put its reasoning in the output: a thinking or scratchpad section to fill before answering, a reasoning or trace field in JSON or tool input, private notes, reasoning "verbatim". Look in skills and tool descriptions too. Ask instead for a brief explanation, the evidence behind a result or a summary of the actions; to see the reasoning, read the thinking blocks with display: "summarized". No fallback is recommended for this category: change the prompt. If a reworded version is still refused, contact support with the request ID.

Workshop

Build a compliant Fable 5.2 request, or paste an existing request to spot what will be rejected.

Cheat sheet

Beta headers useful with Fable 5.2

Fable 5.2's fast mode does not need fast-mode-2026-02-01; on the Claude API, requests that send it still work.

Stop reasons

Sources

Anthropic documentation, read on November 10, 2026. Where this page and the official documentation differ, the documentation wins.

• Claude Fable 5.2: overview
• Prompting Claude Fable 5.2
• Migration guide to Claude Fable 5.2
• Preserved thinking
• Thinking
• Effort
• Refusals and fallback