AI Cache Savings: Measure Reuse Before Quoting the Discount

A proposal says your AI application can reuse the same background material at a much lower input price. That sounds attractive when every customer question includes the same catalogue, style guide or policy document.

The commercial question is how much of the actual workload receives that treatment. A discounted cache read is one component of a bill. It does not establish the cost of creating the cache, the frequency of successful reuse or the cost of producing and checking the answer.

For a small business commissioning an AI service, the useful request is a worked cost model supported by usage evidence. A headline percentage needs a denominator and a workload.

What prompt caching reuses

Anthropic’s prompt-caching documentation, checked on 4 November 2026, describes reusing matching prompt prefixes. In plain language, a prefix is the beginning of the material sent to the model. Its guidance separates cache creation, cache reads and uncached input, and documents cache lifetimes and model-dependent minimum lengths.

The practical implication is that sending similar questions does not itself establish that the reusable material was read from cache. The application needs to meet the relevant conditions, and its usage records need to show what happened.

Think of a fictional catalogue assistant that receives a stable product guide followed by each shopper’s question. The stable guide is a candidate for reuse. The changing question still needs processing. Whether the proposed implementation achieves that reuse is something to demonstrate.

Read the different prices as different events

Anthropic’s pricing documentation, also checked on 4 November 2026, lists base input, output, five-minute cache-write, one-hour cache-write and cache-hit rates separately. The rates depend on the model and configuration.

For procurement, ask the supplier to identify the exact model, hosting route, cache duration and applicable rates in its estimate. A rate for one model should not silently become an assumption about another. Keep the dated pricing reference beside the calculation so someone can revisit it when the configuration changes.

A fictional ten-request workload

Consider an illustrative rate card using abstract cost units. Processing one copy of a reusable prefix without caching costs one unit. Writing that prefix to a cache costs 1.25 units, and each successful read costs 0.10 units. These are explicit modelling assumptions, not a quotation for a particular service.

Suppose ten requests use that prefix. Without caching, the prefix component costs ten units. If the first request writes the cache and the following nine successfully reuse it, the same component costs 1.25 + (9 × 0.10) = 2.15 units.

The saving on this component is 7.85 units, or 78.5% of its uncached cost. That is a statement about these assumed events and prices. It is not yet a statement about the whole application.

Now suppose the changing inputs, generated answers and other costs together add twenty units across those requests, unchanged by the caching choice. The comparison becomes thirty units without caching and 22.15 units with it. The whole-workload saving is about 26.2%, despite the much larger saving on the reusable prefix.

The arithmetic is deliberately simple. Its purpose is to expose which part of the denominator is eligible for the saving. No live API calls or customer workloads were used to obtain these figures.

A write without reuse changes the outcome

Change the example again. Suppose each of the ten requests incurs a fresh cache write and none receives a cache read. Under the same illustrative rates, the prefix component costs 12.5 units, rather than ten units uncached.

Adding the same twenty units of other costs gives 32.5 units in total. In this scenario, the chosen caching pattern costs more. That result reflects the assumed absence of reuse; it does not settle whether caching is economical for another workload.

This is why the business case needs the number of writes and reads, alongside the price of a read. A supplier should explain how its estimate changes when requests arrive less frequently, the reusable content changes, or a new deployment begins.

A demonstration consisting of repeated identical requests in quick succession answers one useful question: can that configuration reuse the prefix under those conditions? It leaves open whether normal customer traffic has the same pattern.

Ask for evidence at the right level

For the fictional catalogue assistant, I would request a short report containing:

• The model, configuration and dated rate assumptions used in the estimate.
• The reusable prefix size and the changing input and output sizes.
• Recorded cache-write, cache-read and uncached input volumes.
• Results from both a fresh start and representative periods of normal use.
• The total workload cost alongside the isolated prefix saving.

Anthropic documents usage fields named cache_creation_input_tokens, cache_read_input_tokens and input_tokens. Its total-input calculation adds these three fields. Reading only the last field would omit cached input from the total represented by those records.

A business owner does not need to inspect every API response personally. They do need an explanation that traces the cost summary to appropriate records, with the same unit definitions throughout. If a report counts requests in one section and tokens in another, label that change clearly.

Keep cost optimisation tied to the job

The catalogue assistant still needs to answer accurately from the approved guide. A cheaper run that uses an outdated guide would fail that brief. Content updates should remain governed by the business’s accuracy requirements, even when updating affects reuse.

Likewise, do not enlarge a request purely to make a savings percentage look impressive. Compare the proposed design with a sensible uncached alternative that performs the same task. Unnecessary background material can distort the baseline.

For that broader comparison, MaryChuks.com’s guide to cost per successful AI task explains why review, retries and acceptance matter alongside token rates.

Prompt caching can be a useful part of an economical system. The business case becomes credible when it specifies what is reused, records how often reuse occurs and calculates the effect on the whole workload. Ask the supplier to demonstrate that operating pattern before relying on its savings estimate.

Sources

• Anthropic: Prompt caching — live technical documentation checked 4 November 2026.
• Anthropic: Pricing — live rate documentation checked 4 November 2026. Illustrative cost units in this article are modelling assumptions.