What changed on October 7, and what did not
On October 7, 2026 Anthropic lowered the prompt cache read price on Claude Sonnet 5.5 from $0.20 to $0.10 per million tokens. That is 0.05x the base input price instead of 0.1x. Cache writes and all other prices were unchanged.1 Sonnet 5.5 input is $2 per MTok, a 5-minute cache write is $2.50, a 1-hour write is $4, and output is $10.2
The obvious reading is "caching got better, turn it on everywhere". That is only half right. Two separate questions are involved:
- Does a cache write pay for itself? This is a threshold question about hit rate.
- What does a warm prefix cost once it is paying? This is a steady-state question about read price.
The cut mostly answers the second. The first barely moved, and that matters because the first is the one that decides whether a sparse or bursty workload should be cached at all.
The break-even, with write cost in it
Let w be the write multiplier on the base input price, r the read multiplier, and h the share of requests that find a warm prefix (the rest are cold and pay the write). Caching beats no caching when:
h·r + (1 − h)·w < 1
Solving for the threshold gives h* = (w − 1) / (w − r).
def break_even_hit_rate(write_mult: float, read_mult: float) -> float:
"""Share of requests that must read a warm prefix for caching to beat no caching."""
return (write_mult - 1) / (write_mult - read_mult)
def prefix_cost_per_request(prefix_tokens, base_per_mtok, write_mult, read_mult, hit_rate):
per_mtok = base_per_mtok * (hit_rate * read_mult + (1 - hit_rate) * write_mult)
return prefix_tokens / 1_000_000 * per_mtok
# Sonnet 5.5, 5-minute write (1.25x), read 0.05x since Oct 7
print(break_even_hit_rate(1.25, 0.05)) # ~0.208
# Same write, old read 0.10x
print(break_even_hit_rate(1.25, 0.10)) # ~0.217
# 1-hour write (2x)
print(break_even_hit_rate(2.0, 0.05)) # ~0.513The multipliers come from Anthropic's pricing page: a 5-minute write is 1.25x base input, a 1-hour write is 2x, and a read is 0.1x by default, 0.05x on Opus 5.5 and Sonnet 5.5, and 0.025x on Fable 5.1 and Mythos 5.1.2
| Model | Read multiplier | 5-minute write (1.25x) | 1-hour write (2x) |
|---|---|---|---|
| Sonnet 5.5 before Oct 7 | 0.10x | 21.7% | 52.6% |
| Sonnet 5.5 now | 0.05x | 20.8% | 51.3% |
| Opus 5.5 | 0.05x | 20.8% | 51.3% |
| Fable 5.1 | 0.025x | 20.4% | 50.6% |
The threshold moved by less than a point. Anthropic's own wording is that caching pays off after one cache read for the 5-minute duration and after two for the 1-hour duration;2 the table says the same thing as a rate. If your workload cleared the bar before the cut, it clears it now. If it missed the bar, the cut did not rescue it.
What a warm prefix costs now
Take a 50,000-token prefix, which is an ordinary size for a tool-heavy agent or a document-QA setup. Uncached, it costs $0.100 per request on Sonnet 5.5.
Read the first row first. At a 0% hit rate you pay the write premium on every request: a quarter more than not caching for the 5-minute TTL, and double for the 1-hour TTL. The cut did nothing for that row. Its effect is in the bottom rows, where the cost of the prefix drops by roughly 30% relative to the old read price (from $0.016 to $0.011 at 95%).
Agents and coding tools: where the gain is, and where it moved
A long agent loop is the case caching was made for, because each turn re-sends everything before it. Two things are specific to the growing prefix. The new tokens each turn (tool output, the model's last message, the user's reply) are written at 1.25x, and they are written whether or not the session lives long enough to read them back.
The split is the useful part. Before the cut, reads were roughly two thirds of the cached bill. Now writes (about $0.38 of $0.73, counting the first write) are about half and reads are 48%. Three practical consequences follow:
- Prefix churn costs more than it did. Anything that rewrites earlier turns, such as trimming old tool results or editing the system prompt mid-session, invalidates the cache from the edit point onward, so the whole tail is rewritten at 1.25x.34 Compaction is a real cost event, not free housekeeping.
- Large tool outputs are the new lever. A 20,000-token file dump enters the prefix once at the write rate and is then read on every later turn. Truncating it before it enters costs nothing in cache terms.
- Turn gaps decide hit rate. The lifetime is measured from the start of the request that wrote or last read the entry, not from the end of the response, and a read refreshes it at no extra cost.3 An agent that streams for four minutes has about a minute left to start the next call. Test runs, builds and human approval pauses longer than the TTL turn the next turn into a full-prefix rewrite.
If those pauses are common in your sessions, a 1-hour write is worth pricing, because a stalled session otherwise rewrites a 150,000-token prefix at $2.50 per MTok (about $0.38) to resume.
RAG: cache the stable part, not the retrieved part
In a typical RAG request the prefix is the system prompt, tool or schema definitions and any fixed instructions, and the retrieved chunks differ per query. The cache matches an exact prefix of tools, system and messages, in that order, up to the block marked with cache_control.3 Put the breakpoint after the stable block and before the retrieved text; if chunks come first, nothing after them can hit.
The second shape is where the cut helps most: a large, shared, repeatedly queried context. The first is where cache hits depend on there being enough traffic on that one prefix to keep it warm.
TTL and traffic shape: when the 1-hour write wins
Hit rate is a property of arrival gaps, not of volume. Assume, for illustration, that requests to one prefix arrive as a Poisson stream (random, memoryless). A request hits if the previous request to that prefix started within the TTL.
The shape of the table is the finding. At gaps of a minute or so the TTL does not matter. In the 10 to 60 minute band the 5-minute entry expires between most requests and keeps charging 1.25x writes, while the 1-hour entry stays warm. Past roughly an hour, the 1-hour entry loses its edge too, and at a 90-minute mean gap both cost more than no caching.
Real traffic is rarely Poisson, and two shapes break the table:
- Bursty traffic does better than the table, because requests cluster and the first one warms the rest.
- Metronome traffic, such as a cron job every 6 minutes against a 5-minute TTL, does worse. Every request is cold, the hit rate is 0%, and you pay 1.25x on all of them. Move the schedule inside the TTL, move to the 1-hour write, or leave the job uncached.
Which workloads gain and which stay uncached
| Workload | Prefix behaviour | Verdict |
|---|---|---|
| Interactive coding agent | Large, append-only, gaps mostly under 5 minutes | Cache; watch long tool runs and compaction |
| Agent with human approval steps | Large, gaps often over 5 minutes | Price the 1-hour write against your measured hit rate |
| Long-document QA | Large, shared, bursts of questions | Cache; the best case |
| RAG with per-query chunks | Small stable prefix, volatile tail | Cache only the stable block; gain depends on prefix size |
| High-volume classification with a short fixed prompt | Small prefix, constant traffic | Cache if the prefix is large enough to qualify; dollar gain is small |
| One-shot unique documents (summarise once) | Never re-read | Stay uncached; the write premium buys nothing |
| Periodic jobs with gaps over the TTL | Cold every time | Stay uncached, or look at batch processing5 |
| Prompts with timestamps or user names near the top | Prefix differs each time | Fix the prompt first; caching cannot help |
Measure it, then decide
The inputs that matter are the real prefix size and the real hit rate for each prefix, and both come from responses, not estimates.
- Pull cache-write, cache-read and uncached input token counts for each request over a representative week, grouped by prefix (project, route or agent), not fleet-wide.
- Count prefix tokens with the model you are moving to. Anthropic notes that Claude 4.7 and later models use a tokenizer that produces roughly 30% more tokens for the same text, so a prefix sized on an older model understates the new one.2
- Compute the observed hit rate per prefix and compare it with 20.8% for a 5-minute write and 51.3% for a 1-hour write.
- For prefixes below the line, look at the arrival-gap histogram: gaps just over 5 minutes point to the 1-hour write or a schedule change; gaps over an hour point to no caching.
- Re-run the arithmetic with your contracted rates if they differ from list.
A gateway helps with the bookkeeping, not with the pricing. INFRO passes provider caching through unchanged, reads the cached-token counts your provider reports, and prices them at the cached rate in usage.cost per request, so cached and cold requests can be compared by project and key; your provider still invoices you directly. Enter negotiated rates under custom rates and the estimates use them before list. One caching-specific caveat from INFRO's docs: caches live with the upstream that served the request, so a failover to another connection starts that prefix cold.4 INFRO's traffic-change findings also include a lost prompt cache, with an estimated weekly cost change, which is the signal to watch after a prompt edit or a routing change.
The rest is the same discipline as before October 7: keep the prefix stable, keep the volatile content last, and let the measured hit rate, not the price list, say which prefixes earn a cache entry.