OpenAI's 12-hour prompt cache costs twice as much to write as the 30-minute default. It pays for itself on the third visit, and switched on everywhere it makes a busy agent loop 39% dearer.

What changed on October 20

The changelog entry is two lines long: 12-hour caching exists in the Responses API, and its writes cost 2.5x input. The detail is in the caching guide. prompt_cache_options.ttl now takes "30m", the default, or "12h", on GPT-5.6 and later. You can set it per breakpoint too, through prompt_cache_breakpoint.ttl. The prompt needs 1,024 visible tokens before anything caches.

The price is the part people are misquoting. A 30-minute write has already cost 1.25x input on GPT-5.6 and later before October 20. That isn't new. A 12-hour write costs 2.5x. Both are the whole rate, not a fee on top of input; OpenAI's guide says so in as many words. Reads don't change with the lifetime: 0.1x input on most models, 0.05x on GPT-6.1 Sol.

Standard tier, per million tokens, prompts up to 272K input tokens, from OpenAI's pricing page on October 26, 2026. Over 272K every input-side column doubles and output is 1.5x. Batch and Flex halve every column, writes included. Fast doubles them. GPT-5.5 and older models still have free writes and use prompt_cache_retention instead.

Count the visits, not the hours

Put everything in multiples of the input price and the rule falls out quickly. Take a prefix that gets reused, with each request landing more than 30 minutes after the last. On the 30-minute cache every one of those requests finds the entry gone and writes it again at 1.25x. On 12h you write once at 2.5x and read at 0.1x after that.

Cost of the cached prefix as a multiple of its uncached input price, all visits more than 30 minutes and less than 12 hours apart. Reads at 0.1x, or 0.05x in the last column.

At two visits 12h loses to the 30m default by a tenth of the input price. Three is a win against both the default and no cache at all, and by ten the 12h prefix costs about a quarter of the 30m one. The awkward row is the first: a prefix that never comes back costs 2.5x on 12h, double the 30-minute write you would have paid anyway.

The 30m column hides something that predates this change and is easy to miss. On sparse traffic the default costs more than not caching, because every request pays 1.25x to write an entry that expires before anyone reads it. You can opt out: set prompt_cache_options.mode to "explicit" and place no breakpoints, and the guide says the request creates no cache writes. That's how you get the "no cache" column.

Same $2 card, less than half the bill

This is where OpenAI pulls away from Anthropic. GPT-6.1 Sol and Claude Sonnet 5.5 now charge the same $2 input, $0.10 read and $10 output. Anthropic's longest cache lifetime is one hour, at 2x input. OpenAI's is now twelve.

Picture a coding assistant with a 100,000-token prefix of system prompt, tools and repo context. A developer opens it six times across the day, about 90 minutes apart. Across 50 developers and 21 workdays that's 1,050 sessions a month. Here is the prefix line alone:

• GPT-6.1 Sol, 12h cache$577.50
• GPT-6.1 Sol, no cache$1,260.00
• Sonnet 5.5, no cache$1,260.00
• GPT-6.1 Sol, 30m default$1,575.00
• Sonnet 5.5, 5m cache$1,575.00
• Sonnet 5.5, 1h cache$2,520.00

Per session: Sol 12h is one write of 0.1M at $5.00 ($0.50) plus five reads at $0.10 ($0.05), so $0.55. No cache is six times $0.20. The 30-minute and 5-minute caches rewrite on every visit at $2.50 ($1.50). Claude's 1-hour cache also misses every visit and rewrites at $4.00 ($2.40). Output and new tokens are excluded and identical across rows.

Sonnet's best option here is to switch caching off, and that still costs 2.2x Sol on 12h. The 1-hour cache, the one Anthropic sells for exactly this kind of traffic, is the worst row on the chart, because a 90-minute gap clears it every time.

You can fight that on Claude. A tiny request every 55 minutes reads the prefix and keeps the entry alive, at a cent a ping on this prefix. It works, and it's a cron job you have to run for every active user. OpenAI just made it unnecessary.

The hot loop gets nothing for its money

An agent that fires a request every few seconds never lets a 30-minute entry expire. For that traffic, 12h buys a lifetime you'll never reach. It still doubles every write, and a loop writes all the time, because each turn appends new tokens that get cached for the next one.

Take the agent month we priced for Kimi K3.1 Pro on Saturday: 1 billion input tokens, 85% of them cache hits, plus 50 million output. On GPT-6.1 Sol with the default, that's 150M written at $2.50 ($375), 850M read at $0.10 ($85) and $500 of output: $960. Set ttl: "12h" globally and the writes become $750. Same work, $1,335, 39% more.

The fix is what the per-breakpoint setting is for. Put a 12h breakpoint at the end of the static part (system prompt, tool definitions, the repo map) and let the conversation tail cache on 30 minutes. The static part gets written once a day. The tail, the bit that changes every turn, stays at 1.25x.

Check your dashboard before you trust it

The usage object now splits writes by lifetime, under input_tokens_details, in cache_write_tokens_details.ttl_30m_tokens and ttl_12h_tokens. cached_tokens counts reads only. If your own cost code multiplies cache_write_tokens by one rate, it's wrong for any request that used 12h.

LiteLLM has exactly that bug right now. Its pricing logic bills every write at the 30-minute rate, which logs a 12h write at half what OpenAI charges. The fix was opened on October 21 and hadn't merged when we checked. Its review bot also flagged that the patch prices 12h writes at Standard rates on Batch, Flex and Fast requests. If you budget off a LiteLLM proxy, expect the invoice to come in above it.

One claim we can't back up. Codex lead Tibo Sottiaux posted on X that for logged-in Codex and Work users OpenAI keeps the cache "forever", so old conversations carry no penalty. That may be true inside Codex, but the API guide says nothing like it. The guide calls both lifetimes minimums and says entries aren't kept indefinitely. Plan on twelve hours.

How the others charge for time

Google is the only big provider that bills cache storage by the hour. Explicit caching on Gemini 3.8 Flash costs $0.50 per million tokens per hour until December 31, then $1.00. Holding our 100,000-token prefix for 12 hours costs $0.60 in storage, more than Sol's entire 12h write, on a model with a cheaper rate card. Gemini 4 Argon has no explicit cache at all, only implicit hits.

DeepSeek never charged for writes. Its disk cache builds itself on every request and is cleared "usually within a few hours to a few days" once unused. That's longer than any lifetime on this page, with no TTL to pick and no promise either.

We covered the rest of the caching price lists in July. The write fee was the hidden line then, and it still is. It's just got a second size.

Which traffic earns the 12-hour write

Turn on 12h for internal tools, coding assistants and support consoles, anything where the same person comes back to the same context a few times a day. Put the breakpoint on the static prefix only.

Leave it off for continuous agent loops and for one-shot traffic. The first never needs it. The second never reuses anything, so the 2.5x write is money gone.

If you're choosing between Sol and Sonnet 5.5 on a workload with long idle gaps, this is now the deciding line. Their rate cards match and their caches don't. Run your own visit pattern through our calculator.

Sources

• OpenAI API changelog and prompt caching guide - October 20 entry, ttl values, write and read multipliers, breakpoints, usage fields, retention
• OpenAI pricing - per-model 30m and 12h write columns, long-context and tier multipliers
• Anthropic pricing - Sonnet 5.5 rates and 5-minute and 1-hour cache writes
• Gemini API pricing and DeepSeek KV cache guide - storage pricing and cache lifetime
• LiteLLM PR #47800 and explainx.ai - 12h write billing bug and the Codex "forever" claim