# What is prompt cache hit rate? > Prompt cache hit rate is the share of input tokens billed at the cached rate. Why a low rate wastes money and a high write rate can cost more. URL: https://getculpa.com/what-is-prompt-cache-hit-rate Last reviewed: 2026-08-01 ## Answer 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. ## Common mistakes - Putting variable content before the stable block in the prompt. Why it hurts: Caching matches on prefixes, so anything variable at the front makes every subsequent token uncacheable. Do instead: Order the prompt stable first, variable last. That single reordering is usually the whole fix. - Ignoring what a cache write costs. Why it hurts: 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. Do instead: 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. Why it hurts: Every edit invalidates the cached prefix for all traffic at once, so savings reset on each deploy. Do instead: Freeze the cached block and put anything you tune often after it, where a change costs nothing. ## Self-check - 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. No cache, per call: 4 x $0.001 = $0.004 for the system prompt Cache write, once: 4 x $0.00125 = $0.005, which is more than a single uncached call Cache read, per call: 4 x $0.0001 = $0.0004, a saving of $0.0036 against no cache The write replaces an uncached call, so its EXTRA cost is only $0.005 - $0.004 = $0.001 Each later read saves $0.0036, so break-even = $0.001 / $0.0036 = 0.28 reads Rebuild the cache every call and you pay $0.005 instead of $0.004, which is 25% worse than not caching 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. ## Cost figures Every figure carries its confidence and its source. No figure on this site is provider-reported. - 1 read — break-even point before a five-minute cache write pays for itself on Claude Haiku 4.5 [calculated] Source: 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] Source: ($0.005 - $0.004) / $0.004, from the per-call arithmetic shown in the teardown. ## FAQ Q: What's a good prompt cache hit rate? A: 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. Q: Why did my bill go up after enabling prompt caching? A: 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. Q: Do all providers charge for cache writes? A: 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. ## Sources - Anthropic pricing: https://platform.claude.com/docs/en/docs/about-claude/pricing Run the free Cost Leak Scan: https://app.getculpa.com/scan?source=pseo&slug=what-is-prompt-cache-hit-rate&cluster=metric Machine-readable index of every guide: https://getculpa.com/api/pages Human-readable index of every guide: https://getculpa.com/guides Site overview: https://app.getculpa.com/llms.txt Privacy: 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.