OpenAI's 12-Hour Prompt Cache Costs 2.5× to Write. On Paper It Pays Off From the Third Request

Three uses to break evenHover to explore

Prompt caching is one of the few levers that cuts an AI product's bill without touching quality. OpenAI's new option makes the cache last much longer, at a higher price for writing to it. Whether that saves you money depends on one thing most teams have never measured: how long the gaps are between requests that share the same prompt.

This article is based on OpenAI's prompt caching guide and its changelog, and on coverage by Runtime Wire. The prices are OpenAI's published multipliers for GPT-5.6 and later. The break-even figures in sections 3 and 4 are my own arithmetic from those multipliers, on simplified assumptions stated there, and are not OpenAI's.

1. What OpenAI launched

On 20 October 2026, OpenAI let developers opt into a 12-hour prompt cache in the Responses API, next to the existing 30-minute default. OpenAI pitched it at persistent agents: "Persistent agents, like dots, reuse context throughout the day," its developer account said.

On GPT-5.6 and later models, you set it with prompt_cache_options.ttl to "12h" instead of the default "30m". Both are minimum lifetimes.

2. The prices

For GPT-5.6 and later, as multiples of the normal (uncached) input-token price:

Three other rules matter:

• Minimum size. Only prompts with at least 1,024 visible input tokens are cached.
• Prefixes, not prompts. The cache matches the beginning of a request. Change anything early in the prompt — a timestamp, a user name, the order of tools — and everything after it misses.
• Separate accounting. An optional prompt_cache_key keeps caches separate per customer or user.

On earlier models there is no extra charge for writing to the cache, and the retention options are different.

3. The arithmetic

Take a prefix — system prompt, tool definitions, reference material — of size P, reused N times in 12 hours. Ignore output tokens and the part of each prompt that changes; they cost the same either way.

• No cache: each request pays 1.0 × P. Total: N × P.
• 30-minute cache, requests more than 30 minutes apart: the cache expires between requests, so every request writes again at 1.25 × P. Total: 1.25 × N × P.
• 30-minute cache, requests a few minutes apart: one write, then reads. Total: (1.25 + 0.1 × (N − 1)) × P.
• 12-hour cache: one write, then reads. Total: (2.5 + 0.1 × (N − 1)) × P.

Solving for when the 12-hour cache is cheaper than no cache gives N > 2.7. Against a 30-minute cache that keeps expiring, it gives N > 2.1. In other words: on these simplified assumptions, from the third use of the same prefix within 12 hours, the 12-hour cache wins — as long as the gaps are long enough that the default cache would have expired.

When requests arrive every few minutes, the default cache never goes cold, and the 12-hour option simply costs 1.25 × P more per window for nothing.

4. An example

An illustrative support agent has a 20,000-token prefix: instructions, tool schemas and a product manual. A customer uses it 8 times over a working day, roughly once an hour or two. Billed input for the prefix, in token-equivalents:

• No cache: 8 × 20,000 = 160,000
• 30-minute cache: expires every time, 8 × 1.25 × 20,000 = 200,000
• 12-hour cache: 2.5 × 20,000 + 7 × 0.1 × 20,000 = 64,000

That is a 60% cut against no caching on the prefix — and it shows something less obvious: for sparse traffic like this, the default cache can cost 25% more than not caching at all, because you pay the write premium without ever reading.

If each customer has their own reference material in the prefix, each one needs their own write. The saving still applies per customer, but only for customers who come back three or more times in the window.

5. Who benefits, and who doesn't

Long, repeated context is the biggest hidden cost in agent products, as we saw when one refactor cost $14.29 in tokens. Caching is the cheapest fix — but only when it matches how your users actually behave.

6. What I would not claim

That the 12-hour cache always lasts 12 hours, or that cached reads are guaranteed. OpenAI describes both lifetimes as minimums, and a cache can still miss. Real savings will be somewhat lower than the arithmetic.

That the break-even figures are OpenAI's. They are my calculation from published multipliers, assuming identical prefixes and ignoring partial matches.

That these prices apply to every model. They are for GPT-5.6 and later; earlier models have no write surcharge and different retention options, and GPT-6.1 Sol reads at 0.05×.

That caching is right for sensitive data without checking. OpenAI notes that cached data may be held in GPU-local storage. If you have data-retention commitments, check how caching fits them before extending it.

The honest summary

OpenAI now offers a 12-hour prompt cache in the Responses API. On GPT-5.6 and later, writing to it costs 2.5× the input price, against 1.25× for the 30-minute default, and reads cost 0.1×. On simplified arithmetic, the 12-hour cache beats both no caching and an expiring 30-minute cache from the third reuse of the same prefix within 12 hours — but only when requests are more than 30 minutes apart. For high-frequency traffic it adds cost, and for sparse traffic the default cache may already be costing more than no cache.

The decision is not about the feature. It is about your traffic pattern.

This week, log how often each long prefix is reused and the gaps between uses. Move stable content to the front of your prompts. Then turn on 12 hours only for the prefixes that come back three or more times a day with long gaps.

Sources: OpenAI, Prompt caching guide — the 30-minute default and 12-hour option, the prompt_cache_options.ttl parameter on GPT-5.6 and later, the write prices of 1.25× and 2.5× and read price of 0.1× (0.05× on GPT-6.1 Sol), the 1,024-token minimum, prefix matching, prompt_cache_key, the absence of a write surcharge on earlier models and the note on GPU-local storage. OpenAI, API changelog — the 20 October 2026 launch. Runtime Wire — the Responses API scope, persistent agents as the target use, and OpenAI Developers' quote about dots. The break-even calculations and the support-agent example are mine, on the assumptions stated in sections 3 and 4.

Related Posts

One Refactor Cost $14.29. Every File the Agent Read Stayed on the BillSeptember 2, 2026

The AI MVP Evaluation Set: Test Real User Tasks Before You LaunchJuly 16, 2026

DeepSeek's Cheap Model Just Beat Its Own Flagship: What V4-Flash 0731 Means for Your StackAugust 4, 2026