Claude Cache Reads Just Got 75% Cheaper. Here Is the Math

On 1 September 2026, Anthropic cut the cache read price on Claude Fable 5.1 and Mythos 5.1 from $1.00 to $0.25 per million tokens. Cache writes did not move. That single change means your saving is not a flat percentage, it is 0.75 x (cache reads / your old bill), with a hard ceiling of 75%. If cache reads were a third of what you paid last month, you save about 25%. If they were 60%, you save about 45%. You can work out your own number from one field in the API response.

Key takeaways

• Cache reads on Fable 5.1 and Mythos 5.1 fell from $1.00 to $0.25 per million tokens, a 75% cut on that line only.
• Cache writes stayed at $12.50 per million (5 minute) and $20 (1 hour). Input and output stayed at $10 and $50.
• Your actual saving is 0.75 x (cache read share of your bill). Nothing else changes.
• The write to read ratio went from 12.5:1 to 50:1, which inverts the standard advice. Stop minimising reads. Start minimising invalidations.
• Both of Fable 5.1's breaking API changes force prefix rewrites, so the migration itself has a cache write bill.
• Cross vendor price tables on this topic are wrong by roughly a third, because Claude 4.7 and later tokenize the same text into about 30% more tokens.

Every dollar figure below is modelled from published rates, not lifted from our own invoices. We say so because most posts on this topic do not.

What actually changed on 1 September?

One number. Here is the full Fable 5.1 sheet as of 10 September 2026, taken from Anthropic's pricing page.

Line	Fable 5 (before)	Fable 5.1 (now)	Change
Input	$10	$10	none
Cache write, 5 minute	$12.50	$12.50	none
Cache write, 1 hour	$20	$20	none
Cache read	$1.00	$0.25	75% cut
Output	$50	$50	none

The cache read multiplier moved from 0.1x the input price to 0.025x. Everything else on the sheet is untouched, and the list price of the model did not move at all. This is a discount on exactly one line item, which is why the headline "Fable 5.1 is 25% cheaper" is true for some people and badly wrong for others.

How do you work out your own Claude cache read saving?

Because only one line moved, the arithmetic is fixed:

saving% = 0.75 x (cache read spend / total old bill)

That is the whole thing. Every one percent of your bill that was cache reads buys you 0.75 percent of saving. The ceiling is 75%, reached only if you somehow paid for nothing but cache reads.

Run it backwards and it tells you something about Anthropic. Their own announcement describes "around 25%" for typical workloads and "up to around 45%" for heavy ones. Solve for the cache read share:

• To save 25%, cache reads must be 33.3% of your old bill.
• To save 45%, cache reads must be 60% of your old bill.

So Anthropic's idea of a typical agentic workload is one where a third of the money went to re-reading the same context, and their idea of a heavy one is where it was closer to two thirds. That is a more useful description of the change than the percentage itself.

To find your own ratio, read the usage block on any API response. It reports cache_read_input_tokens separately from input_tokens and cache_creation_input_tokens. Multiply each by its rate, and you have your share. If you are eyeballing a lot of these by hand, our JSON Formatter makes the block readable in one paste.

What does that look like on a real agent session?

Take a session that looks like most coding agents in practice. Forty turns, a 60,000 token context prefix, a 95% cache hit rate, 1,500 output tokens per turn, and one 5 minute cache write of the prefix at the start.

Line	Tokens	At $1.00 read	At $0.25 read
Cache write	60,000	$0.75	$0.75
Cache reads	2,280,000	$2.28	$0.57
Fresh input	120,000	$1.20	$1.20
Output	60,000	$3.00	$3.00
Total		$7.23	$5.52

The saving is $1.71, or 23.7%. Cache reads were 31.5% of the old bill, and 0.75 x 31.5 is 23.6. The formula holds, and it lands almost exactly on Anthropic's "around 25%" claim without us having to take their word for it.

Notice what dominates the new bill. Output is $3.00 of $5.52, which is 54%. After this change, output tokens are the thing worth optimising on a session shaped like this one, not context. If you have never checked how long your agent's replies actually run, our word counter is a blunt but fast way to see how much text a typical turn produces before you go near a tokenizer.

