Claude Fable 5.1 cost model
Updated September 1, 2026 · first published September 1, 2026
Claude Fable 5.1 (claude-fable-5-1) is priced at $10 per million input tokens and $50 per million output tokens. Opus 5 is $5 and $25. Read only those four numbers and Fable looks like a flat 2× premium. That is the wrong model. The cached-input rate moves in the opposite direction, and for a production workload the cache is usually where most of the tokens are.
The four rates that matter
A model is not one price. Fable 5.1 bills five different token types, and only two of them are on the headline.
| Token type | Fable 5.1 | Opus 5 |
|---|---|---|
| Input (uncached) | $10.00 / MTok | $5.00 / MTok |
| Output | $50.00 / MTok | $25.00 / MTok |
| Cache write (5-minute) | $12.50 / MTok | $6.25 / MTok |
| Cache write (1-hour) | $20.00 / MTok | $10.00 / MTok |
| Cache read | $0.25 / MTok | $0.50 / MTok |
The cache read is the outlier. It is 2.5% of Fable's own list input price, and it is half what the same cached token costs on Opus 5. Every other row is 2×; that one row is 0.5×.
What that does to a real workload
Take an agent with a 100,000-token system prompt, tool schema, and retrieved context, reused across a session. On a cold call the prefix costs $1.00 on Fable and $0.50 on Opus 5. On a warm call it costs $0.025 on Fable and $0.05 on Opus 5. The provider that was twice as expensive is now half the price, on the same prompt, because the only thing that changed is whether the prefix hit.
So the break-even is a cache hit ratio, not a model preference. Below roughly 50% of input tokens served from cache, Fable's input premium dominates and Opus 5 is cheaper on prefix. Above it, Fable's cached rate pulls ahead and keeps pulling. Output tokens stay 2× either way, which is why the second lever is output length, not model choice.
Output is the uncapped side
Fable 5.1 accepts a 1M-token context window and can emit up to 128K output tokens in one response. At $50 per million, a single 128K response is $6.40 of output. Extended thinking is always on for this model — there is no way to switch it off, and the old budget_tokens control is rejected with a 400. What you get instead is an effort setting from low to max. That is now a cost dial, and it belongs in your routing policy next to model choice, not in application defaults nobody revisits.
Raw reasoning is never returned, so your telemetry cannot reconstruct thinking cost from response text. You must read it from the usage block on every call and store it. There is no Priority Tier on this model either, so latency cannot be bought — capacity planning has to be done with concurrency and queueing on your side.
What to instrument before you route traffic
Three fields decide whether Fable 5.1 is cheap or expensive for you, and none of them appear on a price sheet.
- Cache hit ratio by feature. Not an account-level average — a chat surface at 90% and a batch job at 0% cancel each other into a meaningless 45%.
- Cache write amplification. A 1-hour write costs 2× list input. A prefix that is rewritten more often than it is read is a net loss at any TTL.
- Output tokens per successful task. The 2× output premium is only justified if fewer attempts are needed. Measure cost per successful task, not cost per call.
Then run the comparison as a variance bridge against your current model, splitting rate from volume from mix. A model that is twice the list price and half the cached price will show up as two large offsetting movements, and an average will hide both.
Related
Related
Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit →