Claude Fable 5.1 and Mythos 5.1: The Developer Migration Guide

Claude Fable 5.1 (API ID claude-fable-5-1, launched September 1, 2026) replaces Fable 5 at the same price of $10/$50 per million input/output tokens. Cache reads drop to $0.25/MTok (0.025x base input), the context window is 1M tokens, and adaptive thinking is always on. Claude Mythos 5.1 is the same underlying model with different safeguards, and only organizations verified through Anthropic's verification programs can use it. The verdict: moving from Fable 5 means changing one model string and handling three breaking API changes. Forced tool_choice is gone, thinking blocks are tied to the model that wrote them, and editing earlier turns invalidates them. Anthropic's own docs still say to start with Opus 5.5 and step up to Fable 5.1 for demanding long-horizon work or when your evals at higher effort fall short.

Last updated: October 17, 2026

This guide covers what changed, the exact errors you will hit, the code that replaces the removed patterns, and how to choose between Fable 5.1 and Opus 5.5. A note on how the examples were checked: no API key was available while writing, so the TypeScript snippets were type-checked against @anthropic-ai/sdk@0.135.0 (tsc --noEmit, strict, moduleResolution: bundler). The Python snippet was checked with python -m py_compile and mypy --strict against anthropic==1.15.0. None of the examples were run, and no model output is shown.

What shipped: Fable 5.1 vs Mythos 5.1 at a glance#

Anthropic describes Fable 5.1 as the successor to Fable 5 "for long-running agentic coding, knowledge work, and research." Its announcement says Fable 5.1 and Mythos 5.1 "are the same model, but with different levels of safeguards." Mythos 5.1 launched for Project Glasswing participants. Per the docs, access is limited to organizations verified through Anthropic's verification programs, such as the Cyber Verification Program. The announcement adds a Life Sciences Verification Program and says access is currently limited to a set of US organizations. For background on why Mythos is gated, see Claude Mythos 5 explained.

Two details are easy to miss. First, the tokenizer turns the same text into roughly 30% more tokens than models older than Opus 4.7 did. If you are coming from an older model, re-baseline token counts before you compare bills. Second, Priority Tier customers lose it on this model: Fable 5 supports Priority Tier and Fable 5.1 does not.

Pricing: why the 0.025x cache read matters#

Every price is the same as Fable 5 except cache reads.

The docs give the read multiplier some context. Cache reads cost 0.025x base input on Fable 5.1 and Mythos 5.1, 0.05x on Opus 5.5 and Sonnet 5.5, and 0.1x on other Claude models. That is a quarter of the Fable 5 rate ($1.00/MTok). Cache writes and the 512-token minimum cacheable prompt are unchanged.

Most of a long agent session is cache reads, so this is the line that moves the bill. Below is an illustrative session: list prices applied to an assumed token mix, not a measurement. It has one 200K-token 5-minute cache write, 40 reads of that 200K prefix (8M cache-read tokens), 300K uncached input tokens and 50K output tokens.

Two takeaways:

1. The same session costs 37.5% less on Fable 5.1 than on Fable 5. That falls inside Anthropic's own estimate of about 25% less for typical workloads and up to about 45% less for highly agentic work. Anthropic based that estimate on four weeks of August 2026 usage at default effort.
2. Fable 5.1's cache read ($0.25) is now close to Opus 5.5's ($0.20). The remaining 2.5x gap between the two models is in input, output and cache writes, so caching alone will not close it.

The write-versus-read break-even and TTL math in Fable 5 prompt caching economics still applies. Swap in $0.25 for the $1.00 read price, and the 1-hour TTL pays for itself even sooner.

Breaking change 1: forced tool_choice returns a 400#

Fable 5 accepted auto, none, any and tool for tool_choice. On claude-fable-5-1, {"type": "any"} and {"type": "tool", "name": "..."} return a 400 invalid_request_error:

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

The check covers the Messages API, the Message Batches API and the token counting endpoint. A batch job or a cost estimator that still forces a tool will fail too. auto (the default) and none are unchanged.

