On Tuesday 20 October OpenAI added a second lifetime to prompt caching in the Responses API. On GPT-5.6 and later a cache write has cost 1.25 times the input price and kept the prefix for a minimum of 30 minutes. Set prompt_cache_options.ttl to "12h" and the write costs 2.5 times the input price and the prefix is kept for a minimum of 12 hours. Reads cost the same under either lifetime, a tenth of the input price on most models and a twentieth on GPT-6.1 Sol. The changelog's pitch is shared instructions, tools and context kept cached "even when requests are hours apart."
The arithmetic is less flattering than the framing. A 12-hour write costs the same as two 30-minute writes, and every read of a 30-minute entry extends it by another 30 minutes for free. An agent that never goes quiet for half an hour never writes a second time under either lifetime, so the 12-hour option doubles its write bill and returns nothing. The longer lifetime pays for itself only when the 30-minute entry would have gone cold at least twice in the same 12 hours. A 30-minute entry I left alone was gone 38 minutes later. The 12-hour ones were not.
I ran it on my own key against gpt-6-luna with a 7,131-token prefix. The write, the read, the explicit breakpoint and the prewarm all did what the guide says. So did the line most people will trip on: I wrote a prefix at the 30-minute lifetime and sent it again six seconds later with "12h", and the usage block reported 7,131 tokens written at the 12-hour rate and zero cached, with no credit for the write six seconds earlier. The guide documents that. The Responses API reference still says 30m is "currently the only supported value," the error for a bad value lists only 30m, Chat Completions rejects 12h outright, and LiteLLM's spend log prices a 12-hour write at the 30-minute rate until a pull request opened on 21 October is merged.
The write you already paid for
The guide has a table for this, under "Overlapping writes and lifetime changes." The third row is the one that matters: valid 30-minute coverage through 2,000 tokens, a request that asks for "12h" at 5,000, and the bill is zero reads, zero 30-minute writes and a 5,000-token 12-hour write. The sentence under it says it plainly: "Upgrading valid 30-minute coverage to 12 hours charges a new 12-hour write for those tokens, without credit for the earlier write."
On the wire that looks like a miss. My request at 07:20:06 UTC with ttl: "30m" returned cache_write_tokens_details: {ttl_30m_tokens: 7131}. The same prefix at 07:20:12 with ttl: "12h" returned ttl_12h_tokens: 7131 and cached_tokens: 0. Six seconds apart, one prefix, 3.75 times the input price in total. On gpt-6-luna that is a quarter of a cent. On gpt-6-astra, where a 12-hour write is $25 per million tokens, flipping a 100,000-token system prompt that is already cached costs $2.50 on top of the $1.25 you paid for the 30-minute write, against $1.00 for sending it uncached.
The other direction is free. The prefix I had written at "12h" and then requested with "30m" came back as 7,131 cached tokens and no write, which is the guide's "any portion already covered by a valid 12-hour entry remains a cache read." The order matters. Decide the lifetime before the first request of the day, or let the 30-minute entry expire before you change it.
When 12 hours is cheaper
Three rules from the guide set the economics. A 30-minute read "refreshes coverage to at least 30 minutes after that read." A read of a 12-hour entry "preserves the later of the existing expiry and 30 minutes after the read" and "does not restart a 12-hour clock." Both write rates are totals, "not surcharges on top of ordinary input."
Put numbers on a 12-hour window. Under the 30-minute lifetime you pay 1.25 for the first write and 1.25 again each time the prefix has sat idle for more than 30 minutes. Under the 12-hour lifetime you pay 2.5 once. Two cold starts cost 2.5 either way. The 12-hour write wins at three, which means an agent that goes quiet for more than half an hour at least twice between breakfast and dinner. An agent that polls every 20 minutes, a chat product with steady traffic, a batch job that runs through its queue without pausing: all of these keep the 30-minute entry alive by reading it, and all of them pay double for nothing on "12h".
Anthropic's guide, which offers a 5-minute lifetime at 1.25 times and a 1-hour lifetime at 2 times, says it directly: for system prompts used more often than every 5 minutes, "continue to use the 5-minute cache, because this will continue to be refreshed at no additional charge." OpenAI's table has a "when to use it" column that says "stable instructions or reference material reused across longer gaps." It does not say what happens when the gaps are short.
What the API accepts, and what the reference says
The guide says the 12-hour lifetime is a Responses API feature and that "unsupported values return 400 invalid_request_error." Both held. The error message did not. ttl: "1h" on gpt-6-luna returned Invalid value: '1h'. Supported values are: '30m'. The request before it, with "12h", had succeeded. The Responses API reference says the same thing in prose: ttl "defaults to 30m, which is currently the only supported value." Elsewhere on the same page, the per-block prompt_cache_breakpoint.ttl is documented as "30m" or "12h".
Chat Completions has the parameter and not the value. prompt_cache_options: {ttl: "30m"} on /v1/chat/completions returned a normal response with cache_write_tokens: 7134 under prompt_tokens_details. The same call with "12h" returned the same 400 as the Responses API, supported values '30m'. The Chat Completions reference documents a ttl of "30m" or "12h" on prompt_cache_breakpoint inside a content part. The endpoint returned Unknown parameter: 'messages[0].content[0].prompt_cache_breakpoint.ttl' for both values.
gpt-5.5 returns prompt_cache_options is not supported on this model, which matches the guide: the older models keep prompt_cache_retention, now marked deprecated in the reference.
Two things worked. prewarm: true with ttl: "12h" wrote 7,131 tokens at the 12-hour rate, returned a completed response with no output items and output_tokens: 0, and the next request read all 7,131. That is how you write the day's prefix at 06:00 before the first event arrives. And the response object echoes what was applied: prompt_cache_options: {mode: "implicit", ttl: "12h"}, next to prompt_cache_retention: "24h", which the reference says is independent of it.
Your meter may not know
The usage block tells the two writes apart. Each Responses call that carried prompt_cache_options returned cache_write_tokens_details with ttl_12h_tokens and ttl_30m_tokens. A call with no options returned cache_write_tokens alone. The OpenAI Python SDK typed the breakdown in 3.36.0 on 21 October, listed in its release notes as "add 30-minute cache-write usage counts" and "clarify cache-write token totals."
Anything that prices your usage from the old fields charges the wrong rate. LiteLLM passes prompt_cache_options through to OpenAI, and pull request #47800, opened on 21 October at 06:21 UTC and still open this morning, describes the result: "it priced every cache write at the 30 minute rate, so spend logs and budgets showed about half the real cost of a 12h write." The price file on LiteLLM's main branch carries one cache-write rate for gpt-6-luna, $0.125 per million tokens, which is the 30-minute rate.
The price is guaranteed. The speed is not.
One sentence in the guide separates what the lifetime promises from what people will assume. "The minimum lifetime governs eligibility for cache-read pricing. It does not guarantee that every request reuses stored KV tensors or has lower latency." Cached state lives on individual machines, the guide says, and "traffic above 15 requests per minute can lead to overflow routing." The 12-hour write buys the discount on every request within the window. Whether the request also skips recomputing the prefix depends on where it lands.
The reverse holds too. "OpenAI may retain entries longer than the requested minimum." A 30-minute entry is not deleted at 30 minutes, it stops being guaranteed. On my key it was gone within 38 minutes. The prefix I wrote with the default lifetime at 07:20:09 and never touched again was rewritten in full at 07:58:03, 7,133 tokens at the 30-minute rate and zero cached. The two 12-hour entries from the same minute, one of them the upgraded prefix, both came back as 7,131 cached tokens.
What to do
Measure the gaps before you pay for the lifetime. The Prompt Caching Dashboard shows your hit rate and the diagnostics endpoint gives a reason for each miss. Count the rewrites of your stable prefix per 12 hours. Fewer than three, stay on "30m".
Do not flip a live prefix. Set "12h" on the first request of the day, or after the entry has been idle for 30 minutes, or accept 3.75 times the input price for the switch. If you run explicit breakpoints, put "12h" on the stable head and leave session context on the request default, which is what the guide's own example does.
Use prewarm: true for the morning write, so the first real request reads.
If you meter spend through LiteLLM or anything else that prices cache writes from one field, treat every 12-hour write as under-counted by half until the proxy reads ttl_12h_tokens.
If you are on Chat Completions, the option is "30m" or a 400. The 12-hour cache costs a migration to Responses first.