What happens on a heavy agent loop?

Now push it. Two hundred turns, a 180,000 token context, a 98% hit rate, 800 output tokens per turn.

Line	Tokens	At $1.00 read	At $0.25 read
Cache write	180,000	$2.25	$2.25
Cache reads	35,280,000	$35.28	$8.82
Fresh input	720,000	$7.20	$7.20
Output	160,000	$8.00	$8.00
Total		$52.73	$26.27

That is a 50.2% saving, slightly better than the "up to around 45%" that Anthropic advertises. Cache reads were 66.9% of the old bill here, and 0.75 x 66.9 is 50.2.

The longer your context and the more turns you run against it, the closer you get to the 75% ceiling. Long horizon agents benefit most, and short one-shot calls with no cache benefit not at all.

Why does the advice about Claude cache reads now invert?

Cache writes did not move. So the ratio between writing a cache entry and reading it went from 12.5:1 to 50:1.

Under the old prices, a wasted cache write on a 60,000 token prefix cost $0.75, which was equivalent to about 750,000 cache read tokens. Under the new prices, that same $0.75 is equivalent to 3,000,000 cache read tokens. The write got four times more expensive relative to everything around it, without its price changing at all.

The practical rule used to be "cache aggressively, and try to read less". It is now closer to the opposite. Reads are nearly free. What costs you is breaking the prefix and paying to write it again. Every time you change a system prompt, reorder tools, inject a timestamp near the top of the context, or edit an early message, you invalidate everything after it and buy a fresh write.

One thing that did not change: break-even. A 5 minute cache entry still pays for itself after one read, and a 1 hour entry after two. Caching is still worth turning on almost always. The question has just moved from whether to cache to how rarely you can afford to invalidate.

Does the Fable 5.1 migration itself cost you money?

Yes, and this is where the two stories collide. Fable 5.1 shipped with breaking API changes, and both of the big ones force you to touch the cached prefix.

Tool choice. tool_choice values any and tool are gone and now return 400. Only auto and none remain. The replacement is "strict": true on the tool definition alongside name, description and input_schema, with additionalProperties: false in the schema, which gives you grammar constrained sampling instead. Tool definitions sit at the front of the context, so rewriting them invalidates the cache for every conversation you have running.

There is a real gap here worth knowing before you plan the work: computer_toolset_20260801 and browser_toolset_20260801 reject strict: true, so toolset based agents have no direct replacement path yet.

Thinking blocks are now model bound. For accounts created on or after 31 August 2026, replaying a thinking block after the system prompt, the tools, or an earlier message has changed returns 400. There is a beta header, thinking-binding-controls-2026-08-01, that gives you prefix_mismatch_behavior and an input_transformations field reporting which blocks were dropped. Fable 5.1 will accept thinking blocks from Opus 5, Fable 5 and Mythos 5, but older models cannot read Fable 5.1's.

There is a third change that has nothing to do with cost and will still stop some teams cold: 30 day data retention is mandatory on Fable 5.1 and Mythos 5.1, and the models are not available under zero data retention without express authorisation from Anthropic. If you sold a customer on ZDR, the cheaper cache reads are irrelevant to you until that is resolved. It appears in none of the launch roundups we checked.

How does the new price compare with Astra and Gemini?

Cache reads on one 60,000 token prefix, per turn, at rates checked on 10 September 2026:

Model	Cache read rate	Cost per 60k read
Meta Muse Spark 1.3 (see note)	$0.002	$0.00012
Gemini 3.8 Flash	$0.075	$0.0045
Claude Fable 5.1	$0.25	$0.015
Claude Opus 5	$0.50	$0.03
GPT-6 Astra	$1.00	$0.06

One caveat on that table before you use it. The four Claude, Gemini and OpenAI rows come from the vendors' own pricing pages. The Muse Spark row is second hand, taken from an aggregator rather than Meta's developer docs, so treat it as indicative until Meta publishes it directly.

