New to Claude Skills? Learn how to install them →

Claude Fable 5.1: What Changed, and What Breaks If You Upgrade

Claude Fable 5.1 shipped 1 September 2026 as the default Fable model, with a quarter-price cache read and three breaking changes for anyone calling Claude Fable 5 today.

September 2, 2026
Get Claude Skills
9 min read

What shipped on 1 September 2026

Claude Fable 5.1 (model ID claude-fable-5-1) launched on 1 September 2026 as the successor to Claude Fable 5, and it's now the default Fable model. Anthropic released it alongside Claude Mythos 5.1, which shares the same capabilities and pricing but is restricted to Project Glasswing participants, accessible only by contacting an Anthropic, AWS or Google Cloud account team.

The headline claim, direct from Anthropic's own models documentation, is that Fable 5.1 "extends Claude Fable 5 at the same input and output prices, with cache reads at a quarter of the cost, and brings stronger long-running agentic coding, multistep research, and document, spreadsheet, and slide work." Anthropic's own guidance is to start with Claude Opus 5 for most workloads, and reach for Fable 5.1 specifically for demanding reasoning and long-horizon agentic work, or when Opus 5 at higher effort still falls short.

This landed the same day Claude Code v2.1.257 shipped, which made claude-fable-5-1 the default Fable model in the CLI and added a couple of unrelated quality-of-life settings alongside it.

Where it sits in the lineup

Claude Fable 5.1Claude Opus 5Claude Sonnet 5Claude Haiku 4.5
Released1 Sept 202624 Jul 2026(balanced tier)(fast tier)
Context window1M tokens1M tokens1M tokens200K tokens
Max output128K tokens128K tokens128K tokens64K tokens
Input / output pricing$10 / $50 per MTok$5 / $25 per MTok$2 / $10 per MTok$1 / $5 per MTok
Cache read pricing$0.25 per MTok$0.50 per MTok$0.20 per MTok$0.10 per MTok
ThinkingAdaptive, always onAdaptiveAdaptiveExtended
Default efforthighhighhighNot supported
Comparative latencySlowerModerateFastFastest
Reliable knowledge cutoffJun 2026May 2026Jan 2026Feb 2025

Fable 5.1 is the most expensive model in the current lineup and the slowest, which matches its stated purpose: reach for it when Opus 5 isn't clearing the bar, not as a default. Claude Sonnet 5's pricing at $2/$10 remains the balanced middle of the lineup, unaffected by this release.

Pricing: what actually changed

Nothing changed for input or output. Fable 5.1 costs exactly what Fable 5 cost: $10 per million input tokens, $50 per million output tokens. The one price cut is cache reads, which drop from the standard Claude rate (10% of base input price, so $1 per million tokens on Fable 5) to 2.5% of base input price, or $0.25 per million tokens, a quarter of what Fable 5 charged. Cache writes are unchanged at $12.50 per million tokens (5-minute) and $20 per million tokens (1-hour), and the 512-token minimum cacheable prompt length carries over too.

That specific cut matters more than it might look. A long agentic session that repeatedly re-reads a cached system prompt and tool definitions, exactly the kind of long-horizon work Fable 5.1 is built for, pays a quarter of what the same session cost on Fable 5 for every one of those re-reads. Batch API pricing is unchanged from the standard 50% discount: $5 per million input tokens, $25 per million output tokens.

Three breaking changes if you're already calling Claude Fable 5

If you're moving existing code from claude-fable-5 to claude-fable-5-1, three behaviors are breaking rather than additive.

1. Forced tool use returns an error

tool_choice set to {"type": "any"} or {"type": "tool", "name": "..."} now returns a 400 invalid_request_error. The error message reads: tool_choice: type "tool" and "any" are not supported for this model. The default, {"type": "auto"}, and {"type": "none"} are unaffected. The same restriction applies to the token counting endpoint.

The reason is that adaptive thinking is always on for Fable 5.1, and a forced tool call would skip it, pushing the model's working-out into the tool arguments themselves and lowering their quality. If you relied on forced tool use to guarantee a call happened, the fix is tool_choice: {"type": "auto"} combined with strict: true (strict tool use) for schema-valid JSON, or a move to structured outputs. If you need the model to actually pick the tool rather than just format it correctly, state the condition in the prompt directly: "Use the get_weather tool to answer." Anthropic says Fable 5.1 follows explicit tool instructions reliably.

2. Earlier models can't read its thinking blocks

Every thinking block now records which model produced it, and compatibility runs one direction only: Fable 5.1 can read thinking blocks from earlier Claude models, but no earlier model can read blocks Fable 5.1 produced. A conversation that moves onto Fable 5.1 keeps its prior reasoning. A conversation that then falls back to an earlier model, through a router or a fallback rule, loses that reasoning for whichever turns ran on Fable 5.1: those blocks are silently dropped before the target model sees them (they don't count toward input_tokens and aren't billed). Opting into the thinking-binding-controls-2026-08-01 beta header makes that drop visible, reported in a top-level input_transformations array instead of happening silently.

3. Editing earlier turns invalidates thinking blocks

This is the one most likely to bite an existing integration. If your code edits, reorders or removes an earlier turn, injects and later deletes a per-request reminder, or rebuilds the top-level system prompt or tools array between requests in the same conversation, every thinking block after that edit becomes invalid. The next request either errors (The block is bound to a different conversation) or drops the block, depending on whether you've set thinking.block_binding.prefix_mismatch_behavior.

