Cost optimization
Prompt Caching Costs: When Does Caching Save Money?
A discounted cache-read price is only one part of the budget. What matters is whether enough input is reused before the cache expires to pay back the write or storage cost. Start with a repeated prefix, then compare the whole workload.
Count each input token once
Separate input into uncached tokens, cache writes, and cache reads. Those are billing categories, not three copies of the same input. Output has its own price and normally remains in the budget even when nearly all input is cached.
For a workload, cost is the sum of each token category multiplied by its unit price, plus any storage or other fees. A dashboard saying that 80% of requests hit the cache does not mean that 80% of input tokens used the cache-read rate: a request can reuse a small prefix and still send a large new document.
A repeated-prefix example you can reproduce
Imagine ten requests sharing an identical 100,000-token prefix. The first request creates the cache; the other nine reuse it while it is valid. The example isolates the prefix, so output and newly added input are zero. It uses Claude Sonnet 5.5 rates from our pricing table.
For the calculator, enter 100,000 input tokens, zero output tokens, ten requests, 90% cache reads, and 10% cache writes. Compare a five-minute write with a one-hour write. The percentages describe the aggregate input across this ten-request group, not ten independent cold starts.
| Workload | Prefix cost (USD) |
|---|---|
| No cache | $2.00 |
| One 5-minute write + 9 reads | $0.34 |
| One 1-hour write + 9 reads | $0.49 |
Find the break-even reuse count
Let P be the ordinary input price, W the write price, R the read price, and N the number of times the same prefix is sent. Without caching, the prefix costs N × P. With one write and subsequent reads, it costs W + (N − 1) × R, multiplied by the prefix size in millions.
Caching saves money when N × (P − R) > W − R. If P is greater than R, divide by P − R to find the required number of uses; equality only breaks even. This is a calculation for one cache lifetime. A later cold start begins a new write-and-reuse cycle.
For a realistic estimate, group requests by stable prefix and cache lifetime. A prefix sent once per day should not be modeled as thousands of continuous hits just because the monthly token total is large.
Use the provider's actual billing categories
Claude lists different cache-write durations and cache-read prices. DeepSeek separates cache-hit and cache-miss input and also has peak and off-peak rates. Gemini explicit caching adds a storage-time dimension; Argon uses implicit caching only. These structures need different assumptions.
Our cross-model calculator includes token reads and listed write rates. It excludes storage and does not invent a write price when a vendor does not list one. For Gemini explicit caching, add stored tokens in millions × storage hours × the storage rate separately.
Measure a small workload before scaling
Keep a sample of request-level token counts, the model identifier, the time of execution, and cache hits or writes. Compare a warm run with a cold run using the same useful output, then test what happens after a pause or a prefix change.
Treat the measured result as a workload property. A high cache-hit rate on short outputs may save a large share of the bill, while output-heavy generation may barely change. Reconcile the estimate with provider-reported costs before assigning a monthly budget.
- Measure token shares rather than request shares.
- Include cache rebuilds and the selected lifetime.
- Add storage and tool charges outside a token-only estimate.
- Keep an uncached baseline so that the saving is observable.
Common questions
- Is a longer cache lifetime always cheaper?
- No. It helps only if the additional reuse offsets its write or storage cost. Compare the same request schedule with each lifetime.
- Can Quota Monitor show every prompt-cache hit?
- Quota Monitor tracks supported provider-reported balances, costs, and limits. This calculator is a planning tool; it does not collect request traces or per-prompt cache events.