Fable 5.1 cuts cache reads by 75%: the new break-even for stuffing context
Anthropic released Claude Fable 5.1 and Mythos 5.1 in the first days of September, and the headline model changes are the ones you would expect: a stronger model, 52.6% on Terminal-Bench-Science, and a split into two safeguard levels, with Mythos reserved for vetted organizations in cybersecurity and life sciences. Input and output prices did not move: $10 per million input, $50 per million output, the same as GPT-6 Astra, which makes $10/$50 the effective frontier list price now. The number that changes my token budgets is the fourth one. Cache read dropped 75% to $0.25 per million, which is 2.5% of the input price.
What changed and what did not
Before 5.1, a cache read cost 10% of a fresh input token, so $1.00 per million against $10 input. Now it is 2.5%. Anthropic's own framing: roughly 25% savings on a typical workload and up to 45% on long agent runs. Both figures depend entirely on your cache-hit ratio, so recompute rather than quote.
| Line item | Before 5.1 | Fable 5.1 |
|---|---|---|
| Input, uncached | $10.00 / M | $10.00 / M |
| Cache read | $1.00 / M | $0.25 / M |
| Cache read as share of input | 10% | 2.5% |
| Output | $50.00 / M | $50.00 / M |
Where cache read dominates
Three workloads are almost entirely cache reads once they are warm, and they are the three I run most:
- RAG with a stable system prompt and corpus prefix. The retrieved chunks change; the instructions, schema and few-shot examples do not, and they are the bulk of the prompt.
- Long agent loops. Every turn re-sends the whole conversation. Turn 40 of a coding agent is 39 turns of cache read plus one turn of new tokens.
- Repeated code review over the same repository. The repo context is identical across reviews; only the diff is new.
For a loop that re-reads a 200,000-token prefix fifty times, that is 10 million cache-read tokens. At $1.00 that was $10.00 per run; at $0.25 it is $2.50. The output tokens for those fifty turns cost the same as before, so the total drops less than 75%, which is exactly what Anthropic's 25-45% range is telling you.
Cache read is now cheap enough that the question flips: not whether you can afford to keep something in context, but why you are paying to retrieve it at all.
The break-even that moved
The trade every RAG architect makes is between sending more context and retrieving more precisely. At 10% of input price, a cached 100,000-token prefix was still a real line item, and trimming it paid for itself. At 2.5%, the same prefix costs a quarter as much to re-read, and a lot of trimming work no longer clears the bar. The mechanics in prompt caching deep dive still hold; the constants changed.
What to recompute this week:
- Cache-hit ratio per workload, from your own logs, not from an estimate. The 25-45% range is meaningless without your number.
- Prefix size versus retrieval precision. Try doubling the stable prefix on one RAG path and measure quality and cost together.
- Agent step caps. If you capped loops to control cost, re-derive the cap.
- Caching you turned off. If cache writes ever looked too expensive relative to reads, re-run that comparison at the new read price.
- Your ROI models and client quotes. Date the change, note it, send it.
If you also serve local models, the same idea exists on your own hardware; prefix caching in local inference trades memory for prefill instead of dollars for tokens, and the break-even shifts the same way.
The honest gap
Every savings number here is Anthropic's, and my example is arithmetic on list prices, not a measured run. I have not verified the cache write price or the cache TTL for 5.1, both of which decide whether a workload with short gaps between calls ever reaches the cheap read path at all; check /prices before you commit the numbers to a quote. And the model quality claim rests on one benchmark figure. A cheaper cache read is only a saving if 5.1 is at least as good as what you run today on your own evals, which is a test, not a price sheet.