Anthropic's stated reason is that thinking is always on, and a forced tool call would skip it. The model would then write its working-out into the tool arguments, which makes the arguments worse. The right fix depends on why you were forcing the tool.

%% title: Replacing forced tool_choice
flowchart TD
  A["tool_choice any or tool"] --> B["400 invalid_request_error"]
  B --> C{"What did you need?"}
  C -->|"Schema-valid JSON"| D["auto + strict: true, or output_config.format"]
  C -->|"Model should use the tool"| E["Prompt names the tool"]
  C -->|"App requires the call this turn"| F["Append role: system message"]

The most common case is "I forced the tool to get structured arguments." Keep tool_choice: auto, set strict: true on the tool, and say in the prompt when to use it. The docs say Fable 5.1 "follows explicit tool instructions reliably."

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

// Fable 5: tool_choice: { type: "tool", name: "record_ticket" } forced the call.
// Fable 5.1: that returns a 400. Keep auto, make the tool strict, and name it in the prompt.
const response = await client.messages.create({
  model: "claude-fable-5-1",
  max_tokens: 16000,
  tools: [
    {
      name: "record_ticket",
      description: "Record a triaged support ticket.",
      strict: true,
      input_schema: {
        type: "object",
        properties: {
          severity: { type: "string", enum: ["low", "medium", "high"] },
          summary: { type: "string" },
        },
        required: ["severity", "summary"],
        additionalProperties: false,
      },
    },
  ],
  tool_choice: { type: "auto" },
  messages: [
    {
      role: "user",
      content:
        "Checkout returns a 500 for every EU customer since the 14:00 deploy. Call the record_ticket tool with your triage.",
    },
  ],
});

const call = response.content.find((block) => block.type === "tool_use");
if (!call) {
  // auto means the model may still answer in text. Treat it as a branch, not a crash.
  console.warn("No tool call. stop_reason:", response.stop_reason);
} else {
  console.log(call.name, call.input);
}

Note the explicit branch for a missing tool call. With auto, the API no longer guarantees that the model calls the tool. Code that read content[0] and assumed a tool_use block now needs to handle a text reply.

If you forced a tool only to get schema-conformant JSON and never needed the tool itself, move the schema to JSON outputs (output_config.format).

Sometimes your application, not the user, needs a specific tool called on the current turn of a multi-turn conversation. For that case the migration guide recommends appending a mid-conversation role: "system" message after the latest user turn. The message names the tool, says the call is required, and tells the model to open with it. It needs no beta header, and earlier turns stay byte-identical, so you keep your prompt cache hits. In Python:

import anthropic
from anthropic.types import MessageParam, ToolParam

client = anthropic.Anthropic()

triage_tool: ToolParam = {
    "name": "record_ticket",
    "description": "Record a triaged support ticket.",
    "strict": True,
    "input_schema": {
        "type": "object",
        "properties": {
            "severity": {"type": "string", "enum": ["low", "medium", "high"]},
            "summary": {"type": "string"},
        },
        "required": ["severity", "summary"],
        "additionalProperties": False,
    },
}

# Before (Fable 5):
#   client.messages.create(model="claude-fable-5", ...,
#       tool_choice={"type": "tool", "name": "record_ticket"})
# After (Fable 5.1): auto + strict tool + an instruction that names the tool.
history: list[MessageParam] = [
    {"role": "user", "content": "Checkout is down for EU customers since the 14:00 deploy."},
    {"role": "assistant", "content": "Understood. Do you want me to file it?"},
    {"role": "user", "content": "Yes, file it now."},
    # App-required call on this turn: append a system message, never edit earlier turns.
    {
        "role": "system",
        "content": "Tool-use requirement for the current turn: call record_ticket. "
        "Begin your response with the record_ticket tool call. Do not reply with text only.",
    },
]

response = client.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    tools=[triage_tool],
    tool_choice={"type": "auto"},
    messages=history,
)

tool_calls = [b for b in response.content if b.type == "tool_use"]
if not tool_calls:
    print("No tool call this turn, stop_reason:", response.stop_reason)

