Cost guide

Prompt cache savings calculator for AI apps

Last updated July 19, 2026 · ByteCosts

Prompt caching saves money when a large, stable prefix - your system prompt, tool definitions, or a reused document context - is sent on most requests. Providers price a cached prefix in tiers relative to the base input rate: reading it back is roughly a tenth of the input price, while writing it to cache costs a premium (about 1.25× for a short TTL, 2× for a long one). The savings come from paying the cheap read rate on cache hits instead of the full input rate every time. Caching only pays off above a break-even reuse count: if a prefix is written once and rarely re-read, the write premium can cost more than it saves. Your real savings depend on prefix size, cache hit rate, and write tier - model them on your traffic before assuming a number.

Open the calculator - Model this on your own token mix, volume, and seats →

Formula

monthlyCost = workloadVolume * unitCost, adjusted for the specific driver this use case models: token mix, seats, plan allowance, cache hit rate, traffic split, or runtime cost.

For prompt cache savings calculator, ByteCosts keeps each driver visible so you can change the workload instead of accepting a generic vendor example.

Example scenario

Start with the live prompt cache savings calculator, enter your real workload volume, then run the same assumptions through a normal, heavy, and constrained-budget scenario.

Assumptions used

These explainer pages do not invent a default price when the workload needs user-specific inputs. The live calculator asks for the missing variables.

Prompt cache savings calculator uses source-backed model, plan, or pricing rows where the data exists.
User-specific volume, token mix, traffic split, plan price, or cache hit rate must be entered by the user.
Unknown data remains unknown/null and should not be converted into a fake benchmark.
Production invoices can differ because of taxes, negotiated discounts, rate limits, retries, and provider billing rules.

Interpretation guide

Compare models or plans with the same workload assumptions.
Stress-test output-heavy, retry-heavy, and power-user scenarios before committing to a price.
Use the estimate to decide what to measure in production logs.
Verify provider source links before production billing decisions.

How Prompt cache savings works

ByteCosts models caching the way providers actually bill it: the cacheable prefix (system prompt + reused context) is read at the cache-read rate on a hit and re-written at the cache-write rate on a miss, while fresh input (the new user turn) and output are billed at list rates. The cache-read rate uses the model's real published price where the dataset has one, and falls back to a 0.1× estimate otherwise.

The decision is governed by a break-even reuse count: how many times a cached prefix must be read before the write premium pays off. Below that reuse, caching loses; above it, savings scale with prefix size and hit rate. A big shared prefix that's hit on nearly every request is where caching wins hardest; a tiny or rarely-reused prefix often isn't worth the write cost.

Because the read rate, write tier, hit rate, and prefix size all interact, there is no single 'caching saves X%' number - it's specific to your workload. The calculator computes the with-cache and without-cache monthly cost side by side so you can see the real delta and break-even point for your model and traffic.

How to cut this cost

The levers that move this workload's bill the most:

Maximize the cacheable prefix: put the system prompt, tool schemas, and any reused document context up front so the largest possible span is cacheable.
Raise the cache hit rate: route a user's turns to a warm cache and keep the prefix byte-identical so it actually matches.
Pick the right write tier: a longer TTL costs more to write but survives between requests - only worth it when reuse clears the break-even count.
Don't cache tiny prefixes: below the break-even reuse, the write premium costs more than the read savings.
Re-check after model changes: a model with no published cache-read price uses an estimate, so verify against your invoice.

Limitations before production billing decisions

Treat ByteCosts calculations as planning estimates, not final billing totals. Real invoices can differ because token mix, retry rate, cache hit rate, rate limits, taxes, gateway fees, regional pricing, and negotiated discounts change the effective cost.

Verify the provider source before production billing decisions, then compare the estimate with your own logs or invoice once production traffic is live.

Calculator context

These figures use ByteCosts' default assumptions. Your token mix, call volume, seats, and quality bar are different - and they move the bill more than any headline price. Open the live prompt cache savings calculator to plug in your own numbers and get a monthly cost you can budget against.

The calculator computes against the same committed, source-backed pricing index behind this page, so the number you get is the number you can defend.

Frequently asked questions

How much does prompt caching actually save?

It depends on prefix size, cache hit rate, and write tier. Reads cost roughly 0.1× the input rate and writes cost a premium, so savings are large for a big prefix hit on most requests and can be negative for a tiny or rarely-reused prefix. The calculator shows the real with-cache vs without-cache monthly cost for your model and traffic.

When does prompt caching stop being worth it?

Below the break-even reuse count - the number of reads needed before the write premium pays off. If a cached prefix is written once and rarely re-read, the write cost can exceed the read savings. Long-TTL writes cost more, so they need more reuse to pay off.

Prompt cache savings calculator. ByteCosts. Updated July 19, 2026. https://bytecosts.com/use-cases/prompt-cache-savings-calculator/