Guides / prompt cache hit rate
What is prompt cache hit rate?
Prompt cache hit rate is the share of your input tokens that billed at the cached rate rather than the standard one. On some providers a cache write bills above the input rate, so a badly tuned cache costs more than none. Culpa, a local-first LLM cost, margin, and forecast ledger, meters cached, uncached, and cache-write tokens separately per call.
Why this happens
Caching gets treated as a switch you turn on, and it isn't. Three things decide whether it saves money. Whether the repeated block sits at the front of the prompt, because caching works on prefixes. Whether it stays stable long enough to be reused before it expires. And whether your provider charges to write the cache. Anthropic models bill cache creation above the standard input rate, so a cache rebuilt more often than it's read is a net loss.
What this usually looks like
- You switched caching on and the bill didn't move, which usually means the repeated block isn't at the prompt's start.
- Your cached-token share sits near zero despite an identical system prompt on every call.
- Spend rose slightly after enabling caching, the signature of writes outnumbering reads.
- Cache hits collapse whenever you deploy, because a changed system prompt invalidates every prefix at once.
Free, no card, no account
Run the free Cost Leak Scan
It shows your most expensive conversation before you install anything.
Mistakes that cost the most
| Mistake | Why it hurts | Do instead |
|---|---|---|
| Putting variable content before the stable block in the prompt. | Caching matches on prefixes, so anything variable at the front makes every subsequent token uncacheable. | Order the prompt stable first, variable last. That single reordering is usually the whole fix. |
| Ignoring what a cache write costs. | On Anthropic models a five-minute cache write bills at 1.25 times input and a one-hour write at 2 times, so churn is expensive. | Compare writes against reads. If you write more often than you read, the cache is losing you money. |
| Editing the system prompt frequently while relying on caching. | Every edit invalidates the cached prefix for all traffic at once, so savings reset on each deploy. | Freeze the cached block and put anything you tune often after it, where a change costs nothing. |
Run this check tonight
- Compute cached input tokens divided by total input tokens. That percentage is your hit rate.
- Check whether your prompt's first tokens are identical on every call. If not, that's why the rate is low.
- Count cache writes against cache reads for the same period. More writes than reads means the cache is a cost, not a saving.
- Look at your hit rate immediately after a deploy and a day later. A permanent drop means the cached block is being edited.
- Price one call both ways using your provider's cached and standard rates, so you know what a hit is actually worth.
When a cache write costs more than the saving
A 4,000-token system prompt on Claude Haiku 4.5. Real rates from the price book: $0.001 per 1k input, $0.0001 per 1k cached read, and a five-minute cache write derived at 1.25 times input, so $0.00125 per 1k.
One read per write and caching already wins. Rebuild on every call with no read at all and it loses by 25%. The hit rate alone doesn't tell you which side you're on, the write-to-read ratio does.
Every number, with its confidence and source
| Figure | What it means | Confidence | Source |
|---|---|---|---|
| 1 read | break-even point before a five-minute cache write pays for itself on Claude Haiku 4.5 | calculated | Incremental write cost $0.001 divided by the $0.0036 per-read saving = 0.28, so the first read clears it. Claude Haiku 4.5 rates from the price book (effective 2026-07-02) with the published 1.25x write multiplier. Matches Anthropic's own statement that a five-minute cache pays off after one read. |
| 25% | cost penalty of rebuilding the cache on every call versus not caching at all | calculated | ($0.005 - $0.004) / $0.004, from the per-call arithmetic shown in the teardown. |
What a generic answer can’t know
A provider reports cached tokens on a response, but it can't tell you why your hit rate is low, because the reason lives in how your application assembles prompts. Diagnosing it means comparing prompt structure across calls, which means request-level data. Culpa keeps that on your infrastructure, where your prompts and responses stay, and counts the calls to run your plan.
Questions founders ask next
What's a good prompt cache hit rate?
It depends entirely on how much of your prompt actually repeats. A better question is whether your reads exceed your writes, because that ratio decides whether caching is saving or costing you money regardless of the headline rate.
Why did my bill go up after enabling prompt caching?
Almost certainly writes outnumbering reads. On Anthropic models a cache write bills above the standard input rate, so if the cached block changes or expires before it's reused you pay a premium on every call.
Do all providers charge for cache writes?
No. In this price book only Anthropic models carry a cache-write rate, derived at 1.25 times input for the five-minute window and 2 times for the one-hour window. Others record a cached read rate with no separate write charge.
On your infrastructure
Culpa runs on your infrastructure. Your prompts and responses never leave it. Culpa counts calls to run your plan, and it fails open, so if it ever breaks your app keeps running.
Free, no card, no account
Run the free Cost Leak Scan
It shows your most expensive conversation before you install anything.
Keep reading
Sources: Anthropic pricing. Last reviewed 2026-08-01. Plain text version.