Prompt-Caching Savings Calculator

Caching either pays for itself or it doesn't, and which side of that line a given prefix lands on depends on exactly one thing: how many times it actually gets read back after you write it. This calculator computes that break-even directly from the published rates, for the model you're actually using, instead of leaving "is caching worth it here" as a guess.

The arithmetic underneath it

A cache write costs a real premium over the plain input rate on any model that charges for writes at all — every model before the GPT-5.6 family writes for free, and GPT-5.6 and later charge a markup. Every subsequent read against that same prefix bills at a steep discount off the plain rate. The break-even is just the ratio of those two numbers: how much extra the write cost, divided by how much each read saves. This calculator derives that ratio live from the facts module rather than hardcoding it, specifically because the underlying rates are model-specific and a hardcoded number would be quietly wrong the moment either rate changed.

Why this varies more than people expect

A prefix that gets read back many times over a session — a long system prompt reused across dozens of turns, a large tool-definition block sent on every call in a conversation — clears its break-even almost immediately, and every read after that point is close to pure savings. A prefix that's written once and read back only once or twice, which is common in short-lived sessions or aggressively rotated cache keys, can end up costing more than not caching at all, particularly on a model where writes carry the newer markup. The gap between those two outcomes is large, and no single "caching helps" rule of thumb covers both.

What you enter

A prefix's approximate size, how many times you expect it to be read back within its retention window, and the model you're running. The calculator prices the write once and each read against the published rates, sums the total, and compares it against simply paying the plain input rate for every occurrence with no caching at all — the actual comparison that matters, not an abstract ratio.

Retention is part of the real answer, not a footnote

A break-even computed in isolation assumes every expected read actually lands within the cache's retention window, and that window is genuinely short by default — measured in single-digit minutes of inactivity for the ordinary in-memory case, with a much longer extended-retention option available separately. A caching strategy built around reads that are expected to land hours apart needs the extended path, not the default one, and this calculator's projection is only realistic if the read pattern you enter respects whichever retention behavior you're actually relying on.

The prompt_cache_key detail this calculator assumes

On GPT-5.6-family models, reliable matching depends on setting a stable prompt_cache_key for the workload — this calculator's numbers assume that's set correctly and traffic against it stays within the recommended rate. A workload without a stable key, or one pushing far more requests through a single key than recommended, will see a worse real hit rate than the break-even here predicts, for reasons this calculator can't see from the numbers alone.

Using this next to the token-cost estimator

This tool answers whether caching a specific prefix is worth doing at all. The token-cost estimator answers what a full request costs once you've decided — including cached-input pricing if you tell it a request is hitting a warm cache. Run this one first to decide on a caching strategy, then the estimator to price the actual requests that strategy produces.

What tends to surprise people running this for the first time

The most common surprise isn't that caching helps — most people already expect that — it's how few repeat reads it actually takes to clear the break-even once a prefix is genuinely being reused, and conversely how badly a workload with a low, one-or-two-read reuse pattern can underperform expectations on a model that charges for writes. A system prompt reused across an entire conversation clears its break-even almost immediately and keeps paying off for the rest of the session; a prefix rebuilt fresh on every request because it happens to include something request-specific near the top never gets the chance to be read back at all, and no amount of caching configuration fixes a prefix that was never actually stable to begin with.

Restructuring a prompt to make caching possible

If a calculation here comes back unfavorable, the fix is often upstream of pricing entirely: move anything request-specific — a timestamp, a user id, a piece of dynamic state — to the end of the prompt rather than the beginning, so the large, stable portion at the front stays byte-identical across requests and actually qualifies as a cacheable prefix. That's a prompt-engineering change, not a pricing one, and it's frequently the difference between a workload that can't benefit from caching at all and one that clears its break-even on the very first repeat.