AI Prompt Caching: Measure the Workflow Saving, Not the Discount

ROI & Cost Optimisation

2 November 2026 | By Ashley Marshall

A huge discount on cached input can make a surprisingly small difference to your AI bill. Start with the part of the workflow you are actually paying to repeat.

A discounted token is not a discounted business process

A headline discount on cached AI input can look like a business case all by itself. It is not. Prompt caching reduces the charge for reusing eligible input context. It does not automatically reduce the cost of the answer, the connected systems, a failed attempt or the person checking the result. Before asking your developer to optimise anything, ask which part of the monthly bill actually comes from repeated input. That single question can prevent a technically successful project from delivering an economically disappointing result.

The current Anthropic’s prompt caching documentation gives a concrete example. Claude Sonnet 5.5 lists standard input at $2 per million tokens and cached reads at $0.10 per million tokens. That is a 95% reduction on eligible cache reads, not a 95% reduction on everything your application does. Five-minute cache writes are listed separately at $2.50 per million tokens, and output at $10. These are published US dollar API rates checked on 2 November 2026, not a quotation for a UK implementation or an assumed exchange rate.

Consider an illustrative workflow whose original £100 of variable usage consists of £20 of cacheable input and £80 of other charges. Even eliminating that £20 entirely would only reduce those charges by 20%. Real caching still has read and possibly write costs, so the saving would be smaller. This example is arithmetic, not a reported client outcome. Its purpose is to make the denominator visible before anyone promises a percentage.

What this means in practice is that finance and operations should approve a cost breakdown, not a screenshot of a pricing table. Separate repeated input, changing input, output, tool calls, retries and human review. Then decide whether the repeated portion is large enough to justify the work.

Find stable context before buying a longer cache lifetime

Prompt caching works best where requests genuinely share a stable beginning. A support assistant may repeatedly need the same approved policy, tone instructions and tool descriptions before receiving a different customer question. A document review workflow may repeatedly apply the same checklist to separate files. Those repeated instructions are candidates for reuse. The changing customer question or new document is not automatically reusable just because the application has enabled caching.

The supplier’s actual request structure matters. Anthropic documents the prefix order as tools, system and messages. Do not interpret a generic blog diagram as permission to reorder those API components. Within the structure your platform supports, avoid unnecessary changing material before reusable context. A fresh timestamp embedded in the beginning of a long instruction block can undermine the very reuse you intended to buy. Ask the implementer to demonstrate hits from real requests rather than merely point to an enabled setting.

Lifetime is another commercial choice, not a badge of sophistication. Anthropic documents a five-minute default lifetime, refreshed when the cached content is used, and an optional one-hour lifetime with a higher write charge. The clock starts at the request that writes or reads the entry, not when its response finishes. A long-running answer therefore consumes some of the available reuse window. A workflow used in a short burst may behave very differently from one opened occasionally throughout the working day.

Start with observed arrival patterns. How often does the same eligible prefix recur, on the same model and supported hosting route, before expiry? Keep model, routing and deployment differences visible in the experiment. Do not consolidate resilient infrastructure merely to improve a cache chart. If usage is sparse, accepting ordinary input billing may be cheaper and simpler than extending lifetime or redesigning the application.

Calculate the break-even point using the correct prices

Cache writes can cost more than ordinary input, so the first request may be more expensive. Subsequent eligible reads need to recover that premium. The right calculation compares the same repeated prefix over the same number of requests. It should not compare a cached input line with a total bill containing output and tool fees. Use the actual model and platform rates in your account, including any negotiated terms.

For a worked example, take exactly one million reusable input tokens across two otherwise identical requests using the Sonnet 5.5 rates above. Without caching, that repeated portion costs $4: two ordinary inputs at $2 each. With a five-minute cache write followed by one eligible read before expiry, it costs $2.60: $2.50 plus $0.10. That is a $1.40 saving on the repeated portion. Output and changing input remain outside this deliberately narrow example.

Use the one-hour write rate of $4 instead and those same two requests cost $4.10 for the repeated portion. That is slightly more than the uncached $4. With a third eligible request, the cached total becomes $4.20 versus $6 uncached. Longer lifetime can pay, but only when enough real reuse arrives. These examples assume identical eligible content, successful reuse, no other surcharges and the published rates remaining applicable.