One gotcha for regulated deployments: CMEK organizations cannot use structured outputs on Fable models, and that includes strict: true. The migration guide says to rely on the prompt instruction alone there.

Breaking change 2: thinking blocks are bound to the model#

Every thinking block now records which model produced it, and only some models can read it. Fable 5.1 reads blocks from Mythos 5.1, Opus 5, Fable 5, Mythos 5 and earlier models, so a conversation that moves onto Fable 5.1 keeps its reasoning. Only Fable 5.1 and Mythos 5.1 can read Fable 5.1's blocks, though. If a conversation moves from Fable 5.1 to any other model, the reasoning is lost for the turns that run there.

%% title: One-way model binding
flowchart LR
  A["Opus 5, Fable 5, older"] -->|"kept"| B["Fable 5.1"]
  B -->|"kept"| C["Mythos 5.1"]
  B -->|"dropped"| D["Opus 5.5, Opus 4.8, fallback"]
  D --> E["Unbilled, model_binding_mismatch"]

This matters most for routers and refusal fallbacks. Fable 5.1's permitted fallback targets are Opus 4.8 and Opus 5, and neither can read its thinking. When a request carries a block the target model cannot read, the API drops the block before the model sees it and the request succeeds. Dropped blocks are not billed and do not count toward input_tokens. The cost shows up elsewhere: the target model has to re-plan without that reasoning, which the docs warn can raise cost and latency on the first turn after the switch.

Without a header, the drop is silent. With the thinking-binding-controls-2026-08-01 beta header, each dropped block appears in a top-level input_transformations array with reason: "model_binding_mismatch". After a model switch this is expected, not a bug. Log it anyway, so a router that keeps flipping between models shows up in your metrics.

Breaking change 3: the prefix check (edit history, lose thinking)#

This is the change most likely to break a hand-rolled agent. If you change anything that comes before a Fable 5.1 thinking block (the system prompt, the tools array or an earlier message), that block and every later thinking block become invalid. Where the check is enforced, the next request fails with a 400 like this:

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.

The error is permanent for that request body, so retrying the same request will not clear it. Mythos 5.1 does not run this check.

%% title: Thinking block prefix check
sequenceDiagram
  participant C as Client
  participant A as API
  C->>A: Turn 1
  A-->>C: thinking + signature
  C->>A: Turn 2, append-only
  A-->>C: 200 OK
  C->>A: Turn 3, edited system prompt
  alt prefix_mismatch_behavior error
    A-->>C: 400 bound to a different conversation
  else drop_block
    A-->>C: 200 + prefix_binding_mismatch
  end

Who is enforced, and when#

Whether the check is enforced depends on when your account was created, not on your code:

• Accounts created on or after August 31, 2026 00:00 UTC are enforced by default on Fable 5.1, Opus 5.5, Sonnet 5.5 and Haiku 5.5.
• Older accounts record the mismatch but only act on it when a request sets thinking.block_binding.prefix_mismatch_behavior, which opts that request into enforcement. If those accounts send the beta header and leave the field unset, they get thinking_mismatch_allowed entries in input_transformations instead.

The migration guide gives a quick test for your own account: send a request that edits history, without the beta header. If you get a 400 that names the header, your account is enforced by default. Anthropic's announcement calls the underlying rule an anti-distillation measure and says it will apply to all users with future model releases. An older account only buys you time.

A warning for library authors: if you ship a tool or framework that people run with their own API key, your key is probably on an older account. Your users on new accounts will hit the check before you do. Test with prefix_mismatch_behavior set before you release.

What counts as an edit#

According to the docs, these patterns invalidate every later thinking block:

• Editing, reordering or removing an earlier turn while keeping later ones.
• Adding per-request text to an earlier turn (a reminder or status line) and removing it 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 looks at the bytes, not the URL, so a rotating signed URL for the same file is fine.

These are safe:

• Removing a leading run of thinking blocks, oldest first.
• Letting server-side compaction or context editing trim the history.
• Moving cache_control markers.
• Changing effort between requests.

