Claude Prompt Caching: The Real Cost Math

Prompt caching is the highest-leverage cost lever on Claude, and also the one teams most often get subtly wrong — paying the write premium on every request and never collecting the read discount. It is not a feature you switch on; it is a pricing trade you have to set up correctly. The good news is the trade is governed by two numbers, and once you know them the decision is arithmetic.

This post is the arithmetic: what a cache write and a cache read actually cost relative to a normal token, where the break-even sits, when it does not pay off, and how to run it so the savings are measured rather than assumed. All the multipliers below are from Anthropic’s prompt caching documentation, as of October 2026.

The two numbers that decide everything

Caching reuses a previously processed prompt prefix so Claude does not re-read it. You pay a premium to write a prefix into the cache, then a deep discount to read it on later requests.

A 5-minute cache write costs 1.25x a normal input token. The 1-hour write costs 2x. A cache read costs 0.1x on standard models, and only 0.05x on Opus 5.5 and Sonnet 5.5 (0.025x on Fable 5.1 and Mythos 5.1). Cache breakpoints themselves are free — you pay only for writes, reads, and ordinary uncached input. Concretely, on Opus 5.5 (base input $4 per million tokens) a 5-minute write is $5, a 1-hour write is $8, and a cache hit is $0.20 per million.

Want cache hit rates and dollars saved visible per request, across every model?

Book a demo

The break-even, in one line

Here is the whole cost case. Say a static prefix would cost 1 unit as normal input. Without caching, N requests that all include that prefix cost N units. With 5-minute caching, the first request writes it (1.25 units) and each of the next N-1 reads it (0.1 units each), for 1.25 + 0.1(N-1) units.

Set those equal and the lines cross before the second request finishes: the 0.25-unit write premium is repaid the first time you read the prefix, because that read saves 0.9 units. So the rule is simple — if a cached prefix is reused even once inside its TTL, caching wins, and the advantage widens fast with every additional hit. A long system prompt or RAG context hit hundreds of times an hour is where the 90% discount compounds into a real line-item reduction.

Where it does not pay: a prefix used exactly once, traffic so sparse that entries expire between requests (use the 1-hour TTL then), or a “prefix” that actually changes every call — which brings us to the mistakes.

Why teams pay the premium and never collect

The failure mode is always the same shape: you write the cache on every request and read it on none. It happens because the breakpoint is on a block that changes.

A cache hit requires a 100% identical prefix up to and including the block marked with cache_control — all text and images, byte for byte. Caching covers the prefix in a fixed order: tools, then system, then messages. A change at one level invalidates that level and everything after it: edit a tool definition and all three levels miss; change the system prompt and system plus messages miss; add or remove an image and the message cache misses. So if you put the breakpoint on the incoming user message — which is different every time — you generate a brand-new hash on every request, pay the 1.25x write each time, and never once get the 0.1x read.

The fix is to place the breakpoint on the last block that is stable across requests, and keep everything variable after it:

system=[
    {"type": "text", "text": STATIC_INSTRUCTIONS, "cache_control": {"type": "ephemeral"}},
]
messages=[{"role": "user", "content": f"[{timestamp}] {user_input}"}]  # varies, uncached

Other rules worth knowing: caching only engages above a token minimum (512 tokens for Opus 5.5, Sonnet 5.5, Haiku 5.5 and Fable 5.1; 1,024 or more for older models), shorter prompts are silently processed uncached, you get up to 4 breakpoints per request, and the lookback only searches 20 blocks back from each breakpoint. Verify it is actually working by reading the usage fields — total input is cache_read_input_tokens + cache_creation_input_tokens + input_tokens, and if the first two are 0 nothing cached.

Running it across providers, and seeing the savings

Caching on the Anthropic API is per-organization and Claude-specific. Most teams, though, do not run only Claude — and prompt caching exists on other providers too, with different mechanics. Routing Claude through the TrueFoundry AI Gateway gives you one place to apply and observe caching: the gateway’s own caching adds exact and semantic caching on top of provider caching, and every call is metered.

That metering is the point. Prompt caching is a bet that your prefix will be reused; the only way to know the bet is paying off is to watch the hit rate and the dollars saved. With that visible per model and per route, you can tune breakpoints and TTLs against real traffic instead of hoping.

Where teams get this wrong

They breakpoint on the variable block. A timestamp or the user message in the cached prefix means a write every call and a read never. Cache the stable prefix; keep the variable part last.

They forget the TTL. The 5-minute window refreshes free on every read, but sparse traffic lets it expire. If requests arrive more than 5 minutes apart but within an hour, use the 1-hour TTL ({"type": "ephemeral", "ttl": "1h"}) even at the 2x write.

They cache below the minimum. Under 512 tokens (on current models) nothing caches and no error is raised. Check the usage fields.

They assume it helps a single-shot call. One request, one use — you pay the 1.25x premium for nothing. Caching is for prefixes reused many times.

A worked example

A support assistant sends a 10,000-token system prompt (product docs plus instructions) with every ticket, on Opus 5.5. Uncached, those 10,000 tokens cost the full input rate on all 2,000 daily tickets. Cached, the first ticket of each 5-minute window writes the prefix at 1.25x and every ticket after reads it at 0.05x — a ~95% cut on the biggest token block in the request. The variable part (the ticket text) stays after the breakpoint and is billed normally. Nothing about the application changes except where the cache_control marker sits; the savings show up as a falling input-cost line in the gateway’s metrics.

Related reading

• Semantic caching
• Provider-agnostic prompt caching at the LLM gateway
• LLM cost optimization
• OpenRouter prompt caching: when it saves money and when it quietly costs more
• GPT-5.6’s new cache pricing has a break-even point

Conclusion

Prompt caching is not complicated, but it is unforgiving: the same feature that cuts your biggest token block by 90% will quietly add a 25% premium to every request if the breakpoint is in the wrong place. The two numbers — 1.25x to write, 0.1x (or 0.05x) to read — tell you exactly when it pays, and the answer is “almost always, if the prefix is reused and the breakpoint is stable.”

Set it up on the static prefix, keep the variable input last, pick the TTL to match your traffic gaps, and watch the hit rate so the bet is measured. Do that through a gateway and the savings are visible per request, across every model you run.

See your Claude cache hit rate and savings per request

Book a demo