The check is enforced automatically for accounts created on or after 31 August 2026; older accounts get the mismatch recorded but not acted on unless the request explicitly sets that field. Claude Code, claude.ai and Claude Managed Agents already keep conversation history append-only for you, so this mainly matters if you're building the messages array yourself. The fix is to stop editing history: add instructions with a mid-conversation system message (turn-scoped if it's only relevant for one turn) instead of rewriting system, and change tools with mid-conversation tool changes instead of rewriting tools. Removing thinking blocks from the start of a run, letting server-side compaction trim history, and changing effort between requests are all still safe.

What's new, not just different

Five changes are additive rather than breaking:

  • Per-message effort (beta). Change the effort level mid-conversation without invalidating the prompt cache, raising it for a hard step and lowering it for routine ones. Requires the mid-conversation-output-config-2026-07-01 beta header.
  • Turn-scoped system messages (beta). A system message with clear_at: "next_user_message" carries system-prompt authority for one turn only, then stops rendering. Useful for per-turn reminders in a tool loop without injecting and deleting text from history, which would otherwise trip the thinking-block invalidation rule above.
  • Progress updates between tool calls (beta). Set thinking.display to "updates" to receive short status updates Claude writes between tool calls as visible text, rather than hidden inside an empty-looking thinking block.
  • The lower cache read price covered above.
  • Content provenance. Every response from Fable 5.1 and Mythos 5.1 carries Anthropic's statistical text watermark, on every platform. Images and video generated through the code execution tool carry signed C2PA Content Credentials when retrieved through the Files API. Neither changes the output's meaning, quality or token count.

What actually got better

Anthropic frames the capability gains as concentrated in six areas, widest at higher effort levels: agentic coding over long sessions (multi-file features, large refactors, debugging across hours-long sessions), knowledge work with documents, spreadsheets and slides, multistep research and search, vision (dense charts, filings, tables nested in PDFs), reasoning across the full 1M-token context window, and more reliable computer use with better recovery from failed steps. Multilingual performance is stated as on par with Fable 5, not improved.

Behavior changes worth knowing before you switch

A handful of default behaviors shifted even where nothing is technically broken, and each has a documented workaround:

  • Fewer parallel tool calls. Fable 5.1 may issue one tool call per turn where Fable 5 batched several, costing more round trips in long agent loops. A one-line prompt instruction to batch independent calls restores the old behavior.
  • Fewer progress updates during long tool runs, especially at higher effort. Set thinking.display to "updates" if your UI depends on narration.
  • Answers from memory more often at low effort, calling search or retrieval less. Raise effort for turns that need fresh information.
  • Denser prose and less chat formatting than earlier Claude models.
  • Unmarked quotations in summaries. The model is more likely to reproduce source passages without marking them as quotes when summarizing documents.
  • Whole-file rewrites for small edits. It's more likely to rewrite an entire file than make a targeted change, which costs more output tokens without changing the result.

What this means if you're building or maintaining skills

Nothing about the SKILL.md format changed. What's relevant is the same pattern this site covered when Opus 5 shipped: a model built for longer unsupervised runs raises the ceiling on how much procedure is worth writing into a skill, because it's more likely to still be on-track by step six. Fable 5.1's stated strength in exactly that kind of long-horizon agentic work makes it, in principle, an even better fit for that pattern than Opus 5, if your evals show it's clearing the bar Anthropic itself sets: use it when Opus 5 at higher effort still falls short.

One practical note if a skill's bundled scripts call the Claude API directly (rather than relying on the host agent's model): a skill that forces tool use with tool_choice: {"type": "any"} or names a specific tool will break outright if it's ever run against claude-fable-5-1, since forced tool use isn't supported on this model at all. Worth an audit if you maintain skills with bundled API-calling code, even if you don't expect Fable 5.1 to be the model actually executing them today.

Migrating from Claude Fable 5

If you're moving an existing integration, Anthropic's own checklist is:

  1. Update the model string from claude-fable-5 to claude-fable-5-1.
  2. Remove any tool_choice of type any or tool. Move schema enforcement to strict tool use with tool_choice: {"type": "auto"}, or to structured outputs.
  3. Pass thinking blocks back unchanged and keep conversation history append-only. If your code builds the messages array itself, run the history-editing check in Anthropic's migration guide before you ship.
  4. Re-tune effort from the default of high, and consider changing it mid-conversation instead of holding one level for a whole session.
  5. Watch agent loops for the one-tool-call-per-turn pattern and add the batching instruction if it matters for your latency budget.
  6. Re-run your evals. Refusal handling, fallback and fallback credit carry over unchanged; cache reads cost less; the behavior differences above are the main things likely to move a score.
model = "claude-fable-5"    # Before
model = "claude-fable-5-1"  # After

Availability

Claude Fable 5.1 is live now on the Claude API (claude-fable-5-1, all customers), Amazon Bedrock (anthropic.claude-fable-5-1), Google Cloud (claude-fable-5-1), Microsoft Foundry, and Claude Platform on AWS. It carries 30-day data retention and isn't available under zero data retention unless Anthropic expressly authorizes it, the same terms Fable 5 and Mythos 5 carried. Claude Mythos 5.1 stays invitation-only through Project Glasswing.

Where to go next

For the model that changed the shape of skill-writing advice before this one, see Claude Opus 5 and Agent Skills. For how Claude Code picks a default model and lets you override it, see Claude Code's modelPicker Setting and ANTHROPIC_DEFAULT_MODEL. If you're weighing a model choice against what it costs to run in production, Claude Code's /claude-api cost-optimize command and modelPricing for contracted rates are both worth a look. Browse the full catalog of skills built for whichever model you land on at getclaudeskills.com/skills.

Frequently asked questions