The interesting row is the last one. GPT-6 Astra and Claude Fable 5.1 carry an identical $10 input and $50 output headline, and on that basis every comparison table calls them equivalent. On cache reads, Astra costs four times as much. For an agent that re-reads a large prefix on every turn, two models with the same list price produce very different invoices.

Two footnotes that change the shape of that table. Astra's price doubles above a 272,000 token input, and the higher rate applies to the whole request rather than only the tokens above the line. Gemini 3.8 Flash's rate is introductory and every figure exactly doubles on 1 January 2027, plus it charges cache storage as an hourly rent of $0.50 per million tokens per hour, which nothing else in this table does.

Is this comparison even fair?

Not quite, and the reason is buried in a footnote on Anthropic's own pricing page. Their wording: Claude 4.7 and later models use a newer tokenizer that "produces approximately 30% more tokens for the same text."

A price per million tokens is only comparable between vendors if a million tokens means the same amount of text. It does not. Fable 5.1's $10 per million input is closer to $13 per million tokens' worth of the same English text measured on the older tokenizer.

That does not undo the cache read finding, because the tokenizer inflates both sides of a Claude to Claude comparison equally, and 75% off is still 75% off. It does mean every cross vendor price table that skips the footnote is wrong by roughly a third in Claude's disfavour. If you are choosing between vendors on price, run your own text through both tokenizers before you trust anyone's per million figure, ours included.

What should you change this week?

• Pull your last month of usage data and compute your cache read share. That one number tells you your saving before you change anything.
• Audit what invalidates your prefix. Timestamps, request IDs, user names and reordered tool definitions near the front of a context are the usual culprits, and each one now costs 50 reads worth of writes.
• If output is now more than half your bill, as in our first model, move your optimisation effort there. Shorter responses beat shorter contexts at these prices.
• Check whether you are on zero data retention before planning a Fable 5.1 migration, because that is a blocker no discount fixes.
• Plan the tool_choice migration as one batch. Since every tool definition edit invalidates caches, doing it in five separate deploys costs five times the cache writes of doing it once.

Frequently Asked Questions

How much cheaper is Claude Fable 5.1 with the new cache read price?

Between 0% and 75%, depending entirely on your workload. The saving equals 0.75 multiplied by the share of your old bill that went to cache reads. A typical 40 turn agent session with a 60,000 token context saves about 24%, while a 200 turn session on a 180,000 token context saves about 50%. A one shot call with no caching saves nothing.

Did Claude cache writes get cheaper too?

No. Cache writes are unchanged at $12.50 per million tokens for a 5 minute entry and $20 for a 1 hour entry. Only the read price moved, from $1.00 to $0.25 per million. This is why the write to read ratio jumped from 12.5:1 to 50:1 and why avoiding cache invalidation now matters far more than it used to.

Is prompt caching still worth using after the price change?

Yes, and more so. Break even is unchanged: a 5 minute cache entry pays for itself after a single read, and a 1 hour entry after two. With reads at a quarter of their old price, the payoff after break even is four times larger. The only case where caching loses is a prefix you invalidate almost every turn.

What are the breaking changes in Claude Fable 5.1?

Three matter. tool_choice values any and tool now return 400 and are replaced by "strict": true on the tool definition. Thinking blocks are model bound for accounts created on or after 31 August 2026, so replaying one after the prefix changed returns 400. And 30 day data retention is mandatory, which means the model is not available under zero data retention without express authorisation.

Why do Claude and GPT-6 Astra cost differently if the list price is the same?

Because the list price only covers fresh input and output. Both are $10 and $50 per million, but Astra's cache read is $1.00 against Fable 5.1's $0.25, so an agent that re-reads a large context every turn pays four times more on Astra for that line. Astra also doubles its rate above a 272,000 token input, and that higher rate applies to the entire request rather than just the excess.

Work out your own number before you take anyone's percentage at face value. Paste a real API response into this free formatter, find cache_read_input_tokens, and run the one line of arithmetic above.

Written by Adithya Guttha, Founder of Art of Code.