When does prompt caching save money?

Selected primary sections reviewed: 9 October 2026.

Prompt caching can reduce the cost of repeatedly sending the same instructions or reference material to an AI model. But “caching enabled” is not a saving. The useful question is: does your workload produce enough billable cache reads to outweigh writes and misses, without making the results less useful or the data handling unacceptable?

This guide helps you choose between a bounded trial, continued use, a revised prompt layout and a hold. It does not assume a particular provider’s prices or that your account has already recorded cache hits.

Start here

• Find the repeat: identify the stable opening portion of your requests, not just their shared topic.
• Check the rules: confirm eligibility, persistence and charging for the exact service and model.
• Measure the difference: compare observed reads, writes and misses with equivalent work—not promised savings.

What caching reuses—and what it does not

Prompt caching reuses computation associated with an input prefix: the opening portion of a request. The model still generates a new output.

Response caching reuses an earlier output. That is a different decision, involving whether an existing answer remains suitable.

A prompt-cache hit therefore does not mean you received a stored answer, an identical answer or a correct answer. Review requirements remain.

Consider an illustrative document-analysis workflow. Every request starts with the same approved instructions and reference pack, followed by a different document. The fixed opening is a candidate for prompt caching; the new document is not part of that shared prefix.

By contrast, a workflow that changes its opening instructions every time, or runs infrequently, may offer little reuse. Repeated meaning is not enough: the service must recognise an eligible match that is still available.

Find the prefix worth testing

Lay out a representative request in order. Identify:

1. Stable instructions, tool definitions and reference material.
2. The point where job-specific content begins.
3. Anything before that point that changes between requests.
4. The shared portion’s token length and the requests’ actual timing.

Where appropriate, place stable material first and changing material afterwards. Do not weaken instructions, remove necessary context or add confidential material merely to increase the potential hit rate.

A timestamp near the beginning, an edited instruction or a changed tool definition may affect matching. Relevant feature settings can matter too. Treat a revised prefix as a new version, not an automatic continuation of the old cache.

Length and timing also matter. A stable prefix may fail a model-specific minimum. Requests may arrive before cache construction finishes or after the reusable content is no longer available. Ten similar requests spread across a month are not equivalent to ten eligible requests within a supported persistence window.

DeepSeek: separate the historical milestone from today’s rules

For historical background, see the DeepSeek context-caching announcement. The announcement described automatic caching, billing based on actual hits and reuse beginning at the input prefix. It is useful evidence of that historical development.

It is not today’s price sheet or operating specification. The page warns that API prices subsequently changed. Its historical prices, headline savings, latency example and statements about retention, privacy or capacity should not be carried into a current purchasing decision.

The DeepSeek context-caching guide, checked against this guide on 9 October 2026, describes a more detailed matching process. Caching is enabled by default, but a hit requires an already persisted, fully matching prefix unit. The guide describes request-boundary, common-prefix and fixed-interval persistence; some shared content becomes reusable only after multiple requests.

Cache construction takes seconds, and hits are best-effort rather than guaranteed. Use the applicable current documentation to plan a trial, then inspect reported usage. Neither the historical announcement nor the current guide proves that your workload will hit.

Check one provider configuration—not a universal caching rule

Write down the provider, exact model/version, endpoint, feature settings and measurement dates before calculating savings.

The OpenAI prompt-caching guide, checked on 9 October 2026, describes separate write/read charge classes and explicit or implicit breakpoints for GPT-5.6 and later; earlier models differ. The Anthropic guide distinguishes five-minute and one-hour write charges, along with cache-read charges.

Do not transfer a multiplier, minimum length, breakpoint rule or lifetime from one service or model version to another.

Documentation	Usage fields to inspect	Question to resolve
DeepSeek	prompt_cache_hit_tokens, prompt_cache_miss_tokens	How much input actually hit or missed?
OpenAI	cached_tokens; where applicable, cache_write_tokens	Which fields and charge classes apply to this model/version?
Anthropic	input_tokens, cache_creation_input_tokens, cache_read_input_tokens	How much input was ordinary input, newly cached or read from cache?

