Claude Fable 5.1 vs Opus 5: Pricing and Cost per Task

Start with Claude Opus 5 for a general workload. At standard Claude API rates, its uncached input, cache writes, and output all cost half as much as Claude Fable 5.1. The exception is prompt-cache reads: Fable 5.1 charges $0.25 per million tokens, half of Opus 5's $0.50.

That is why both headlines—“Fable costs twice as much” and “Fable has cheaper cache reads”—can be true. Neither tells you which model will cost less for your work. You need the token categories, effort, tool rounds, retries, and accepted results from your workload.

Provider facts here were checked against Claude Platform documentation on September 3, 2026. Both models list a 1-million-token context window, 128K maximum output, and high as the default effort. Recheck prices, platform terms, and access before rollout.

Put both rate cards into the same equation

Anthropic's current pricing table separates five billable categories:

Batch halves base input and output for both models, so it does not change their 2:1 relationship on equal token quantities. US-only inference using inference_geo: "us" adds a 1.1 multiplier on supported direct Anthropic endpoints. Opus 5 fast mode has separate premium rates. Partner clouds, private offers, gateways, and taxes can produce a different invoice.

Let U be uncached input in millions of tokens (MTok), W5 and W60 the two cache-write categories, C cache-read MTok, and O output MTok:

Fable 5.1 = 10U + 12.5W5 + 20W60 + 0.25C + 50O
Opus 5     =  5U +  6.25W5 + 10W60 + 0.50C + 25O

Equal token counts without caching make Fable exactly twice the price. That is a useful budget baseline, not a prediction: different models and effort settings can use different numbers of turns, tool calls, and output tokens.

Cache reads can reverse the result, but the threshold is high

Ignore writes and other modifiers for one moment. With equal token counts, Fable costs no more than Opus when:

C >= 20U + 100O

Suppose a run uses 0.01 MTok of uncached input, 2 MTok of cache reads, and 0.002 MTok of output, with writes already amortized elsewhere. Fable costs $0.70; Opus costs $1.10. Now use 0.02 MTok of uncached input, 0.8 MTok of cache reads, and 0.01 MTok of output. Fable costs $0.90 and Opus $0.75. Output matters because its Fable premium is large.

Do not omit writes from the final ledger. Fable's write rates are still twice Opus's. Prefix churn, TTL expiry, or a changed tools array creates fresh writes and can erase the read advantage. Keep each usage category separate. For a Claude Code bill that jumps unexpectedly, use the cache-miss audit guide.

The “75% cheaper” launch phrase compares Fable 5.1's $0.25 cache read with Fable 5's former $1 rate. It does not mean an entire Fable 5.1 request costs 75% less.

Anthropic's own examples disagree for a useful reason

Anthropic's cost-and-intelligence guide reports a SWE-bench Pro subset where default Fable 5.1 and default Opus 5 scored 92.1% and 91.7%, a difference inside run-to-run noise. Opus cost about 15% less per solved task: $1.01 versus $1.19.

The same guide reports a different coding setup in which Fable 5.1 at medium matched default Opus 5 at $2.91 versus $8.50 per attempt. Those are Anthropic measurements on named harnesses, not independent leaderboard results or a forecast for your repository. The apparent conflict is the point: workload design and effort can reverse the cost ranking.

Effort belongs in the price comparison

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:

const 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." }],
});

The broad model page recommends Opus 5 as the starting point for most workloads, then Fable 5.1 when demanding long-horizon work or an Opus run at higher effort still misses. For a workload already known to be a long agent loop, include Fable 5.1 at low or medium in the first matched test. Effort is not a hard token budget; measure quality, output, tool rounds, and latency rather than assuming a label maps to a fixed spend.

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.

Check three compatibility changes before switching models

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 requires separate access approval

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-1 is available to Claude API customers and on the named partner platforms.
• claude-mythos-5-1 is 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 explains how to check approval with your account team.

Price accepted tasks, not requests

Choose a small, representative, non-sensitive task set. Run claude-opus-5 and claude-fable-5-1 from the same inputs, tools, permissions, provider, and acceptance condition. Pin effort explicitly. Start clean conversations rather than switching mid-session, which changes history reads and cache state. Record every token category, latency, tool rounds, refusals, 400 responses, retries, and human corrections.

Add the cost of failed attempts and retries, then divide by accepted tasks—not total requests. If Opus passes reliably, its lower standard rates make it the simpler default. Fable earns production traffic only when its lower cache-read bill, fewer failures, fewer rounds, or better acceptance rate offsets its input/output premium.

The operating rule is short: start ordinary work on Opus 5; test Fable 5.1 at reduced effort for very long, difficult, or cache-read-dominated agents; expand only when cost per accepted task or the acceptance rate improves. Do not build around Mythos until the account has explicit Glasswing approval.