Prompt caching costs: reads, writes and real savings

Prompt caching costs depend on how much input your application actually reuses, what the model charges for writing that input to a cache, and what it charges for reading it later. A discounted cached-input rate is useful only for the tokens that receive it. Output tokens and changing input can still dominate the bill.

OpenAI’s current documentation also distinguishes newer models with a cache-write rate from earlier models with different caching behavior. An estimate based on an old tutorial can therefore understate the cost of a mostly changing prompt.

Start with the current rate categories

The OpenAI prompt-caching guide describes three input categories for GPT-5.6 and later: ordinary input, input written to the cache, and input read from it. Writes cost 1.25 times the ordinary input rate. Reads cost one tenth of that rate on most of those models, and one twentieth on GPT-6.1 Sol.

These are alternative rates for the relevant input tokens. A cache write is not charged as the ordinary input price plus another full write price.

The official pricing table lists the following standard rates for GPT-6.1 Sol when checked on October 6, 2026:

The same table separates standard rates from fast-mode rates. Keep the model, mode and token category together when comparing costs. The numbers above do not apply to every OpenAI model, to other providers, or to a consumer ChatGPT subscription.

For other models, start with their current listing in the Webtamine API price catalog and follow its official source. Our pricing method explains the catalog’s common request assumptions.

A six-request example

Suppose an application sends the same eligible 12,000-token prefix six times. Assume the first request writes that entire prefix and the following five read it successfully. These are illustrative calculations, not measured results from an application.

At GPT-6.1 Sol’s standard rates, processing that prefix six times as ordinary input would cost $0.072. One write costs $0.015; five reads cost $0.003 in total. The prefix’s combined cost would be $0.018, a 75% reduction.

That percentage applies only to the reusable prefix. It excludes changing input and output. If each request also adds 1,000 ordinary input tokens and generates 2,000 output tokens, those additions cost $0.066 across six requests. The total changes from $0.138 without prefix reuse to $0.084 with it: a reduction of about 39%, rather than 75%.

The changing-input assumption means those tokens receive the ordinary rate. If an implementation also writes changing suffixes, that part of the calculation needs the write rate instead. Do not hide it inside a single average “input price.”

When a write pays for itself

For a model with a read rate of one tenth of ordinary input, one write followed by one full read costs 1.35 times the prefix’s ordinary cost. Processing that prefix twice without caching costs twice its ordinary cost. The second successful use therefore already makes that particular prefix cheaper across the pair.

A prefix written once and never reused costs more than processing it once at the ordinary rate. This is why a low read price cannot rescue a workload full of cache writes and misses.

The relevant question is how often the same saved prefix is used while it remains eligible. Six requests from different users can share common instructions in an application, but different customer documents may create separate prefixes. Six requests are not automatically six uses of one cache entry.

Similar text is not enough

The guide describes caching in terms of eligible prefix boundaries and exact matches. For GPT-5.6 and later, the minimum cacheable prefix is 1,024 visible input tokens; OpenAI’s hidden system content does not count toward that threshold.

Stable instructions, shared examples and stable tool definitions can make useful reusable material. Changing content belongs later in the request when the application can arrange it that way. Reordering tools or changing structured-output definitions can change the prefix and prevent an expected match.

The boundary also matters. A long block of text that merely resembles yesterday’s prompt is not evidence of a hit. OpenAI’s guide warns that sharing a common prefix does not itself guarantee reuse when a suitable cached boundary is absent.

In a conversation, appending a new message can preserve an earlier boundary. Extending or editing content inside an existing message can change the boundary the application expected to reuse. Request construction affects costs even when the visible instructions seem almost identical.

Explicit breakpoints give a narrower budget

On supported models, explicit caching lets the application mark where reusable content ends. In explicit-only mode, a request without explicit breakpoints does not read or write the prompt cache. Content after the final selected breakpoint uses the ordinary input rate rather than receiving a cache-write charge.

That can be useful when a fixed instruction package precedes frequently changing documents. The application can cache the package and leave the varying material outside the selected prefix.

OpenAI permits up to four cache writes per request; combining an implicit breakpoint with explicit ones uses one of those slots. This is an implementation constraint, not a reason to add four breakpoints to every prompt. Choose boundaries that correspond to content likely to recur.

For GPT-5.6 and later, the documented default minimum lifetime is 30 minutes after the most recent write or reuse. An entry may remain longer, but a cost forecast should not assume indefinite retention. Older models have different retention settings and behavior.

Measure reads, writes and the whole response

Inspect the returned usage data rather than counting repeated words yourself. The guide includes cached_tokens and cache_write_tokens in usage examples. Those categories let you distinguish successful reuse from writing new content.

For a useful cost check, record the model and mode, input categories, output tokens and request cost over a representative workload. Compare the complete workload, including failed reuse and changing prompts. A test consisting only of repeatedly sending one identical prompt can overstate savings for a document-processing application.

Caching also does not promise identical answers. It reuses prompt processing, not a previously generated response. Generation settings and model behavior still matter. Cached tokens also count toward token-per-minute limits, according to the guide; a smaller invoice does not necessarily allow a higher request rate.

How Anthropic’s Claude API differs

Anthropic’s prompt-caching documentation uses the same idea with different switches and lifetimes. Caching is opt-in: you add a cache_control field, either once at the top level of the request, where the system places the breakpoint on the last cacheable block and moves it forward as a conversation grows, or on individual content blocks for finer control. The cached prefix covers tools, system and messages, in that order, up to the marked block.

The default lifetime is 5 minutes, refreshed at no extra cost each time the entry is read, and measured from the start of the request that writes or reads it. A response that takes 4 minutes to stream leaves about one minute for the next request to reuse the prefix. A 1-hour lifetime costs more to write.

Anthropic’s table lists a 5-minute write at 1.25 times base input. For Claude Opus 5.5, checked October 10, 2026: base input $4, 5-minute write $5, 1-hour write $8 and cache hits $0.20 per million tokens, with output at $20. The six-request arithmetic above works the same way with those rates; the shorter default lifetime matters more for traffic that arrives in bursts several minutes apart.