Prompt caching calculator for Claude, GPT and Gemini

Prompt caching bills the repeated start of a prompt, the prefix, at a reduced price when it was seen recently. Most calculators assume a hit rate and stop there. This one works out the hit rate from your traffic and the cache lifetime, then applies each provider’s write and read prices from our daily price data (209 models; 74 from Anthropic, OpenAI and Google, whose caching rules we checked on 2026-10-11).

The cost formula

With N requests a day, a prefix of P tokens, Q new input tokens and O output tokens per request:

without = N × (P + Q) × input + N × O × output
with = writes × P × write + reads × P × cached + N × Q × input + N × O × output

Prices are per million tokens. A miss writes the prefix: on Anthropic at 1.25× input for the 5-minute cache or 2× for the 1-hour cache; on OpenAI GPT-5.6 and later at 1.25×; on earlier OpenAI models and Gemini’s implicit cache at the normal input price. Monthly figures use 365 ÷ 12 days. Long-context price tiers apply to the whole request, and the cached and write prices scale with them, as Anthropic’s Haiku 5.5 price table shows.

How the hit rate is estimated

Every request, hit or miss, leaves the prefix in the cache for another T minutes (the lifetime), because Anthropic and OpenAI refresh an entry each time it’s used (for Gemini and other providers, we assume the same). So a request finds the cache warm when the previous request arrived less than T minutes earlier. If requests arrive at random at λ per minute (requests per day ÷ active minutes), the gap between them is exponentially distributed and the chance it is shorter than T is 1 − e^(−λT). The first request of each day always writes, unless the overnight gap is shorter than the lifetime. For example, one request every 10 minutes against a 5-minute cache gives λT = 0.5 and a hit rate of only 39%. Our unit tests check the formula against a simulation of 200,000 random requests.

Where the estimate can be wrong

• Bursty or regular traffic. Clustered requests hit more often than random ones with the same daily total; evenly spaced requests are all-or-nothing (every gap under T hits, every gap over T misses).
• Concurrency. Anthropic notes that an entry only becomes available after the first response begins, so requests fired in parallel before then each write.
• Provider-side behaviour. OpenAI says that on models before GPT-5.6, traffic above about 15 requests a minute can be routed to machines without your cache, and that nothing guarantees a hit. Google says Gemini’s implicit caching has no cost-saving guarantee and doesn’t publish its lifetime, so the lifetime for Gemini is an assumption you choose.
• Only the fixed prefix is counted. In a chat, the growing history can be cached too; for that, measure your cached share and enter it in the LLM cost calculator.

If you have measured your hit rate from the API’s cached-token fields, set it by hand and the traffic model is skipped. Not included: Gemini’s explicit caches (billed for storage per token-hour), batch discounts, regional price multipliers and rate-limit effects.

Break-even

If a write costs W times the input price and a read R times, a write pays for itself after more than (W − 1) ÷ (1 − R) reads, and caching saves money once the hit rate passes (W − 1) ÷ (W − R). With no write premium (W = 1), any hit is a saving. The prompt caching guide explains these rules in more depth, and the token counter tells you how long your prefix is.