Cache Economics: How Hit Rate Decides Your Real Agentic Bill

On September 1, 2026, Anthropic released Claude Fable 5.1 and cut cache read from $1 to $0.25 per million tokens, a 75% reduction. The community's first reaction was "agents got cheaper." That sentence can be true or empty: the bill is unit price times token structure. If cache read is a small slice, the cut moves total cost by single digits; if it dominates, the same price sheet saves far more.

This article does not compare who has the cheaper input price; that is not the question here. The question is how hit rate decides your agentic bill under a cache-first architecture: split tokens into four classes, give a cost formula, run a sensitivity analysis by load profile, and derive the engineering preconditions, plus where you capture nothing.

First, the caveat. Anthropic's published overall cost reduction of about 25%, and up to about 45% for workloads that depend heavily on cache read, are Anthropic's own estimates based on real August 2026 usage data, not independent third-party measurements; every saving figure here follows that caveat. Beyond Anthropic, we did not measure each vendor's cache pricing this batch, so we give no specific numbers, only relative relationships. Use each vendor's official website snapshot of 2026-09-02 as the source of truth.

1. The blind spot in a price table: an agentic bill is not one multiplication

A price comparison implicitly assumes "dollars per million input tokens" represents cost. That barely holds for single-turn Q&A and breaks inside an agent loop, not because of price but because of how tokens are composed.

Every round of an agent loop resends what it already processed: the repo file tree, files it read, conversation history, raw tool output. To the model this is known information, but at the API level it still counts as input tokens; caching is what stops that part from being billed at full price. So: the more rounds, the longer the context, the less new content per round, the higher the cache read share. Fable 5.1 supports a 1M-token context, and in long-context scenarios cache read volume is larger, amplifying the share.

Two teams on the same model, one says cheaper and one says more expensive. Neither miscalculated; their load structures differ. Before judging whether the cut helps, look at token structure.

2. Token composition and the cost formula

Split input tokens into three classes plus output:

Fable 5.1 specifics: input $10/M, output $50/M, cache read $0.25/M, 5-minute cache write $12.50/M, 1-hour cache write $20.00/M, batch input $5.00/M, batch output $25.00/M. Base prices are flat versus Fable 5.

The formula:

single call cost (USD) =
    fresh_input / 1e6 × P_fresh
  + cache_write / 1e6 × P_write
  + cache_read  / 1e6 × P_read
  + output      / 1e6 × P_out

whole-task cost = sum of per-round costs
cache read cost share = (cache_read × P_read) / total cost

Three places where intuition goes wrong. First, writing costs more than not writing: the 5-minute tier is 1.25× base input, the 1-hour tier is 2×, and caching only pays off once the same prefix is read enough times. Second, keepalive is not free: after TTL expiry the prefix is rewritten, and a low-frequency task may rewrite every round, swapping read price for write price. Third, output is 5× input: if every round emits long output, output overtakes cache read as the largest cost item, limiting the read cut's effect.

3. Token structure across four load profiles

The same price sheet produces completely different bills under different loads. The table below is a qualitative tiering, not measured data.

The key dividing line is the ratio of new content per round to already-processed content. A typical agent loop adds only one tool return or one diff per round while rereading everything, so cache read share rises with rounds. This is why the cache read unit price leverages agentic loads far more than single-turn Q&A.

4. Sensitivity analysis: what a 75% cut actually buys

Holding token structure constant, total cost reduction is roughly cache read bill share times 75%. Derivation from the official reduction, not a measured bill.

This table is a reverse ruler: a measured 10% total reduction implies cache read is about 13% of your bill, so the bottleneck is hit rate.

Calibrating: the ~25% overall reduction implies cache read is about a third of the bill, the ~45% agentic ceiling about 60%. Both are Anthropic's own estimates, not independent measurement.

Three second-order effects eat the reduction: the price drop pushes behavior toward longer context and more rounds; keeping the cache may mean a pricier long-TTL tier or keepalive calls, raising write cost; output price is unchanged, so longer output dilutes the read-side saving.

5. Why not apply this table across vendors

This piece verified only Anthropic. Other vendors' cache pricing was not measured per vendor this batch, so use each vendor's official website snapshot of 2026-09-02 as the source of truth. Fill in your own numbers along the dimensions below to apply the section-2 formula to any vendor.

This also explains why cheap input price and cheap bill decouple: a model with a lower input price but a low cache discount, a long minimum prefix, and a short TTL can cost more than a pricier rival under high-frequency load. Treat it as a six-dimensional vector.

Positioning-wise, Opus 5 sits lower on input price; GPT-5.6 Sol enters the discussion with a Terminal-Bench 4.0 score of 37.3%. DeepSeek-V4-Pro, Kimi K3, Qwen3.8-Flash-Next, GLM-5.3-Flash, and Gemini 3.7 Flash each have their own cache systems. The question: on the model you chose, what is your hit rate.

6. Five typical cache invalidation triggers

Hit rate is not given by the model; it is broken by your own writing.

The first two are most often dismissed. Changing the system prompt invalidates the whole prefix; splicing runtime state into it locks hit rate at zero. Rule: put only what is invariant in the prefix; move what varies to the tail.

