Prompt-caching savings calculator

Two numbers decide whether caching helps you at all

A cache read prices at a steep discount against standard input; a cache write costs more than a standard read, and costs more again at the longer of the two available TTLs than at the shorter one. Put those together and caching a prefix is not automatically a win — it is a bet that you'll re-read that prefix enough times, inside the TTL window, to earn back what the write cost. Below that frequency, turning caching on quietly makes a request pattern more expensive, not less, and nothing in a normal API response flags that for you.

The break-even, worked through

At the shorter TTL, a cached prefix needs to be read a small number of times within that window before the arrangement beats paying standard input price on every request; at the longer TTL, it needs a few more, because the write itself costs more up front. A request pattern that reuses a prefix in quick, dense bursts tends to favour the shorter window; one where the same prefix gets reused sporadically over a longer stretch, but reliably within an hour, tends to favour the longer one — and a pattern that reuses a prefix only once, however large that prefix is, never benefits from caching it at all.

What you enter, and what comes back

Give this tool your prefix size, how often a request reuses it, and the typical gap between bursts of reuse, and it tells you which TTL wins for that specific pattern and what the difference is worth over a month at your volume — not a generic "caching saves money" answer, but a number tied to your own request shape. It also flags the case where your prefix sits below the minimum length a given model requires before anything can be cached at all, which is the single most common reason a team turns caching on and sees no effect in their bill.

The trap this catches

Where this calculator's flag actually saves you time is a multi-model setup — a fallback chain, a cost-driven downgrade, an A/B test across models — where a prefix sized for one model's floor quietly stops qualifying the moment a different model in that same set handles the request. See why your prompt caches on one model and not another for the full mechanics of why that happens and how to build a routing setup that doesn't depend on guessing which model ends up serving a given request, and the minimum-cacheable-prefix table for the current floor by model.

Where it sits relative to the other calculators

This tool isolates the caching decision on its own. If you want caching folded into a full subscription-versus-API comparison for your whole workload, the subscription vs API cost calculator already applies this same logic as one of its two levers, alongside batch pricing.