Anthropic Prompt Caching: A Step-by-Step Audit of Your API Bill
Across the four Claude models we price, the published cache-read rate is a median of 90 percent below the standard input rate, recorded on August 10, 2026. That is the largest single discount available on a Claude bill, it needs no negotiation and no volume commitment, and a great many teams pay full price for input that Anthropic would have billed them a tenth for.
The reason is always the same. Caching applies to a stable prefix, so it only pays when the beginning of your prompt is byte-for-byte identical between calls. One moved character and the whole thing is billed as new input. This is an audit you can run in an afternoon, and it usually finds something.
What the discount is worth on your own prompt
Work it through on real rates. On August 10, 2026 we recorded Claude Sonnet 5 at $2.00 per million input tokens and $0.20 per million cached input tokens. Suppose an assistant with a 6,000 token fixed prefix, a system prompt plus tool definitions plus a policy document, and a 400 token user message on top, running 200,000 times a month.
Uncached, that is 1.28 billion input tokens at $2.00, which is $2,560 a month of input. With the 6,000 token prefix served from cache and only the 400 token message billed as new input, the same traffic is 1.2 billion cached tokens at $0.20 plus 80 million fresh tokens at $2.00, which is $400.00. The output bill is identical either way. You changed nothing about the model, the prompt or the quality of the answers, and the input line fell by 84%.
Those rates are what we observed on that date and both are on the Claude Sonnet 5 page with their history. The method is what matters; run it on today's numbers and your own prefix size.
The audit, step by step
One, find your prefix. Print a real request exactly as it goes over the wire, not as your framework describes it. Mark everything that would be identical on the next request: system prompt, tool and function schemas, few-shot examples, shared documents, style guides. That block is your cacheable prefix, and it is usually larger than people expect once tool definitions are counted.
Two, measure it against the variable part. Count the prefix tokens and the per-request tokens separately. If the prefix is the large majority of your input, caching is the highest-leverage change available to you and everything else on your optimization list can wait. If the prefix is a small fraction, caching is not your problem and you should be looking at output length or model tier instead. The token counter will size both halves from pasted text without uploading it.
Three, check what you are actually being charged. This is the step that gets skipped, and it is the only one that produces evidence. Anthropic's API returns the cache fields in the usage block of every response, separating input that was read from cache from input that created a cache entry and input billed at the standard rate. Log all three for a day. Your real hit rate is cached reads divided by total input tokens, and it is a measurement, not an estimate.
Four, price the gap. Open the advanced calculator, enter your input and output token counts, and move the caching slider from zero to the hit rate you just measured. The distance between those two totals is what your prefix instability is costing you every month.
Why your hit rate is lower than you think
Almost every disappointing hit rate comes from one of five causes, and all five are fixable in the prompt rather than the architecture.
A timestamp, request id or session id near the top of the system prompt invalidates everything after it on every single call. So does a personalization line, the user's name or plan or locale, placed before the shared instructions instead of after them. Tool schemas serialized from a dictionary or a set can reorder between processes, producing a prefix that differs byte-for-byte while looking identical to you. Cache entries expire, so low-traffic hours and staggered deployments miss what busy hours hit. And any A/B test or prompt experiment that varies the early part of the prompt splits your traffic across two prefixes, halving the reuse of both.
The fix in every case is the same discipline: everything stable first, everything variable last, and nothing in between. Order your prompt so a reader could draw a line across it and say that everything above the line is the same on every request. Then check the byte equality rather than trusting it.
What to check before you count the saving
Two things sit outside what our archive records, so verify both on Anthropic's own pricing page before you put a number in a budget.
Writing to the cache is not free. We capture standard input, standard output and the cache-read rate, and we do not capture the cache-write rate, so we do not publish one. Anthropic charges a premium for the request that creates a cache entry, which means a prefix has to be read back enough times to repay the write. For a busy endpoint that break-even arrives almost immediately. For a prompt used a handful of times a day it may never arrive at all, and caching it can cost more than it saves.
Cache lifetime also decides your realistic ceiling. Entries do not live forever, and the traffic pattern that keeps a prefix warm on a busy service will not keep it warm overnight. Model your hit rate on your quietest hour rather than your busiest, and the figure you take to a budget meeting will survive contact with the invoice.
The same idea beyond Claude
Caching is not an Anthropic feature, though Anthropic documents it more explicitly than most. Of the 42 models we price, 28 publish a cache-read rate and 14 do not, and among those that do the median discount is 90 percent off standard input. If you are choosing a model for a prefix-heavy system, that published rate belongs in the comparison alongside the headline input price, because for this kind of workload it is the price you will actually pay. The rates page lists all three rates per model.