The third trigger has extra severity on Fable 5.1. Officially, editing history turns invalidates thinking blocks is a breaking change, enforced for accounts created on or after August 31, 2026. On old accounts, client-side history reordering only silently blows the cache; on new accounts it also raises an error. Fable 5.1 upgraded cache discipline from a suggestion to a hard error if ignored. Migration details are in the Claude Fable 5.1 API Migration SOP.

The fourth matters for systems with a fallback path. Cache is bound to a specific model; one fallback switch re-bills the entire prefix at full price. If the system thrashes between tiers on rate limit or timeout, hit rate is repeatedly zeroed.

7. Raising hit rate: six engineering preconditions

1. Prefix invariance. Order by change frequency: system, tools, stable history, then this round's additions. Varying content in the prefix drags everything after it down.
2. Layout stability. Do not insert content into the middle of the context. Appending at the tail is safe; inserting in the middle invalidates the entire prefix after the insertion point.
3. Dynamic instructions go turn-scoped. Per-round instructions travel via turn-scoped system messages, not by rebuilding system or injecting per-turn reminders into messages.
4. Hand history trimming to the server. Client-side reordering of messages both blows the cache and, on new Fable 5.1 accounts, raises an error.
5. Pick TTL by call frequency. Base it on how many times the same prefix will be read within TTL, not "longer is better."
6. Make hit rate observable. Instrument all four token classes separately and treat cache read share as a first-class metric. Without that number, everything above is guessing.

Read hit rate in two senses: cache read over total input tokens (mechanism), and cache read cost over total cost (dollars). Because cache read is one-fortieth of base input price, the same token hit rate looks worse in the cost sense.

Finally, verify. Take a batch of representative tasks before and after the switch, fix the task set and round cap, and compare per-task cost and the four-class token composition. Task-set design is in the agent evaluation resource guide; the release is in Claude Fable 5.1 and Mythos 5.1: What Changed.

8. Conclusion: measure structure before price

• Unit price is the fourth factor. Hit rate, layout, rounds and output length come before it.
• A 75% cut scales with cache read's bill share. A third implies about 25%, six-tenths about 45%; both from Anthropic's estimates.
• Capture needs discipline, not a model swap. Invariant prefix, stable layout, TTL by frequency, observable hit rate.
• The overlooked case is capturing nothing. Dynamic prompts, per-round tool rebuilds, and model thrashing zero the hit rate.
• No instant change. Wire four-class instrumentation, run two fixed-task batches.

References

• Anthropic official announcement and pricing page (Claude Fable 5.1, released 2026-09-01): input $10/M, output $50/M, cache read cut from $1/M to $0.25/M (75% reduction), 5-minute cache write $12.50/M, 1-hour $20.00/M, batch input $5.00/M and output $25.00/M, 1M-token context, 128K max output. Specific URL unconfirmed.
• Anthropic official cost estimates, about 25% overall for typical workloads and up to about 45% for highly cache-dependent agentic loads, Anthropic's own estimates, not independent third-party measurement.
• Other vendors' cache pricing, read discount, write premium, TTL tiers, minimum cacheable prefix, and billing granularity, not measured per vendor this batch. Use each vendor's official website snapshot of 2026-09-02 as the source of truth; no specific numbers given here.
• Fable 5.1 breaking change editing history turns invalidates thinking blocks, enforced for accounts created on or after 2026-08-31, from the official announcement, URL unconfirmed.
• Opus 5 price about half of Fable 5, GPT-5.6 Sol Terminal-Bench 4.0 score 37.3%, from each vendor's public information, for positioning only.
• Sections 3 through 5 tables are arithmetic derivations and qualitative tiering from the official reduction, not measured bills; the rest are engineering recommendations, flagged in place.

FAQ

Q1: Cache read dropped 75%, so why did my bill barely move?

A1: The unit price dropped, but the bill is unit price times token structure. Only when cache read dominates does a 75% cut mean a real reduction; compute the cost-share first, a 10% share buys only about a 7.5% total cut. If the share will not rise, the cause is low hit rate.

Q2: How should cache hit rate be defined and computed?

A2: In two senses. The token sense is cache read over total input tokens; the cost sense is cache read cost over total cost. Because cache read is far cheaper than base input, the same token hit rate looks much lower in the cost sense.

Q3: Does changing the system prompt really invalidate the whole cache?

A3: Yes. The hit precondition is a byte-identical prefix, and the system prompt is its first segment, so one changed character invalidates everything after it. The common mistake is splicing per-round state like current time or task ID into the system prompt, which locks hit rate at zero.

Q4: How to choose between the 5-minute and 1-hour cache tiers?

A4: By how many times the same prefix is read within TTL, not "longer is better." Write price is above base input ($12.50/M at 5 minutes, $20.00/M at 1 hour); read once within TTL and you pay write price, pricier than no cache. High-frequency calls suit a long TTL.

Q5: Will multi-model routing and fallback eat the entire cache dividend?

A5: Yes, more thoroughly than most expect. Cache is bound to a specific model, so one switch re-bills the whole prefix at full price. If the system thrashes between tiers on rate limit or timeout, hit rate is repeatedly zeroed; treat fallback as a cost event with a threshold and cooldown.