Prompt caching: the discount nobody budgets for

A FinOps guide by OptimNow · prices from the live OptimToken catalogue

Of the discounts published on an LLM rate card, prompt caching carries the largest percentage. Across the 201 models on OptimToken that publish a cache-read price, the median is 88% off input. It is also the narrowest: it applies to input tokens only, and only to the share of them that repeats. The saving that reaches an invoice is usually between 3.3% and 21.0%. Both figures are computed below from current prices.

The discount is not one number

Providers do not agree on what a cache read costs. The 3 most common published rates are 10%, 20%, 25% of the list input price, and the full range runs from 0% off to 99% off. Of the 292 models, 91 publish no cache-read price at all, which in practice means no cache discount to plan around.

Two consequences for model selection. A cache-heavy architecture is worth more on some models than others, so the cache rate belongs in the comparison alongside input and output. And a switch between two similarly priced models can change the cache economics without changing the list price at all.

Why the headline never reaches the bill

A cache read discounts input tokens. It does nothing to output tokens, and output is where most of the money goes on a typical workload. Two multipliers sit between the headline and the invoice: the share of the bill that is input, and the share of input that is a cache hit rather than a fresh read.

The ceiling matters as much as the realised figure. Even at a perfect hit rate, the median saving tops out at 56.3% on Meeting Summary, the most input-heavy profile, and sits at 19.6% on Marketing Content, where long outputs dominate. The 88% is a discount on input tokens, not on the bill, and those are different budgets.

Worked example: an agent workflow at 100,000 requests/month

The Agent Workflow preset models 6,000 input and 3,000 output tokens per request, at a 70% cache hit rate. Agent loops re-send a large stable prefix (system prompt, tool definitions, prior turns) on every call, which is the pattern caching was designed for.

On Claude Opus 5, caching returns $1.9K a month at this volume, against a list rate of $5.00/M input and $25.00/M output. Real money, and worth the engineering. It is also 18.0% of the bill, not 90%. GPT-5.5 returns the same $1.9K, from the same input price and the same 90% cache rate, but against a larger bill, so it lands at 15.7%. The cache rate is identical on both rows. The output price decides what it is worth. Compare the two side by side before assuming the cache rate settles the choice.

The same model, a workload where it does not pay

Hold the model still and change the workload. On the Marketing Content profile (2,500 in, 1,800 out, 20% hit rate), the same Claude Opus 5 saves 3.9%: $225 a month instead of $1.9K. The cache rate did not change. The workload writes long outputs from short, mostly fresh prompts, so there is little input to discount and little of it repeats. Generation-heavy work with varied prompts is the case where a caching project does not repay the effort of building it.

The cache price that saves nothing

In the catalogue, 4 models publish a cache-read price identical to the list input price: DeepSeek V4 Flash 0731, Schematron V2 Turbo, Schematron V2 Small, UI-TARS 7B. The field is populated, so a spreadsheet that reads "cache price present" scores these as cache-friendly. The discount is 0%. This is the reason to compare the cache rate against the input rate rather than checking whether a rate exists.

The write premium, which most business cases leave out

Every figure above uses published read prices only, so each is a ceiling on the saving rather than the saving. Writing to the cache is billed separately, and above the standard input rate. It is the half of the mechanic that gets left out of business cases, and the half that decides whether caching pays at all.

Anthropic publishes ×1.25 on input for a 5-minute entry and ×2 on input for a 1-hour entry. Other providers structure it differently, and some fold the write into the standard input price, so treat these as Anthropic's published terms rather than a market rate. They are the only 2 numbers on this page not computed from the catalogue.

The hub's own Cost/req (after discounts) column does charge the write, which is why it can sit slightly above the read-only figures on this page. It assumes one token written for every 5 read. The write is billed at the model's published write rate where there is one, and at the ordinary input rate where there is not (the full formula).

The premium sets a break-even: a cached prefix has to be read enough times inside its lifetime to earn back what the write cost. Against the read rates providers publish today:

Read the table as a floor, not a target: even at the least favourable rate it publishes, 7 calls sharing one prefix is enough. That is why caching is close to automatic on a high-traffic path.

It also names the failure case exactly. A workload whose calls arrive further apart than the cache lifetime never reaches the second read. Every call writes a fresh entry, and the prefix bills at ×1.25 or ×2 of input instead of ×1. Cached, that endpoint costs more than leaving it alone. The variables are request rate and prefix stability, not prompt size, which is the intuition worth correcting: a large prompt cached once an hour loses money, and a small one cached every second makes it.

What to check before budgeting a caching saving

• Compute the input share of your own bill first. Caching cannot save more than that share, whatever the discount. On the Marketing Content profile the median model spends 74% of the request on output, so the ceiling is set before caching enters the discussion.
• Measure the hit rate, do not assume it. The gap between the two bars in the chart above is entirely hit rate. Providers report cache-read and cache-write tokens separately; that ratio is the number to track.
• Check the prefix is stable byte for byte. A timestamp, a session ID or a reordered tool list at the top of a prompt invalidates the entry. This is the most common reason a measured hit rate lands far below the modelled one.
• Match the cache tier to the traffic pattern. The longer tier costs twice the input rate to write. It pays only when calls are spread out enough to need it and frequent enough to reach break-even.
• Recheck after any model switch. Published discounts run from 0% to 99% across this catalogue, so a migration can change the caching business case even when list prices look similar.

For an organisation early in its FinOps practice, the useful first step is measurement rather than optimisation: split the bill into input and output, then into cache reads and writes. Teams already tracking that split can move to the break-even test per endpoint. These figures are list prices from the current snapshot, not audited spend, and they assume the token presets on the pricing table rather than your own traffic. Batch is the other published discount, and the one that reaches output tokens: when the −50% applies covers it.

The FinOps reasoning behind this guide comes from OptimNow's open-source practice library: github.com/OptimNow/cloud-finops-skills.

Data snapshot: 2026-09-30 · Compare all models · Cloud compute pricing · All guides