Research-backed calculator guide
Cross-Provider Prompt Cache Break-Even Calculator: Hit Rate, TTL and Traffic Shape
Calculate when prompt caching pays across providers by separating cache writes, reads, TTL expiry, stable-prefix size, and request traffic shape.
Prompt caching is not automatically a saving. It is a pricing decision whose result depends on four variables: the cost of creating a cached prefix, the cost of reading it, how long the entry remains usable, and how many requests share that prefix before it expires. A cross-provider prompt cache break-even calculator should expose all four rather than display one headline discount.
Quick answer
Caching pays when the expected cost of cached prefix tokens is below the same prefix sent as ordinary input. For one TTL window, let N be requests, M cache writes or misses, H cache reads or hits, P cached-prefix tokens, r ordinary input price, w cache-write price, and c cache-read price. Ignore the changing suffix for the break-even test because it is billed the same in both cases.
The cached-prefix comparison is:
uncached cost = N × P × r
cached cost = M × P × w + H × P × c, where N = M + H
Caching is cheaper when:
M × (w − r) > H × (r − c)
This gives two useful thresholds:
- Minimum hit rate:
H / N > (w − r) / (w − c). - Minimum reads per write:
H / M > (w − r) / (r − c).
The first is best for dashboards. The second is useful for a cache window because it answers how much reuse each miss must generate. If a provider has no write premium, w = r, the threshold is zero before storage, setup, or operational costs. If the provider charges storage or a longer-TTL premium, add those costs before deciding.
Provider rules are not interchangeable. OpenAI documents model-dependent cache thresholds and, for GPT-5.6 and later in the Responses API, a 30-minute default write rate of 1.25 times ordinary input and a 12-hour option at 2.5 times, while reads are typically 0.1 times ordinary input for those models. Its usage response exposes cached and cache-write token counts, which makes a realized-cost check possible. [1] Anthropic publishes separate 5-minute and 1-hour cache-write prices and cache-hit prices by model, and reports creation and read token fields separately. [2] Gemini's current API documentation describes implicit caching, model-specific minimum token counts, and a total_cached_tokens usage field; the API surface and model must be checked before importing an explicit-cache formula from another provider. [3]
What the current result set covers
The exact query was checked on 2026-11-02 using a web search method in English, United States localization. The visible results are mainly calculator pages, provider-specific explainers, and engineering posts. Their recurring pattern is a fixed formula for a cache write premium versus a discounted read, followed by a single example for one model or one TTL. That format answers “does caching save money in this example?” well.
The specific opportunity is a calculator that keeps the provider inputs separate from the traffic model. A 90% cached-read discount does not mean a 90% bill reduction when only 20% of total input tokens are stable. Conversely, a modest discount can matter when a very large document is reused frequently. Expiry and cold starts also turn a daily request count into a different number of writes. This page therefore models the sequence of misses and hits instead of treating a monthly hit-rate percentage as sufficient evidence.
Inputs a cross-provider calculator should expose
Start with the stable prefix, not total prompt tokens. P includes the system instructions, tool definitions, examples, or reference document that are byte-identical up to the provider's cache boundary. F is the changing input per request. Output tokens are separate because prompt caching does not make generated output free.
Then enter ordinary input price r, cache-write price w, and cache-read price c in the provider's published units. Most vendor tables use dollars per million tokens, but some products add a storage rate per cached token-hour or use a different unit. Keep the unit in the calculation and label it on the result.
Finally describe traffic. Use requests per TTL window when you have a stable workload. If traffic is irregular, use an arrival schedule or a distribution of inter-request gaps. A monthly average can be misleading: 300 requests arriving in three five-minute bursts have a different write count from 300 requests spread across a day.
For a full monthly estimate, use:
uncached monthly = Q × (P + F) × r + Q × O × o
cached monthly = M × P × w + H × P × c + Q × F × r + Q × O × o + storage
Here Q is total requests, O is output tokens per request, o is output price, and M + H = Q. For explicit caches, storage can be a token-hour charge. For implicit caches, it may be absent or embedded in the provider's pricing. Do not add a storage fee unless the selected provider and model actually quote one.
Worked example
Formula check with a provider-neutral example
Suppose a workload has a 1,000,000-token stable prefix, 200 changing tokens, 300 output tokens, and a base input rate of $3.00 per million tokens. For an illustrative cache tier, use a $3.75 write rate and a $0.30 read rate. These are example rates, not a universal cross-provider quote; replace them with the selected model's current price before making a purchasing decision.
The write premium is $3.75 − $3.00 = $0.75 per million cached tokens. Each hit saves $3.00 − $0.30 = $2.70 against ordinary processing. The minimum hit rate is therefore 0.75 / (3.75 − 0.30) = 21.74%. The minimum reads per write is 0.75 / 2.70 = 0.2778, or roughly one hit for every four misses. These are equivalent views of the same break-even point; the reads-per-write figure is not the same as recovering the entire write invoice from zero.
| Step | Assumption or input | Calculation | Output for this example |
|---|---|---|---|
| 1. Stable prefix | P = 1,000,000 tokens | Prefix × base rate | $3.00 uncached per request |
| 2. Cache miss/write | w = $3.75/M | Prefix × write rate | $3.75 per miss |
| 3. Cache hit/read | c = $0.30/M | Prefix × read rate | $0.30 per hit |
| 4. Miss penalty | w − r | $3.75 − $3.00 | $0.75 per write above baseline |
| 5. Hit saving | r − c | $3.00 − $0.30 | $2.70 per read versus baseline |
| 6. Break-even hit rate | (w − r) / (w − c) | $0.75 / $3.45 | 21.74% of requests |
| 7. Ten-request window | M = 7, H = 3 | 7×$3.75 + 3×$0.30 | $27.15 cached prefix cost vs $30.00 uncached |
| 8. Low-reuse window | M = 9, H = 1 | 9×$3.75 + 1×$0.30 | $34.05 cached prefix cost: $4.05 worse |
The 200 changing tokens and 300 output tokens are still billed on every request. At a base input rate of $3.00/M and an illustrative output rate of $15.00/M, they add $0.0006 + $0.0045 = $0.0051 per request in either scenario. They do not alter the prefix break-even, but they do dilute the percentage saving on the total bill. This is why a cache can be economically positive for the prefix yet look small on an all-in invoice.
TTL and traffic shape change the answer
A TTL is not just a label. It determines how many times the same prefix becomes cold. If the first request after expiry is a write, every additional cold start adds the write premium again. A 5-minute tier can work well for a steady stream and poorly for a tool used once every ten minutes. A longer tier can reduce cold starts, but its write or storage price may be higher.
For regular traffic, calculate requests per TTL window and then estimate misses. For bursty traffic, group requests by the actual prefix key and simulate whether the next request arrives before expiry. Do not use the application's global hit rate if each customer, document, or experiment variant has its own cache key. A shared 80% hit rate can hide many individual prefixes that never receive enough reads.
Also inspect prefix ordering. Put stable content before volatile content. A timestamp, request ID, user-specific instruction, or changing tool serialization near the beginning can prevent the later stable material from matching. OpenAI describes longest matching eligible prefixes and exposes cached and write tokens for monitoring. [1] Anthropic's cache boundary covers the prompt prefix through the designated cache-control block, and its response usage reports cache creation and read tokens. [2] Gemini recommends common content at the beginning and short intervals between similar requests, and reports the number of cached tokens. [3]
For operations, record at least prefix identity, prefix token count, request timestamp, provider and model, TTL tier, cache-write tokens, cache-read tokens, ordinary input tokens, and billed price version. Then reconcile the modeled M and H to vendor usage. A monthly aggregate is useful for finance, but a per-prefix inter-arrival histogram explains why the result moved.
Provider comparison without false equivalence
OpenAI, Anthropic, and Google all expose caching concepts, but their controls differ. OpenAI's documented modes and lifetime options vary by model; do not assume every model has the same minimum or write multiplier. [1] Anthropic's 5-minute and 1-hour write prices are model-specific, and a longer cache may be justified by cadence or latency needs rather than by token price alone. [2] Gemini's implicit caching is enabled by default on documented model families, while explicit caching is API- and model-dependent; its minimum input threshold also varies. [3]
A useful cross-provider comparison normalizes three outputs: cost per million cached-prefix tokens, cold-start cost per TTL window, and all-in monthly cost after adding uncached suffix and output. It should retain the provider's own units and date each price observation. The comparison is an estimate when it uses list prices and an assumption when it uses a forecast hit rate. It is not a vendor quote, a guaranteed saving, or a promise that one provider is cheapest for every model.
Use the LLM cost calculator for the wider model-and-token bill, then use the AI token cost calculator to separate cached, ordinary, and output tokens. After deployment, the AI API invoice reconciliation calculator can compare modeled token classes with invoice or usage-export rows.
Run your scenario
Turn this framework into an editable estimate.
Use dated, source-linked assumptions and see cost per request, successful task and month.
Common mistakes and limitations
Do not call every repeated prompt a cache hit. The prefix may be below a provider minimum, may differ by one token, or may have expired. Do not multiply a published discount by total prompt tokens when only a prefix is eligible. Do not use a hit rate from one model to forecast another model with different cache boundaries or TTL behavior.
This method excludes quality changes, latency value, implementation labor, privacy controls, minimum commitments, taxes, negotiated discounts, retries, failed requests, and provider-specific storage unless you add them as explicit rows. It also assumes that ordinary input, write, and read prices are stable for the period. Because provider pricing and model availability change, record the checked date and re-run the model after a pricing or API change.
FAQ
What is the simplest prompt cache break-even formula?
For a fixed prefix, compare the write premium with the savings from reads: hit rate > (write price − ordinary input price) / (write price − cache-read price). This formula assumes each miss creates one write and each hit receives the published read price. Add storage or other fixed costs separately.
Does a larger prompt change the break-even percentage?
Not by itself. Prefix size multiplies both the miss penalty and the hit saving, so it cancels in the percentage threshold. It changes the dollars at stake. A 100,000-token prefix can justify instrumentation that would not be worthwhile for a 1,000-token prefix, even if both have the same break-even rate.
How should I model a 5-minute versus 1-hour cache?
Use a separate write rate and a separate cold-start count for each TTL. Estimate how many requests sharing the same prefix arrive inside each window. A longer TTL can reduce writes, but it may cost more to create or retain. Choose the tier with the lower all-in cost after the observed arrival pattern, not the tier with the larger advertised discount.
Why can a high monthly hit rate still lose money?
The average may combine many busy prefixes with many cold prefixes. A prefix that receives one request per hour can pay a write premium repeatedly even when another shared prefix has excellent reuse. Segment hits and writes by cache key, model, tenant, and TTL before using a single monthly percentage.
Do changing user messages and output tokens get cached?
Usually, only the eligible prompt prefix receives the cache treatment. Changing input and generated output remain separate billable components. The provider's usage response is the authority for what was actually read, written, or billed. OpenAI, Anthropic, and Gemini document different field names and behaviors, so map the API response before importing it into a ledger. [1] [2] [3]
Should I enable caching when the provider has no write premium?
A zero write premium makes the token-only break-even threshold zero, but it does not make every caching design free. Check minimum token thresholds, cache-key fragmentation, retention, privacy requirements, latency, and any storage or request-level fees. The decision is favorable on the cached-token line only after those other costs are either zero or included.
Primary sources checked
Pricing and product behavior can change. These sources support the time-sensitive claims in this guide; verify current provider terms before committing spend.