OpenAI adds 12-hour prompt caching to the Responses API, with cache writes at 2.5x the input price

OpenAI's API changelog for 20 October 2026 says that you can now choose 12-hour prompt caching in the API, listed under v1/responses. The entry gives the reason in one sentence: a 12-hour cache keeps shared instructions, tools and context cached longer, so they keep the lower cached-input price even when your requests are hours apart. And it gives the cost: a 12-hour cache write is 2.5x the input token price. If your requests share a long fixed beginning and arrive in bursts with quiet hours between them, work out what it does to your bill.

What changed

Prompt caching saves the beginning of a prompt — the prefix — so that a later request starting with the same text reads it from the cache instead of paying the full input price for it. On GPT-5.6 and later, writing a prefix to the cache for the default 30-minute lifetime costs 1.25× the standard, uncached input rate. In the Responses API you can now ask for a 12-hour minimum lifetime instead, at a write rate of 2.5× ordinary input. Reading what is cached costs 0.1× the ordinary input rate on most of these models and 0.05× on GPT-6.1 Sol, whichever lifetime you chose. The guide says plainly that these are total write rates, not surcharges added to ordinary input, and that read rates are the same for both lifetimes.

In the Responses API, prompt_cache_options.ttlchooses the minimum cache lifetime , and it takes"30m", the default, or "12h". Set nothing and nothing changes: with no lifetime set anywhere, you keep the default"30m"behaviour. Send a value it does not support and you get a400 invalid_request_error. Older models are untouched: these settings do not change theirprompt_cache_retentionparameter.

"Minimum" matters. OpenAI may keep entries longer than you asked, and "12h"sets no deletion deadline and does not change the maximum data-retention policy. Nor is it a clock that reading resets: a read from an entry with 12-hour coverage does not restart a 12-hour clock, and it does not charge another write.

The pricing page now prices both writes in columns of their own, per 1M tokens : input, output, cached input, 30-minute write and 12-hour write. For gpt-6-astra those are $10.00, $50.00, $1.00, $12.50 and $25.00 ; for gpt-6.1-sol $2.00, $10.00, $0.10, $2.50 and $5.00 ; for gpt-6-luna $0.10, $0.50, $0.01, $0.125 and $0.25.

What it means for you

On all three rows the 12-hour write is exactly twice the 30-minute write — $25.00 against $12.50 , $5.00 against $2.50 , $0.25 against $0.125. So the question OpenAI tells you to ask is the right one: compare the higher 12-hour write rate with the cost of rewriting the prefix after 30-minute coverage expires.

Work it through on gpt-6.1-sol, per million prefix tokens, as the table prices them. While requests keep coming, the 30-minute cache looks after itself, because each read refreshes coverage to at least 30 minutes after that read. The cost appears when traffic pauses for longer than that. With one such gap, the 30-minute cache expires and the prefix is written twice: $2.50 + $2.50 = $5.00. The 12-hour write costs $5.00 once, and the request after the gap reads it for $0.10: $5.10. With one gap the two come out level, a read apart. With two gaps it is $7.50 against $5.20, and every further gap widens the difference. So"12h" pays when a stable prefix would otherwise go cold at least twice in its 12 hours; if your traffic never pauses for half an hour, the longer lifetime only doubles your first write.

That matches OpenAI's own advice: consider "12h"for stable prefixes reused across longer gaps. And the prefix has to be long enough to be cached at all: 1,024 tokens on GPT-5.6 and later.

One request can mix both. A breakpoint — the marker where a cached prefix ends — can carry its own lifetime through prompt_cache_breakpoint.ttl. The guide suggests keeping material you reuse all day at the start of the prompt and giving its breakpoint"12h", with the session's own context left at "30m".

Watch one trap. If a prefix is already cached for 30 minutes and you move it to 12 hours, you pay a new 12-hour write for those tokens, with no credit for the earlier write.

Then check what you are billed. The response's input_tokens_details.cache_write_tokens_details splits writes into ttl_30m_tokens and ttl_12h_tokens, which do not overlap and add up to cache_write_tokens. To cost a request, multiplyttl_30m_tokens by 1.25× your input price and ttl_12h_tokensby 2.5×. Ifttl_12h_tokens keeps appearing for the same prefix through the day, something early in your prompt is changing and the long lifetime is buying you nothing. How the cache matches a prefix, and why its order matters, is in our guide What Prompt Caching Is.

The source

OpenAI's API changelog, the entry of 20 October 2026, with the prompt caching guide and the pricing page, all on developers.openai.com.