Fable 5.1 Cache Reads Cost $0.25/MTok — Summarizing to Save Money Is Now a Losing Trade

Every LLM cost guide written in the last two years says some version of the same thing: context is expensive, so summarize it. Compact the conversation. Truncate old turns. Pass a digest instead of the transcript.

On Claude Fable 5.1, released 1 September 2026, that advice is now usually wrong — not because context got cheap in general, but because of a single footnote in Anthropic's pricing table that almost nobody has read.

The one number that changed

Fable 5.1 costs exactly what Fable 5 costs: $10 per million input tokens, $50 per million output tokens. Cache writes are unchanged too — $12.50/MTok for the 5-minute cache, $20/MTok for the 1-hour cache.

The cache read price went from $1.00/MTok to $0.25/MTok.

That looks like a routine discount until you check it against the rule the rest of the lineup follows. Every Claude model prices a cache hit at 0.1× the base input price. Fable 5.1 and Mythos 5.1 are priced at 0.025× — and the docs call this out explicitly as an exception:

Cache hits and refreshes on Claude Fable 5.1 and Claude Mythos 5.1 are priced at 0.025x the base input price. All other models use the standard 0.1x multiplier.

Here is the whole lineup in one table, with the ratio that actually matters in the last column:

Model	Input	Cache read	Output	Output ÷ cache read
Claude Fable 5.1	$10	$0.25	$50	200×
Claude Fable 5	$10	$1.00	$50	50×
Claude Opus 5	$5	$0.50	$25	50×
Claude Sonnet 5	$2	$0.20	$10	50×
Claude Haiku 4.5	$1	$0.10	$5	50×

Every model in the lineup has sat at 50× for years. Fable 5.1 sits at 200×. That is not a discount, it is a different cost structure — and it changes which architecture is cheapest.

Notice the second oddity while you're in that table: Fable 5.1's cache reads are cheaper in absolute dollars than Opus 5's, at $0.25 versus $0.50, even though Fable 5.1's input price is double. On a long agentic session where most input tokens are cache hits, the "expensive" model can be the cheaper one per turn. Nobody's mental model of the lineup accounts for that yet.

The arithmetic that kills the summarizer

Take a working assumption that matches most agent sessions: a stable prefix of 200,000 tokens — system prompt, tool definitions, the retrieved documents, the first several turns — that gets re-sent on every request.

Cost to re-read that prefix from cache, per request:

200,000 × $0.25 / 1,000,000 = $0.05

Five cents. Now price the "optimization" you were about to build. Summarizing that context into a 2,000-token digest costs you the output tokens:

2,000 × $50 / 1,000,000 = $0.10

The summary costs twice as much as re-reading the entire thing it replaces — and that's before counting the input tokens the model has to read in order to write the summary, and before counting the cache write you'll pay to cache the new, shorter prefix.

The break-even is brutal once you write it out. A 2,000-token summary must save you enough cache reads to cover $0.10. Each avoided read of the full prefix saves $0.05. So the summary pays for itself on the third request that uses it — assuming the summarized context never has to be re-expanded, and assuming you paid nothing to produce it, which you did.

On Fable 5 with $1.00 cache reads, that same prefix cost $0.20 per read and the summary paid for itself half a request in. The habit was correct. The price moved; the habit didn't.

When caching itself pays off

Worth recomputing the basics too, since the multipliers shifted. Sending N requests against the same prefix:

• Uncached: N × 1.0× base input
• 5-minute cache: 1.25× + N × 0.025×
• 1-hour cache: 2.0× + N × 0.025×

Solving for break-even: the 5-minute cache wins from the second read (1.25 ÷ 0.975 ≈ 1.28), the 1-hour cache from the third (2.0 ÷ 0.975 ≈ 2.05). Practically: if a prefix is going to be read more than once, cache it.

But look at the write-to-read ratio, because that is where the risk moved:

$12.50 write ÷ $0.25 read = 50×

On Fable 5 that ratio was 12.5×. A single cache miss now costs you what fifty cache hits cost. Cache hygiene stopped being an optimization and became the dominant cost variable — one stray datetime.now() in your system prompt, one unsorted JSON blob in a tool definition, one mid-conversation change to tools, and you're paying the 50× penalty on every request until the prefix stabilizes again. Verify with usage.cache_read_input_tokens on real traffic; if it's zero across repeated calls, something in your prefix is moving.

Three decisions that flip

1. Long agent loops: keep the transcript.

A 100-turn session against that 200K prefix costs 100 × $0.05 = $5.00 in cache reads on Fable 5.1. The same session on Fable 5 cost $20.00. If you built a compaction step to avoid that $20, you built it against a number that no longer exists — and the compaction step costs output tokens, adds a round trip, and throws away detail the model might have needed.

Anthropic's own migration guidance lands in the same place: keeping context is now cheap to re-read, while aggressive compaction costs capability. Compact when you approach the 1M context window or when the model is genuinely losing the thread — not to save money.

2. RAG: consider passing the whole document.

If your retrieval step exists to cut a 40,000-token document down to 4,000 tokens of top-k chunks, price both sides. Cached, the full document costs 40,000 × $0.25/1M = $0.01 per request. The chunked version costs $0.001. You are saving nine tenths of a cent per request, in exchange for every failure mode retrieval brings — wrong chunk, lost cross-references, missing table headers, the whole catalogue. At small scale that trade is now indefensible. At ten million requests a month it's $90,000, and it's a real engineering decision again. Do the multiplication before assuming which side you're on.

