Cache reads fall to $0.25 per million tokens. A worked cost example explains why that does not cut an entire Claude API bill by 75%.
Anthropic's Fable 5.1 announcement lowers cache reads to $0.25 per million tokens, a 75% reduction on that billing line. The model identifier is claude-fable-5-1. The percentage is useful only after separating cached reads from the rest of your usage.
A worked example, not a benchmark
Consider a hypothetical usage period containing one million ordinary input tokens, one million five-minute cache-write tokens, twenty million cached-read tokens and one million output tokens. At $10 for ordinary input, $12.50 for those writes and $50 for output, changing only reads from $1 to $0.25 gives:
| Billing line | Before | After |
|---|---|---|
| Ordinary input | $10.00 | $10.00 |
| Five-minute cache writes | $12.50 | $12.50 |
| Cache reads | $20.00 | $5.00 |
| Output | $50.00 | $50.00 |
| Total | $92.50 | $77.50 |
The saving is $15, or approximately 16.2% of this example's total, despite the 75% reduction on reads. This is an illustrative calculation, excluding taxes, platform-specific charges, batch discounts and one-hour cache writes. It is not a measured customer workload.
To reuse the calculation, replace each volume with your own recorded token count. Do not multiply the whole invoice by 0.25. A workload dominated by output will behave differently from one that repeatedly reuses a large context.
Read the right counters
The prompt-caching documentation separates input_tokens, cache_creation_input_tokens and cache_read_input_tokens. Ordinary input is not the total input: add the three counters to reconstruct it. Keep five-minute and one-hour writes separate when both appear in usage data.
For an audit, group usage by model, provider and day before calculating costs. Keep a sample of individual responses beside the aggregate so you can investigate discrepancies. Count retries too: the cost of a completed task can rise even while the nominal token rate falls.
Keep the cached prefix stable
Caching requires identical prompt segments through the cache breakpoint. Put changing request content after the reusable section. A timestamp inserted into that section can prevent a hit. A changing HTTP request identifier is not, by itself, evidence that the prompt prefix changed.
A useful check is to repeat an otherwise identical request, inspect the cache counters, then change one prompt segment deliberately. Record the configuration and timing for each attempt. That isolates caching behaviour more clearly than watching the monthly invoice and guessing.
Recheck quality separately
Recalculate costs and evaluate model behaviour as separate steps. Keep the same task set, acceptance criteria and tooling when comparing models or effort settings. Report completed tasks, retries and failures alongside cost. No benchmark chart is reproduced here because this article supplies billing arithmetic, not independent model-performance measurements.
September 7 revision: primary sources reviewed and practical explanation rewritten; no independent test results claimed.