Claude Code, claude.ai, Claude Managed Agents and the Claude Agent SDK keep the prefix intact for you. The check matters if your own code builds the messages array.

Client-side compaction needs care. Suppose you keep recent turns word for word behind a summary. The migration guide says to strip the thinking blocks from those kept turns or set drop_block, because their thinking was produced against the full history.

error vs drop_block#

prefix_mismatch_behavior accepts "error" (the default) or "drop_block". With drop_block, the API removes the failing block and every later thinking block, and the request succeeds. Each removed block is reported in input_transformations with type: "thinking_dropped" and reason: "prefix_binding_mismatch". When streaming, the array arrives on the message_start event.

Dropping blocks has a cost. Anthropic tested it on a multi-turn coding benchmark, and the Preserved thinking page reports the extra output tokens:

Anthropic notes wide error bars, but the direction is clear. Treat drop_block as a safety net. An integration that trips it every turn pays in output tokens, especially at max.

The three-step audit#

The migration guide's integration check, condensed:

1. Capture two consecutive request bodies from a real session and diff system, tools and the shared messages prefix. Under the new rules, any difference is a bug.
2. Run a session with the beta header and prefix_mismatch_behavior: "drop_block", and log input_transformations on every response. An empty array means the history is intact. In CI, use "error" instead so any edit fails the run.
3. Pick a production setting. Use "error" if a mismatch can only mean a bug, or "drop_block" to keep going without the dropped reasoning instead of failing. Either way, monitor the 400s or the logged entries.

Here is step 2 as code. It also turns on the progress-update display, so the same run doubles as a UX check:

import Anthropic from "@anthropic-ai/sdk";
import type { BetaMessageParam } from "@anthropic-ai/sdk/resources/beta/messages/messages";

const client = new Anthropic();
const messages: BetaMessageParam[] = [
  { role: "user", content: "Find why tests/billing.spec.ts is flaky and propose a fix." },
];

async function turn() {
  const response = await client.beta.messages.create({
    model: "claude-fable-5-1",
    max_tokens: 16000,
    system: "You are a senior TypeScript reviewer.", // identical bytes on every request
    thinking: {
      type: "adaptive",
      display: "updates", // progress text in thinking blocks, reasoning stays hidden
      block_binding: { prefix_mismatch_behavior: "drop_block" }, // use "error" in CI
    },
    messages,
    betas: ["thinking-binding-controls-2026-08-01", "thinking-display-updates-2026-08-18"],
  });

  for (const t of response.input_transformations ?? []) {
    // prefix_binding_mismatch: something before t.path changed since the last request (a bug).
    // model_binding_mismatch: the conversation switched models (expected after a fallback).
    console.warn(`[binding] ${t.type} ${t.reason} at ${t.path}`);
  }

  for (const block of response.content) {
    if (block.type === "thinking" && block.thinking) console.log("status:", block.thinking);
    if (block.type === "text") console.log(block.text);
  }

  // Append-only: push the assistant content back exactly as returned.
  messages.push({ role: "assistant", content: response.content });
  return response;
}

await turn();
messages.push({ role: "user", content: "Apply the fix and show the diff." });
await turn();

The path field uses the same messages.{i}.content.{j} format as the error message, so it points straight at the block that failed.

The new betas that make append-only easy#

The prefix check pushes you toward a history you only ever append to. Three betas that shipped with or alongside Fable 5.1 cover the cases where people used to edit history.

Per-message effort (mid-conversation-output-config-2026-07-01). On Fable 5, output_config.effort was set per request, and changing it between requests lost the cached prefix from earlier turns. On Fable 5.1, you can append a role: "system" message that carries only output_config. It changes effort mid-conversation without invalidating the cache. The new level takes effect from the next user turn, and the accepted values are low, medium, high, xhigh and max. On Bedrock InvokeModel, put the beta value in the anthropic_beta array of the request body.

