Caching is not free, and on a platform that charges a write premium there is a hit rate below which it actively costs you money. On Claude Sonnet 5 with Anthropic's 5-minute cache write, that threshold is 21.7%. Below it, you are paying more than you would have paid with no cache at all. Here is where the number comes from, in words, because once you can derive it you can sanity-check any vendor's caching claim in about fifteen seconds.
Claude Sonnet 5 charges $2.00 per million input tokens, $10.00 per million output, and $0.20 per million for input served from cache. Take the calculator's default workload: a 12,000-token cacheable prefix, 400 variable tokens, 500 output tokens, 200,000 requests a month.
When you hit the cache, the 12,000-token prefix costs $0.20 per million rather than $2.00. The saving is 12,000 × ($2.00 − $0.20) ÷ 1,000,000 = $0.0216 per request.
When you miss, the prefix is charged at $2.00 per million plus a 25% write premium, because the platform is not merely processing those tokens, it is serialising and storing the model's internal state for them. The penalty is 25% of 12,000 × $2.00 ÷ 1,000,000 = 25% of $0.024 = $0.006 per request.
Caching breaks even when the expected saving on hits equals the expected penalty on misses: h × $0.0216 = (1 − h) × $0.006. Rearranged, h = 0.006 ÷ (0.006 + 0.0216) = 0.006 ÷ 0.0276 = 0.217.
Now the useful part. Notice that the prefix length, 12,000, appears in both sides of that equation and cancels. The break-even hit rate depends only on the write premium and the size of the cached discount, not on how much text you are caching. For any model, break-even = premium ÷ (premium + discount), where both are expressed as fractions of the standard input price. Sonnet 5's cached rate is 90% off, and the premium is 25%, so break-even is 0.25 ÷ (0.25 + 0.90) = 21.7%. Claude Haiku 4.5, at $0.10 cached against $1.00 standard, has the identical 90% discount and therefore the identical 21.7% threshold. On a platform with no write premium at all — OpenAI applies none to GPT-5.6 Terra's $0.20 cached rate against $2.00 standard — the premium is zero, break-even is zero, and caching is unconditionally worth enabling.
What the savings actually look like
At the default 80% hit rate, the arithmetic runs as follows. Uncached, each request costs 12,400 ÷ 1,000,000 × $2.00 + 500 ÷ 1,000,000 × $10.00 = $0.0298, so 200,000 requests cost $5,960. With caching, the 160,000 hits cost $0.0024 + $0.0008 + $0.005 = $0.0082 each, or $1,312 total; the 40,000 misses cost $0.03 + $0.0008 + $0.005 = $0.0358 each, or $1,432. Total $2,744 — a saving of $3,216 a month, 54% off.
At 0% hit rate the same workload costs 200,000 × $0.0358 = $7,160, which is $1,200 more than not caching. That is not a hypothetical. It is what a nightly batch job with a cached prefix looks like when every request arrives long after the previous one expired.
Hit rate is a property of your architecture, not your luck
Two things determine it, and both are under your control.
Prompt ordering. Caches match on an exact prefix, byte for byte, from position zero. Everything up to the first difference is reusable; everything after it is not. So the fixed material — system prompt, tool schemas, few-shot examples, pinned reference documents — must come first, in a stable order, and the variable material must come last. Get the order wrong and the cache does not fail loudly; it simply never matches, and your bill quietly includes the write premium on every request forever.
Traffic density. Cache entries live for minutes, typically five on the shortest tier. Whether request n+1 finds the entry left by request n is a question about your arrival rate. A support tool taking 40 requests a minute against a shared prefix will sit above 95% all day. A workflow firing 200 requests spread evenly across an eight-hour overnight window — one every 2.4 minutes — will hit sometimes and miss often, landing somewhere near the break-even line. A tool used twice a day will never hit. Before enabling caching, look at a histogram of inter-request gaps for the requests sharing a prefix, not at your daily total.
Four ways to destroy a hit rate without noticing
-
A timestamp in the system prompt. "Current date and time: 2026-08-15 14:32:07" at the top of an otherwise fixed 12,000-token preamble means every request has a unique prefix. Hit rate: zero. Write premium: paid every time. If the model genuinely needs today's date, put it in the user message, or truncate it to the day so it changes once every 24 hours instead of once a second.
-
Reordered tool definitions. Serialising a tool registry from a hash map, dictionary or set gives you an order that is stable within a process and different after a restart, or different between replicas. Half your fleet caches one prefix and half caches another, and a deploy invalidates everything. Sort tools by name before serialising, and pin the JSON key order.
-
Per-user personalisation at the top. "You are assisting Priya Raman, on the Enterprise plan, in Amsterdam" placed above the shared instructions turns one shared cache entry into one entry per user. Each user must now generate enough traffic on their own to keep their own entry warm, which almost none of them will. Move personalisation below the shared block. The instructions do not care where the user's name appears.
-
A prefix below the vendor's minimum. Platforms only cache blocks above a floor — commonly around 1,024 tokens. A 600-token system prompt is not cacheable at all, and no amount of correct ordering changes that. Either pad it with genuinely useful material or accept that caching is not your lever here.
One structural warning the calculator cannot flag: A/B testing two system prompt variants halves the density of each. Two variants at 20 requests a minute each behave very differently from one at 40, and if you are near the break-even line the experiment itself can be what pushes you under it.
For a chat product, caching stacks with history containment rather than replacing it — the AI chatbot cost calculator shows the two working together on the same conversation. Prompt caching explained covers the mechanics of what is actually stored, and the LLM API cost calculator prices a blended cached rate across every model in the index at once.
Prices used by this calculator were last verified on 15 August 2026 from the vendors' own pricing pages. See the full price index for every figure and its source, the change log for what has moved recently, and the methodology for how the index is maintained and where its limits are.