Recent commentary reinforces why the model cannot be omitted from the spreadsheet. Finout’s October pricing review distinguishes cache rates between model generations, while BenchLM’s October pricing reference lists model-specific cache-read rates. Treat those as supporting explanations; the provider documentation and your contract remain the pricing authority. For a UK budget, translate the final invoice consistently into pounds and state how VAT is treated. Do not insert a convenient exchange rate without dating it.

Measure a working week, including cold starts and review time

A convincing demonstration often repeats the same request several times in a row. That is useful for checking that caching works, but it can exaggerate the saving available in production. Real traffic includes quiet periods, changed instructions, interrupted sessions and different customer inputs. Measure a representative working week, including the first request after a pause. If Monday mornings always begin cold, those writes belong in the business case.

Record the workload, exact model, deployment route, instruction version, input usage, cache writes, cache reads, output usage and task outcome. Keep diagnostic records proportionate and avoid storing customer prompts merely to calculate a saving. Usage counts and request metadata are often enough. Where the platform exposes different usage fields, have the implementer document their definitions before finance aggregates them.

Anthropic’s uncached input count is not the entire prompt. To calculate a token-based read share, include uncached input, cache creation and cache reads in the denominator. Also distinguish that metric from the proportion of requests that experienced any hit. One tiny reused prefix can make a request count as a hit while barely affecting the bill. Neither percentage is a substitute for actual cost per acceptable completed task.

What this means in practice is a small comparison with a clear acceptance rule. Use the same model, representative tasks and quality checks before and after enabling caching. Include review minutes, failed attempts and any additional maintenance. Compare the distribution of response times, not just the fastest warm response. An improvement that disappears during busy periods may not help the customer queue. If the experiment requires changing the prompt as well, record that separately: otherwise you cannot tell whether caching or the rewrite caused the result. Keep the existing approval process throughout the trial.

Keep privacy and quality boundaries outside the saving target

The strongest counterargument is reasonable: if caching is available with a small implementation change, why spend time analysing it? For a high-volume workflow with long repeated context, that may be exactly right. Run a small test and take the saving. The caution is against confusing cheap reuse with permission to retain more data, share more context or replace quality checks. Those are separate decisions with separate owners.

For UK organisations, the ICO’s data minimisation guidance remains relevant: personal data should be adequate, relevant and limited to what is necessary. Caching does not create a special exemption from that principle. Review the provider’s retention arrangements, supported product and contractual settings for the particular deployment. Do not assume a caching feature has identical terms across direct APIs, cloud platforms and consumer chat products.

Keep customer-specific context separate where your access rules require it. Reusing an approved general policy is different from reusing a customer’s account information across unrelated cases. Authentication, retrieval filters and permissions must remain effective whether a cache hits or misses. Also distinguish prompt caching from storing a previous finished answer. The former reuses processing of input context; it is not a guarantee that an old answer remains correct or authorised for a new person.

The practical decision is modest. Identify one repeat-heavy workflow, establish its baseline, test the supported caching option and keep it only if total cost per acceptable outcome improves. TensorMesh’s recent breakdown is useful background on write premiums and reuse, but generic savings claims cannot replace your own traffic. Name an owner for future price or model changes. Review the result when instructions, model or routing change. The goal is a cheaper dependable service, not a more impressive cache percentage.

Frequently Asked Questions

Is prompt caching the same as reusing an old answer?

No. Prompt caching reuses processing of eligible input context. It does not establish that a previous answer is correct or authorised for a new request.

Can a cache make the first request more expensive?

Yes. Some providers charge a premium for cache writes. Later reads need to recover that premium before the repeated portion becomes cheaper.

Should we always choose the longest cache lifetime?

No. Compare the additional write charge with the eligible reuse that actually occurs before expiry. Sparse traffic may not justify a longer lifetime.

Does a 95% cache-read discount mean a 95% cheaper workflow?

No. That discount concerns eligible cached input only. Output, changing input, tools, retries and human review can remain unchanged.

Which workflow should a small business test first?

Choose an existing repeat-heavy workflow with long stable instructions and enough traffic to measure. Avoid starting with short one-off prompts or an application whose costs are mainly human review.

Do we need to log customer prompts to measure savings?

Not necessarily. Usage counts, model and deployment identifiers, instruction versions and task outcomes often provide the necessary evidence without retaining prompt text.

Can we assume the same rates through a cloud platform?

No. Confirm the exact model, hosting route, region, account terms and supported caching behaviour. Direct API documentation is not a substitute for your platform contract.