OpenAI's 12-hour prompt caching: when the higher write price pays off

On 20 October 2026 OpenAI added a 12-hour prompt cache lifetime to its Responses API. It is aimed at shared instructions, tools and context that are reused "even when requests are hours apart", in the words of the API changelog. The catch is the price: a 12-hour cache write costs 2.5 times the normal input rate, twice the 1.25 times charged for the default 30-minute lifetime. Whether it saves money depends almost entirely on how far apart your requests are. This article works through the break-even point and the billing rules worth knowing before you switch it on.

What changed

According to the prompt caching guide, for GPT-5.6 and later models:

• Cache writes are charged. The default 30-minute lifetime costs 1.25 times the uncached input rate to write. In the Responses API, prompt_cache_options.ttl can be set to "12h", which costs 2.5 times. The guide stresses that these are total rates, not surcharges on top of ordinary input.
• Reads cost the same for both lifetimes: 0.1 times the uncached rate on most of these models, and 0.05 times on GPT-6.1 Sol.
• The lifetime is a minimum. OpenAI may keep entries longer, and the guide says "12h" "does not set a deletion deadline" or change the maximum data-retention policy.
• The minimum cacheable prefix is 1,024 visible input tokens.

Earlier models keep the older prompt_cache_retention parameter with its in_memory and 24h values (GPT-5.5 and GPT-5.5 Pro support "24h" only) and no write charge. The new setting does not change those.

The pricing page now lists separate 30-minute and 12-hour write prices per model. For GPT-6.1 Sol at standard-tier, short-context prices, input is $2.00 per million tokens, cached input $0.10, a 30-minute write $2.50 and a 12-hour write $5.00.

Where the break-even sits

The key detail is how the two lifetimes refresh. A read refreshes 30-minute coverage to at least 30 minutes after that read, so a prefix used every few minutes stays warm on the default setting and needs only one write. A 30-minute read does not restart a 12-hour clock, and the guide does not say whether a "12h" request that reads existing 12-hour coverage extends it, so plan as if it does not. So the 12-hour option only helps when the gaps between requests are longer than 30 minutes but the reuse falls within 12 hours of the write.

For that pattern, compare the cost of the shared prefix across k requests, in multiples of its uncached input price:

• No caching: k.
• 30-minute cache: each request finds the cache expired and writes again, so 1.25 × k. That is more than no caching at all.
• 12-hour cache: one write and k − 1 reads, so 2.5 + 0.1 × (k − 1).

With two requests the 12-hour option costs 2.6 against 2.0 uncached and 2.5 for repeated 30-minute writes. From the third request it is cheapest: 2.7 against 3.0 and 3.75. With GPT-6.1 Sol's 0.05 read rate the crossover is the same, and the savings grow slightly faster.

A worked example

Take a review bot that runs eight times across a working day, roughly an hour apart, on GPT-6.1 Sol. Each run starts with the same 40,000-token prefix of instructions, tool definitions and coding standards.

• Uncached, the prefix costs $0.08 a run, or $0.64 a day.
• With the default 30-minute lifetime and the cache expiring between runs, each run pays a $0.10 write: $0.80 a day.
• With a 12-hour lifetime, one $0.20 write plus seven reads at $0.004 each comes to about $0.23 a day.

These figures cover only the shared prefix; output tokens and the changing part of each request cost the same in all three cases. If the same bot runs every five minutes instead, the default 30-minute cache stays warm and the 12-hour write would add cost for no benefit.

Billing details to check

• Upgrades aren't credited. The guide says upgrading valid 30-minute coverage to 12 hours "charges a new 12-hour write for those tokens, without credit for the earlier write".
• Mix lifetimes per breakpoint. A request-level ttl applies to the implicit breakpoint and to explicit breakpoints without their own ttl; prompt_cache_breakpoint.ttl overrides it for one breakpoint. Within a request, each token is billed once at the longest lifetime covering it. Each request can create up to four cache writes.
• Avoid writing what won't be reused. In explicit-only mode, content after the last selected breakpoint is billed at the ordinary input rate with no write charge. Without any explicit breakpoint in that mode, nothing is cached or written.
• A minimum lifetime is not a guarantee of reuse. The guide notes that the minimum lifetime governs eligibility for cache-read pricing; it does not guarantee that every request reuses stored state or is faster.
• Measure by lifetime. Usage now includes cache_write_tokens_details with ttl_30m_tokens and ttl_12h_tokens, which sum to cache_write_tokens. Price each separately and don't add the total again.

What it means for engineering and security leaders

Since writes became chargeable on newer models, caching is no longer automatically a saving. Our earlier overview of prompt caching costs noted that a cache that is never read costs more than not caching. The 12-hour option sharpens that trade-off: a strong saving for stable prefixes with sparse traffic, such as scheduled jobs, review bots and internal assistants used a few times a day, and a cost increase when applied to busy or fast-changing context.

There is also a data question. A longer minimum lifetime means cached model state derived from your prompts may be kept for longer. The guide says the setting doesn't change OpenAI's maximum retention policy, but teams with strict retention requirements should confirm how it fits theirs before enabling it broadly.

Practical takeaways

1. List workloads that reuse the same large prefix with gaps longer than 30 minutes. Those are the candidates for "12h".
2. Put stable material first and give only that breakpoint a 12-hour lifetime; keep session context on 30 minutes.
3. Use explicit-only mode where the end of the prompt changes on every request.
4. Update cost dashboards and estimates to price ttl_30m_tokens and ttl_12h_tokens at their own rates.
5. Compare a week of costs before and after the change, per workload, rather than assuming a saving.
6. Check the setting against your data-retention commitments.