Turn-scoped system messages (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 the current turn only. The message stays in messages and you resend it unchanged. Once a later user message exists, it stops being shown to the model and costs no input tokens. The cache keeps matching and later thinking blocks stay valid. This replaces the pattern of adding a reminder and deleting it on the next request, which the prefix check now penalizes.

Progress updates (thinking-display-updates-2026-08-18). Before tool calls, Fable 5.1 writes short progress updates, each in its own thinking block. Under the default display: "omitted" those blocks come back empty, so a long agentic turn can look silent. display: "updates" returns the updates as text while the reasoning stays hidden. "summarized" returns them mixed in with summarized reasoning.

Here are both message-level betas in one request:

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

const response = await client.beta.messages.create({
  model: "claude-fable-5-1",
  max_tokens: 8000,
  output_config: { effort: "high" },
  messages: [
    { role: "user", content: "Design the schema for a multi-tenant audit log." },
    { role: "assistant", content: "Use one append-only events table keyed by tenant_id and created_at..." },
    // Effort-only system message: applies from the next user turn, cache stays warm.
    { role: "system", content: [], output_config: { effort: "low" } },
    { role: "user", content: "Rename the column actor to actor_id everywhere." },
    // Turn-scoped reminder: rendered for this turn only, resend it verbatim later.
    {
      role: "system",
      clear_at: "next_user_message",
      content: "Make a targeted edit. Do not rewrite the whole schema.",
    },
  ],
  betas: ["mid-conversation-output-config-2026-07-01", "mid-conversation-system-clear-at-2026-08-21"],
});

console.log(response.usage);

Tool changes got a fourth piece on September 22, 2026, per the release notes. Under the inline-tools-2026-09-15 header, a mid-conversation system message can carry tool_addition and tool_removal blocks, including a full tool definition. You can add or change tools without touching the top-level tools array, which would otherwise invalidate every thinking block. One limit from the migration guide: a message that carries tool changes cannot be turn-scoped. Our inline tool definitions guide covers the full pattern.

Watermarking, C2PA and 30-day retention#

In August we covered Anthropic's rollout of text watermarks and C2PA credentials in Anthropic's text watermarking and the EU code. The Fable 5.1 docs confirm both apply to this model:

• Text watermark. Text from Fable 5.1 and Mythos 5.1 carries Anthropic's statistical text watermark on every platform where the model is available. Per the docs, it adds no tokens or hidden characters, carries no information about you or your organization, and needs no changes to requests or responses.
• C2PA on media. Supported image, video and audio files that Claude produces (for example through the code execution tool) carry signed C2PA Content Credentials when you retrieve them through the Files API on the Claude API. If your pipeline re-encodes those files, check whether your tooling keeps the manifest.
• Why now. In July 2026 Anthropic signed the EU Code of Practice on Transparency of AI-Generated Content. Since August 2, 2026 the EU has required AI providers serving its market to mark AI-generated content, with a transition period for models launched earlier, per Anthropic's watermark article. A watermark detection API is in private preview for eligible organizations.

Check retention before you switch. Fable 5.1 and Mythos 5.1 are Covered Models with 30-day data retention. They are not available under zero data retention (ZDR) unless Anthropic expressly authorizes it. On the Claude API, a request from an organization or workspace without 30-day retention returns a 400 invalid_request_error.

Anthropic's announcement says Enterprise Frontier Safeguards will offer ZDR-equivalent privacy by storing data in cloud infrastructure the customer controls, rolling out in phases from fall 2026. Until then, it says, eligible customers can use Fable 5.1 with zero data retention. Confirm your organization's status before a cutover, not during it.

Behavior changes to prompt around#

These show up without any code change. Anthropic's Prompting Claude Fable 5.1 page has a prompting fix for each:

• Less consistent parallel tool calling. In long loops where the next independent reads are only implied, Fable 5.1 may make one tool call per turn where Fable 5 batched several. The migration guide's fix is a one-sentence batching instruction after each user message, ideally as a turn-scoped system message.
• Fewer progress updates, especially at higher effort. Use display: "updates". If your UI depends on narration, ask explicitly for an opening line and periodic updates.
• Fewer retrieval calls at low effort. At the lowest level the model answers from memory more often. Raise effort for turns that need fresh information. Per-message effort makes that cheap.
• Denser prose and less chat formatting. Anti-formatting rules written for older models can now strip out structure the content needs.
• Unmarked quotations in summaries. The model is more likely to copy passages from the source without marking them as quotes.
• Whole-file rewrites for small edits. The result is usually the same, but it costs more output tokens and time. Ask for targeted edits.

Effort needs a fresh sweep too. The default is high, and the docs say the gains over Fable 5 are largest at xhigh and max, which add thinking time and delay the first response. Anthropic recommends re-tuning rather than carrying over your Fable 5 settings. For reference, the announcement says Fable 5.1 defaults to High effort in Claude Code and Medium in Claude Cowork and on Claude.ai.

Refusals work the same as on Fable 5: HTTP 200 with stop_reason: "refusal" and a stop_details object. fallbacks: "default" (beta) retries on the model Anthropic recommends, and the permitted targets are Opus 4.8 and Opus 5. The fallback model does not receive Fable 5.1's thinking blocks. Two billing notes:

• Refusals that arrive before any output, in categories with low false-positive rates, have been billed since September 24, 2026.
• Fallback credit refunds the prompt-cache cost of switching models.

fallbacks is not available on Bedrock, Google Cloud or Foundry. Refusal-handling code you wrote for Fable 5 carries over.

Fable 5.1 vs Opus 5.5: which to call#

Opus 5.5 is the closest alternative, and Anthropic itself presents it as the default. Both models are strong. The choice comes down to cost, latency and compliance against extra headroom on the hardest tasks.

Anthropic's models overview says to start with Opus 5.5 for most workloads. It recommends Fable 5.1 for demanding reasoning and long-horizon agentic work, or when evals on Opus 5.5 at higher effort still fall short. Anthropic's reported benchmarks for Fable 5.1:

• Terminal-Bench 4.0: 55.8%, against 42.0% for Fable 5 and 60.9% for Mythos 5.1.
• CursorBench 3.2.0: 73.4%, against 70.5% for Fable 5.

Anthropic notes that safeguard interventions likely lower the Fable scores.

%% title: Fable 5.1 or Opus 5.5
flowchart TD
  A["Start with Opus 5.5"] --> L{"Long-horizon agentic work?"}
  L -->|"Yes"| D
  L -->|"No"| B{"Evals pass at xhigh or max?"}
  B -->|"Yes"| C["Stay on Opus 5.5"]
  B -->|"No"| D{"ZDR required?"}
  D -->|"Yes"| E["Check Fable 5.1 eligibility"]
  D -->|"No"| F{"Need Priority Tier?"}
  F -->|"Yes"| G["Fable 5.1 not supported"]
  F -->|"No"| H["Use Fable 5.1"]

A practical pattern is to route by step rather than by session: Opus 5.5 for routine turns, Fable 5.1 for the hard ones. Watch the binding rule if you do this. On the Claude API, moving a conversation up from Opus 5.5 to Fable 5.1 keeps its earlier reasoning. On Bedrock, Google Cloud and Foundry, that switch drops the Opus 5.5 thinking blocks too. Moving back from Fable 5.1 to Opus 5.5 drops Fable 5.1's thinking blocks on every platform. Where you can, route each conversation in one direction only.

Migration checklist (from Fable 5, and from Opus 5)#

The earlier Fable 5 changes (prefill, sampling parameters, adaptive-only thinking) are in Migrating to Claude Fable 5. The changes for 5.1:

1. Replace claude-fable-5 (or claude-opus-5) with claude-fable-5-1. On Bedrock, use anthropic.claude-fable-5-1.
2. Remove every tool_choice of type any or tool, including in batch jobs and token-counting calls. Use auto plus strict: true, output_config.format, or an appended system message.
3. Coming from Opus 5 or older: remove thinking: {"type": "disabled"}, budget_tokens, assistant prefill and non-default temperature/top_p/top_k. Each returns a 400.
4. Send thinking blocks back unchanged and only append to the history. Move injected reminders to turn-scoped system messages, and move system/tools changes to mid-conversation system messages.
5. Run the drop_block audit with the thinking-binding-controls-2026-08-01 header, and fix every prefix_binding_mismatch.
6. Pick a production prefix_mismatch_behavior and alert on 400s or input_transformations entries.
7. Re-sweep effort starting from the high default, and consider per-message effort instead of one level per session.
8. Add a batching instruction if your agent loop starts making one tool call per turn.
9. Re-baseline cost on real traffic. Cache-heavy sessions should get cheaper. If you are coming from a model older than Opus 4.7, account for the tokenizer difference.
10. Confirm you are eligible for 30-day retention, and check that you do not depend on Priority Tier.

Anthropic also ships a migration helper. In Claude Code, /claude-api migrate this project to claude-fable-5-1 runs the bundled Claude API skill. It applies the model swap and the breaking parameter changes, then gives you a checklist to verify by hand.

FAQ#

Is Fable 5.1 a drop-in replacement for Fable 5?#

Mostly. The API surface, limits, per-token prices (apart from cheaper cache reads), tokenizer, adaptive thinking and refusal handling all match. Three things break:

• Forced tool_choice returns a 400.
• No model except Mythos 5.1 can read Fable 5.1's thinking blocks.
• Editing anything before a thinking block invalidates it.

If your code builds the messages array itself, run the drop_block audit before switching.

Why does tool_choice any return a 400, and what replaces it?#

Thinking is always on, and a forced tool call would skip it, so the model would put its reasoning into the tool arguments and make them worse. Pick the replacement that matches what you needed:

• Structured arguments: tool_choice: auto plus strict: true on the tool and a prompt that names it.
• Structured data with no tool: JSON outputs via output_config.format.
• A call your app requires on this turn: an appended role: "system" message.

Will my agent break from the thinking prefix check?#

Only if it edits history: rebuilding system or tools, rewriting earlier turns, or adding per-request text and then deleting it. Accounts created on or after August 31, 2026 are enforced by default. Older accounts are enforced only when a request sets prefix_mismatch_behavior. To check your account, send a request that edits history without the beta header. A 400 that names the header means you are enforced.

Does the watermark change outputs or add tokens?#

No. Per Anthropic's docs, the statistical text watermark adds no tokens or hidden characters, carries no information about you or your organization, and needs no changes to requests or responses. Image, video and audio files retrieved through the Files API carry signed C2PA Content Credentials.

Should I use Fable 5.1 or Opus 5.5?#

Start with Opus 5.5, as Anthropic's docs recommend for most workloads. It is 2.5x cheaper on input and output, its latency is rated Moderate rather than Slower, and it is not a Covered Model. Anthropic recommends Fable 5.1 for demanding reasoning and long-horizon agentic work, or when your evals on Opus 5.5 at higher effort still fall short. Before you move a workload, confirm your 30-day retention and Priority Tier needs.

Sources#

• What's new in Claude Fable 5.1 - Anthropic docs
• Claude Fable 5.1 and Claude Mythos 5.1 migration guide - Anthropic docs
• Preserved thinking - Anthropic docs
• Prompting Claude Fable 5.1 - Anthropic docs
• Claude Developer Platform release notes - Anthropic docs
• Models overview - Anthropic docs
• What's new in Claude Opus 5.5 - Anthropic docs
• API and data retention - Anthropic docs
• Claude Fable 5.1 and Mythos 5.1 announcement - Anthropic
• How Claude's text watermark works - Anthropic

Continue Reading#

• Claude Opus 5.5 Developer Guide - the model Anthropic recommends starting with before Fable 5.1, with its own migration notes.
• Fable 5 Prompt Caching Economics - the write-versus-read and TTL math, which works out even better at Fable 5.1's $0.25 read price.
• Anthropic's Claude Text Watermarking and the EU Code - background on the text watermark and C2PA Content Credentials rollout that now covers Fable 5.1.