Claude Fable 5.1 is not a blanket 75% price cut. It keeps Fable 5's $10 per million input tokens and $50 per million output tokens. The economic change is narrower and potentially more useful: a cache read now costs $0.25 per million tokens instead of $1.
That makes the upgrade attractive for agents that repeatedly read a large, stable prefix. It does almost nothing for a workload whose input changes on every call. Before changing claude-fable-5 to claude-fable-5-1, separate those two cases and check the request features that no longer work.
All provider facts below were checked against Claude Platform documentation on September 3, 2026. Recheck mutable pricing, retention, and availability before a production rollout.
Start with a token ledger, not a headline discount
Anthropic's current pricing table lists the same rates for Fable 5.1 and Mythos 5.1:
| Token category | USD per MTok |
|---|---|
| Base input | $10 |
| 5-minute cache write | $12.50 |
| 1-hour cache write | $20 |
| Cache hit or refresh | $0.25 |
| Output | $50 |
Batch input and output cost $5 and $25 per MTok. US-only inference using inference_geo: "us" applies a 1.1 multiplier to every token category. Cloud marketplaces and gateways can add their own terms, so these figures are an upstream list-price baseline rather than a promised invoice.
Two percentages describe the cache change. Cache reads are 75% cheaper than Fable 5's former $1 rate. They are also 97.5% cheaper than processing the same tokens as uncached $10 input. Saying “Fable 5.1 is 75% cheaper” drops the denominator and is usually false.
The break-even point depends on write duration
Consider a one-million-token prefix and ignore the changing suffix and output for a moment.
A 5-minute cache write followed by one hit costs $12.50 + $0.25 = $12.75. Processing the prefix twice without caching costs $20. The cache wins on the second use if the prefix matches and the hit lands before expiry.
A 1-hour write followed by one hit costs $20.25, slightly more than two uncached uses. Add a second hit and the total becomes $20.50 versus $30 uncached. In this simplified example, the longer write becomes cheaper on the third use.
Real billing should preserve the categories returned in usage:
texttotal = base_input_mtok * 10 + cache_write_5m_mtok * 12.50 + cache_write_1h_mtok * 20 + cache_read_mtok * 0.25 + output_mtok * 50
Track cache creation and reads separately. A blended “input discount” hides prefix churn, TTL misses, and accidental changes to system prompts or tool definitions. Teams diagnosing sudden Claude Code session costs have a different task; use the cache-miss audit guide for that path.
Omitted effort means high
The Effort reference states that omitting output_config.effort is exactly equivalent to setting high. Fable 5.1 supports low, medium, high, xhigh, and max. Adaptive thinking is always on; effort steers work across thinking, visible text, and tool calls.
Set the value explicitly so a cost or latency baseline cannot be misread later:
typescriptconst response = await client.messages.create({ model: "claude-fable-5-1", max_tokens: 16000, output_config: { effort: "high" }, messages: [{ role: "user", content: "Review this rollout plan." }], });
High is a sensible first migration point, not a universal optimum. Run routine classification and transformation cases at medium or low. Compare high, xhigh, and max on the few long-horizon coding or research tasks where quality can justify more tokens and latency. Effort is a behavioral signal rather than a hard token budget, so only your eval set can identify the useful step-down.
Fable 5.1 also introduces per-message effort in beta. A mid-conversation system message can change the level without invalidating the cached prefix. Changing the top-level effort value on a later request starts the cache over. If dynamic effort is part of the design, use the current beta header and test cache counters rather than assuming both mechanisms behave the same.
Three compatibility gates come before the model-ID edit
The official migration guide identifies changes that a one-line model replacement can miss.
First, forced tool use is unsupported. tool_choice with type any or a named tool returns a 400 invalid_request_error. Keep auto or none. When schema-valid output matters, use strict: true with automatic tool choice or structured outputs. When the application needs a particular tool, make that requirement explicit in the instruction and validate the call.
Second, thinking blocks are forward-readable, not backward-readable. Fable 5.1 can consume blocks made by earlier Claude models. An older fallback model cannot consume blocks made by Fable 5.1. A router that moves backward mid-conversation must expect those blocks to be dropped instead of assuming full state continuity.
Third, Fable 5.1 can bind thinking blocks to the conversation prefix. Editing an earlier message, rebuilding system, or changing the tools array can invalidate later blocks. The safest self-managed history is append-only. Use server-side context editing or compaction when possible, and run the migration guide's prefix check before sending production traffic. Enforcement timing differs for older accounts, which makes a canary more important, not less.
Do not try to solve forced tools by disabling thinking. Fable 5.1 always uses adaptive thinking; manual budget_tokens and thinking: {type: "disabled"} return errors.
Mythos 5.1 is an approval boundary, not a public upgrade tier
Anthropic's Fable 5.1 release documentation describes Fable 5.1 and Mythos 5.1 as sharing capabilities, specifications, and prices. Availability is the actionable difference:
claude-fable-5-1is available to Claude API customers and on the named partner platforms.claude-mythos-5-1is limited to approved Project Glasswing participants.- Both carry 30-day data retention unless Anthropic expressly authorizes otherwise.
- Neither currently supports Priority Tier.
A model card or cloud catalog entry is not account entitlement. If there is no written organization-level approval, build against Fable 5.1. The Mythos access guide covers the separate evidence and account-team question.
A migration canary should prove both quality and economics
Clone a representative, non-sensitive request set and keep Fable 5 as the baseline. Change the model ID, remove forced tool choice, and pin effort explicitly. Record base input, cache creation, cache reads, output, latency, tool rounds, refusals, and 400 responses.
Expand traffic only when the existing task eval passes, the observed cache-hit ratio supports the projected saving, and the integration handles stop_reason: "refusal" separately from transport failures. Roll back the model ID if any gate fails. Raising effort is not a fix for a broken tool contract or mutated history.
The practical rule is short: migrate when stable prefixes are reused and the compatibility canary passes; run an ability-first eval when most input is unique; keep Mythos out of the executable plan until the account has explicit Glasswing approval.