In Anthropic’s documented API context, total input is the sum of those three components. Do not assume another provider uses the same accounting structure.

A miss is not a complete billing description. Under an applicable provider rule, an eligible request that misses may create a new cache entry and incur a write charge. Check what happens on that request; do not automatically price every miss as ordinary uncached input.

Work through the prefix arithmetic

The following is an invented example, not a provider tariff or measured account result.

Assume a 1,000-token prefix costs 1 unit at the ordinary uncached input rate. For this illustration only:

• A write costs 1.25 units.
• A full read costs 0.1 unit.
• A miss charged only as ordinary input costs 1 unit.

Across ten comparable requests, assume one write, five full reads and four ordinary-input misses, with no additional writes.

Prefix treatment	Calculation	Cost
Without caching	10 × 1	10 units
One write	1 × 1.25	1.25 units
Five full reads	5 × 0.1	0.5 units
Four ordinary-input misses	4 × 1	4 units
Total with caching	1.25 + 0.5 + 4	5.75 units

The difference is 4.25 units, or 42.5% of the uncached prefix cost.

That is not a 42.5% saving on the whole request, completed task or monthly budget. Changing input, generated output, tools and review remain outside this calculation.

Now change the assumption. Suppose each of the four misses instead becomes a new write, charged at the invented 1.25-unit total write rate rather than the 1-unit ordinary-input rate:

5 writes × 1.25 + 5 reads × 0.1 = 6.75 units.

The prefix saving falls to 3.25 units, or 32.5%. This second scenario is also hypothetical. Its purpose is to show why a miss-triggered write changes the result—not to specify any provider’s charging rule.

For a real service, establish whether the published write rate replaces ordinary input charging for those tokens or whether another accounting treatment applies. Do not double-count it.

Partial hits need similar care: price the read portion and the remainder in their applicable classes. Extra writes, fewer reads or changed rates can reduce or reverse the benefit. There is no universal break-even request count.

Run a bounded comparison

Use approved, representative material and a fixed quality standard. Compare with a matching no-cache baseline where supported, or a documented before-and-after period. If you cannot isolate caching from other changes, qualify the conclusion.

A compact trial record is enough:

Record	What to retain
Configuration	Provider, model/version, endpoint, features and owner
Prefix	Approved version, eligible length and changing-content boundary
Timing	Request count, cadence and applicable persistence rule
Usage	Reported writes, full/partial reads and misses
Charges	Applicable rates, check date and billing reconciliation
Outcomes	Answer acceptance, corrections and latency
Safeguards	Permission to use the service/material; data-handling review

Keep the model, task mix and review standard comparable. If prompt layout changes, check whether it changes answer quality as well as reuse.

Record output and tool charges and review effort alongside the input result, but keep the caching calculation distinct. The broader guide, What does an accepted AI result cost?, explains how to combine these into a workflow-level measure. Repeating that full worksheet here would obscure the narrower question: did prefix reuse help?

Retain only the minimum approved evidence. A general analytics log should not become a second store of client prompts or documents. A successful cache hit does not approve the provider’s retention arrangements.

Decide what to do next

Choose an outcome supported by the evidence:

• Continue within the approved scope: observed reads reduce costs on comparable work, quality remains acceptable and data-handling checks pass.
• Adjust and retest: early prompt changes, partial matches or request timing appear to limit reuse. Version the adjustment and measure again.
• Hold: the charge treatment is unclear, evidence is missing, quality worsens or permissions remain unresolved.

If you have not measured the workload, recommend a bounded trial—not a realised saving. Distinguish expected hits from observed reads and estimated charges from reconciled costs.

Recheck after a material change to the prefix, cadence, model, endpoint, features or rates. For the wider authorisation decision, return to the parent routing guide.

The useful conclusion is specific: this configuration, over this period, produced this input-cost difference under these conditions. “Prompt caching saves money” is too broad to guide the next decision.

Source and scope note

Selected sections of official DeepSeek, OpenAI and Anthropic documentation were compared with this guide on 9 October 2026. These pages are living; verify current terms before a real pricing decision. No account usage, billing, retention setting or actual cache hit was inspected for this guide. All numerical examples are illustrative.