Prompt Caching Savings Calculator

Cacheable prefix, hit rate and three separate rates — ordinary, cache read and cache write — turned into a monthly saving and a break-even hit rate.

The prompt, split into the part that repeats and the part that does not

Requests per month

Cacheable prefix, tokensThe identical opening of every request: system prompt, tool schemas, the document you keep asking about.

Remaining input tokensThe part that changes per request. Never cached.

Cache hit rateShare of requests that find the prefix already cached.

Your three input rates

Ordinary input rateUS dollars per 1,000,000 tokens

$ / 1M

Cache read rateUS dollars per 1,000,000 tokens — what a hit costs.

$ / 1M

Cache write rateUS dollars per 1,000,000 tokens — what a miss costs. Set it equal to the ordinary rate if your provider charges no write premium.

$ / 1M

Saved per month on the cacheable prefix

$1,332

Caching starts paying for itself above a 21.7% hit rate. You are at 70.0%.

Cache hits per month: 70,000
Cache misses per month: 30,000
Prefix tokens billed per month: 800,000,000
Prefix cost with no caching: $2,400
— cache writes on misses: $900.00
— cache reads on hits: $168.00
Prefix cost with caching: $1,068
Saving: $1,332
Saving as a share of the prefix bill: 55.5%
Blended prefix rate: $1.34 / 1M
Break-even hit rate: 21.7%
Unchanged either way (rest of the input): $120.00

What this assumes: a miss writes the whole prefix at the write rate and a hit reads the whole prefix at the read rate. Real caches are prefix-matched, so a single edited character near the top of the prompt invalidates everything after it — the hit rate you enter has to reflect that, and it is the number people are most optimistic about. Cache entries expire; if your traffic is bursty enough that the entry has gone cold between requests, those are misses. The non-cacheable remainder and the output are billed identically with and without caching, so they are excluded from the saving and shown separately. Some providers charge no write premium at all — set the write rate equal to the ordinary input rate and the break-even drops to zero.

Prompt caching is usually presented as a discount, and it is not. It is a trade: you pay a premium the first time a prefix is seen in exchange for a large discount every time it is seen again. That makes it a break-even problem, and the break-even has a closed form. Caching pays when the blended rate — the write rate on misses, the read rate on hits — falls below what you would otherwise pay per input token, which happens above a hit rate of (write − input) ÷ (write − read). With a modest write premium that threshold is low, often well under a third, which is why caching is worth turning on for almost any repeated prefix. It is not why it is worth restructuring your prompt for.

The restructuring question is separate and more interesting. Caches match on prefixes, so the saving depends entirely on how much of your prompt is byte-identical from one request to the next, from the very first token. A system prompt that interpolates the current timestamp or the user's name at the top caches nothing at all, however static the following eight thousand tokens are. Moving the volatile parts to the end of the prompt is frequently the single highest-leverage change available, and it costs an afternoon.

What this does not model: the cost of a cache entry sitting unused, which is zero on per-token pricing but not on every provider; the quality effect of reordering a prompt, which is real and occasionally negative; and the interaction with batching, where an asynchronous window can push requests far enough apart that the entries expire. Measure your actual hit rate from usage logs rather than assuming it.

Prompt Caching Savings Calculator

The reasoning behind this

Related tools