3. Sub-agent fan-out: the shared prefix got cheap.

Fan-out patterns pay for the shared context once per worker. When each worker's read of a shared 200K brief costs five cents instead of twenty, spawning ten workers to look at ten files costs $0.50 in shared context instead of $2.00. Fan-out that didn't justify itself on Fable 5 may justify itself now — the constraint that killed it was arithmetic, not architecture.

Where it does not flip

Be honest about the limits, because "context is cheap" is not the same claim as "context is free."

• Latency doesn't care about your bill. A 200K-token prefix still takes time to process on a cache read, and the 1M window still adds time-to-first-token. If you compact for responsiveness, keep compacting.
• Quality is a separate axis. A model reasoning over 800K tokens of half-relevant transcript is not sharper than one reading a clean 50K summary. The reason to compact was never only money — and the money reason is the one that just evaporated.
• Output tokens got no cheaper. They're still $50/MTok, still the most expensive thing you can do. Every architecture that generates text to save input tokens now looks worse, not better.
• Cache TTLs are real. Five minutes and one hour. A workload with a 90-minute gap between requests pays the write again — and at 50× a read, that's the expensive path.
• One-shot calls gain nothing. No second read, no cache benefit, no change.

The behavior change that quietly eats the savings

One more thing to price in, because it moves in the opposite direction. Anthropic documents that in long-running agent loops — custom coding agents, bash-and-editor harnesses, computer use — Fable 5.1 may issue one tool call per turn where Fable 5 batched several. Each extra turn is a full round trip: another cache read, another set of output tokens, more wall-clock time.

If your loop is chatty, that regression can consume a meaningful slice of the cache savings. The documented fix is a one-sentence batching instruction appended after each user message (as a turn-scoped role: "system" message in beta, or as a text block after the tool_result blocks), left in the history on later requests so it doesn't disturb the cached prefix.

Two related tuning notes from the same release, since they also show up on your bill: Fable 5.1 writes fewer progress messages between tool calls, and at low effort it answers from memory more often instead of calling a search or retrieval tool. If your product depends on retrieval at low effort, raise effort for those routes or tell the model explicitly when to search.

What to measure before you change anything

Do not refactor on the strength of a blog post's arithmetic — including this one. Instrument first:

1. Cache hit rate. usage.cache_read_input_tokens vs usage.cache_creation_input_tokens across a real session. At a 50× write/read ratio this is your single most valuable metric.
2. The split of your bill. Cache reads, uncached input, output. If output dominates, cache pricing is not your problem and this entire article is a distraction from your actual bottleneck.
3. Cost per completed task, not per request. A cheaper request that needs three more turns to finish the job isn't cheaper. This is the metric that catches the one-tool-call-per-turn regression.
4. Effort sweep, fresh. Default effort is high and all five levels (low through max) are supported. Fable 5.1's gains over Fable 5 are largest at xhigh and max, but those cost thinking time. A setting tuned for Fable 5 is not automatically right here — evaluate it on your own workload rather than inheriting someone else's number.

If you're building the measurement layer from scratch, that instinct — decide with numbers from your own traffic, not vendor benchmarks — is the same one that separates production LLM work from prototype work. It's the through-line of our LLM evaluation and testing course, and the context engineering course covers the specific case of deciding what stays in the window and what gets summarized.

Is Fable 5.1 worth $10/$50 at all?

Separate question, and worth stating plainly: Anthropic's own documentation recommends starting with Opus 5 for most workloads, at $5/$25, and moving to Fable 5.1 for demanding reasoning and long-horizon agentic work — or when your evals on Opus 5 at higher effort still fall short.

The published gains over Fable 5 are real and concentrated in agentic work: Terminal-Bench 4.0 at 55.8% vs 42.0%, Terminal-Bench-Science 0.1 at 52.6% vs 24.7%, AutomationBench at 31.4% vs 17.1%, CursorBench 3.2.0 at 73.4% vs 70.5%. Anthropic puts the net cost effect at roughly 25% lower for typical workloads and up to about 45% for highly agentic ones, driven by the cache read change.

Those are their benchmarks and their cost estimate. Yours will differ, which is the point of running the sweep. If you're choosing between tiers rather than tuning one, we keep a model comparison course current for exactly this decision, and the advanced LLM integration course covers the caching and context patterns underneath it.

TL;DR

• Fable 5.1 prices cache reads at 0.025× input ($0.25/MTok). Every other Claude model uses 0.1×.
• Output tokens now cost 200× a cache read. Generating a summary to avoid re-reading context is usually a net loss.
• Cache writes cost 50× a read — cache invalidation, not context size, is now your main cost risk.
• Fable 5.1 cache reads ($0.25) are cheaper than Opus 5's ($0.50), despite double the input price.
• Compact for the context window, for latency, or for quality. Do not compact for the bill.
• Watch for one-tool-call-per-turn in long loops; it can eat the savings.

There is a second half to this story that has nothing to do with money: on Fable 5.1, editing earlier turns to trim context can now get your request rejected outright with a 400. I wrote that one up separately, on CoderLegion, as "Claude Fable 5.1 Made Your Conversation History Append-Only." If you're planning to change your context strategy on the strength of the arithmetic above, read that before you ship it.

---

Prices, model behavior, and availability were checked against Anthropic's official documentation on 2 September 2026: the pricing page, the models overview, and the Fable 5.1 migration guide. Verify current figures before making commercial decisions — this is a fast-moving lineup.