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

On GPT-5.6 and later, a cache write bills at 1.25x the plain input rate for the default 30-minute lifetime, or 2.5x for the 12-hour one — instead of that rate, never on top of it. On every earlier model a written token simply bills as ordinary input, with no surcharge. Every later read against the same prefix bills at a steep discount, the same whichever lifetime wrote it — 0.1x the input rate on most current models, 0.05x on GPT-6.1 Sol and GPT-6.1 Terra. 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 — but only on a model whose writes carry the GPT-5.6 markup. On an older model an unread write simply breaks even. 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, the model you're running, and — on GPT-5.6 and later — which lifetime you'll ask for. The result shows the other lifetime's cost and break-even alongside, so the trade is visible either way. 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 lands while the entry still exists. On GPT-5.6 and later, an entry stays reusable for at least 30 minutes after its last write or read, and each reuse resets that clock without another write charge — so a steady conversation keeps its prefix alive. Earlier models use in_memory retention, typically minutes of inactivity, or an extended 24h option. A strategy built on reads that land hours apart needs extended retention on an older model. On a newer one it used to mean paying for a fresh write each time; since October 20, 2026 the Responses API offers a 12-hour lifetime instead, at the higher write rate — which pays off when the reads that land inside those hours outweigh the write's extra cost. Choose it on the first write: upgrading an entry already cached for 30 minutes charges a fresh write, with no credit for the earlier one.

What this calculator assumes about hits

It assumes every read you enter really hits. On GPT-5.6 and later, OpenAI routes cache traffic automatically, so prompt_cache_key no longer affects whether you hit — it only separates cache accounting between your users. On earlier models a stable key still helps routing, at about 15 requests a minute per key. On every model, a real hit rate falls below what this calculator assumes when the prefix isn't byte-identical, when traffic on one prefix is high enough to trigger overflow routing, or when the entry expires — at least 30 minutes after its last use on GPT-5.6 and later. Prompt Cache Diagnostics on the Responses API explains individual misses.

One correction worth stating: until October this calculator billed the write of a pre-GPT-5.6 prefix at nothing, reading "no additional cache-write charge" as "free". The written tokens are input and bill at the ordinary input rate; only the GPT-5.6 surcharge is absent. The old figures overstated savings on every older model by one full prefix charge.

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.