Deep Dive — OpenAI's 12-hour prompt cache costs 2.5x to write

If you are searching "is OpenAI's 12-hour prompt caching worth it", the honest answer is: not the way most people will use it. OpenAI's October 20 changelog added a longer cache lifetime to the Responses API and priced the write at double the default, which turns a feature that looked like a discount into a prepaid bet on how often you reuse the same prompt prefix.

That bet is worth making for a support bot with a pinned knowledge preamble, a coding agent that works in one repo all day, or an overnight batch that re-reads the same 40,000-token instruction block every hour. It loses money on anything you reuse twice.

What OpenAI actually shipped on October 20

The change is one new value on an existing setting. In the Responses API you can now set prompt_cache_options.ttl to "12h" instead of the default "30m", according to the API changelog. It applies to GPT-5.6 and later. The request-level setting covers the implicit breakpoint and any explicit breakpoint that does not carry its own value, and an individual breakpoint can override it — so a single request can mix a 12-hour block of stable instructions with 30-minute blocks of conversation.

The price is where this stops being a free upgrade. OpenAI's prompt caching guide puts 30-minute cache writes at 1.25× the uncached input rate and 12-hour writes at 2.5×, and is careful to say those are total write rates, not surcharges stacked on top of ordinary input: each token is billed once at either the uncached, cached-input, or cache-write rate. Reads are unchanged by lifetime — 0.1× ordinary input on most of these models, and 0.05× on GPT-6.1 Sol.

At GPT-6.1 Sol's published standard tier — $2 per million input tokens, $0.10 cached input, $2.50 cache write, $10 output, from the September 29 release note — the 12-hour write works out to $5 per million tokens. Reads stay at $0.10. You pay an extra $2.50 per million up front for the right to keep that prefix alive until dinner.

Two details matter more than the headline number. First, reuse refreshes the lifetime without another write charge, so a prefix in constant use is one write for the whole window. Second, upgrading a prefix that already has valid 30-minute coverage charges a fresh 12-hour write with no credit for the first one — toggling the setting on a warm cache costs you the full 2.5×.

The 24-hour setting that doesn't mean what it looks like

The most common misread of this release is that OpenAI shortened something. It did not, and the confusion comes from two fields measuring opposite directions.

The older prompt_cache_retention field takes "in_memory" or "24h" and is now deprecated. OpenAI's reference documentation describes it as a maximum retention policy — how long cached state may sit in GPU-local storage as application state — while prompt_cache_options.ttl is a minimum cache lifetime, a floor that governs whether a read is billed at the cached rate. The two are independent and do not interact.

So "12 hours" is not half of "24 hours." One is a guarantee you buy; the other is a ceiling the platform applies. Organizations without Zero Data Retention enabled default to the 24-hour maximum; organizations with it enabled default to in_memory, which typically means 5 to 10 minutes idle and up to an hour.

The guide is blunt about the limit of the new number: OpenAI may retain entries longer than the requested minimum, and "12h" does not set a deletion deadline or change the maximum data-retention policy. If your compliance team reads "12-hour cache" as a data-lifetime control, it is the wrong lever. The cached object is an encrypted set of key-value tensors held on the local GPU machines, not your prompt text in a database, and per OpenAI's data-controls page that state is not retained past the 24-hour expiry.

The arithmetic nobody puts in the launch post

Cache pricing has a break-even point, and the 12-hour option moves it in the wrong direction while raising the payoff on the far side.

Ignore output tokens and hold everything per million input tokens at price P. A cached read costs 0.1P. Without any cache, each use costs P, so N uses cost N·P.

With the 30-minute write you pay 1.25P once and 0.1P per reuse, so two uses cost 1.35P against 2P uncached — a 32% saving on the second use alone. That is why caching became standard practice: it pays from the second request.

With the 12-hour write you pay 2.5P once and the same 0.1P per reuse. Two uses now cost 2.6P, which is 30% more than not caching at all. Three uses cost 2.7P, a 10% saving. Ten uses cost 3.4P, a 66% saving. On GPT-6.1 Sol, a million-token prefix reused ten times across a working day bills $6.80 against $20.00 uncached — but the same ten uses inside a thirty-minute burst bill $4.30 on the default setting.

The comparison that matters is 12-hour against 30-minute, not against nothing. A 12-hour write costs exactly the same as two 30-minute writes. So the new option wins as soon as a day's traffic on that prefix would have needed a third write — meaning roughly an hour of activity with reuses continuing past the 30-minute lapse. Below that, you are paying double for a window you did not use. The moves in cutting an LLM bill without switching models still matter more than this one for most products, which is the useful way to read the release: a refinement, not a rescue.

There is a second-order effect worth stating plainly: a longer window makes a bigger prefix worth caching. A 1,024-token block is the minimum cacheable prefix for GPT-5.6 and later, but the write charge scales with whatever you put behind it. A 400,000-token repository context costs $2 to write at GPT-6.1 Sol's rates. Two dollars sounds trivial until an agent that misses its cache on every turn pays it ten thousand times, which is $20,000 for the same tokens that caching would have written once.

What silently voids the whole thing

A cache write is only recoverable if a later request matches the same prefix exactly, and OpenAI's guide is specific about what breaks the match: the model, the tool names, descriptions, schemas and their ordering, plus tool-specific instructions all feed the rendered prefix. Reordering a tool manifest — the kind of tidy-up that looks cosmetic in a diff — changes the prefix and burns the write.

That footgun is sharper at 12 hours because the write is more expensive and the window invites you to build systems that assume persistence. Any deployment that rewrites the system prompt, rotates an injected timestamp, or re-serializes a JSON schema in a different key order resets the clock and re-bills at 2.5×. The teams that benefit are the ones whose prompt assembly is already byte-stable; the teams that get burned are the ones that treat the prompt as a template with a datetime.now() in it.

Read the minimum lifetime as a billing rule rather than a service-level guarantee. OpenAI's documentation ties it to eligibility for cached-input pricing, and a cache entry still has to be present when the next request arrives. Eviction happens; the discount does not come with a hit-rate promise.

Why the number landed a day after DeepSeek's

OpenAI shipped 12 hours on October 20. DeepSeek open-sourced DeepInfer, the inference engine behind its own API, on the same day — and its deployment write-up describes a KV cache retention window of three days, which Chinese outlet Zhidx read as a 72-hour design target and framed OpenAI's timing as a direct response. Tibo, who runs ChatGPT and Codex, announced the cache option as part of a 28-day program of daily fixes.

The comparison is real and also not apples to apples, in a way that favors OpenAI's number being the more honest one. DeepInfer is Apache 2.0 and supports exactly one model, DeepSeek-V4.1-Flash, on Nvidia's SM100 and Huawei's Ascend 950, and only for offline inference, as The New Stack reported. The pieces that make a 72-hour cache into a product — distributed KV cache storage, prefill-decode disaggregation, cross-node load balancing, an online serving layer — are the pieces DeepSeek did not publish. Its 72 hours describes the inside of its own cluster, not a knob you can set.

Which makes the actual story here narrower and more interesting than a spec war. Cache lifetime has been an internal serving detail for two years; in one week it became a published number with a price attached, from both ends of the market. OpenAI is selling a guaranteed floor at a premium. DeepSeek is documenting what its own hardware does and giving away the engine minus the cache tier. Neither number tells you what your hit rate will be, and hit rate is the only variable that decides the bill.

Zhidx also reported that Codex and Work subscribers will get cache retention that is described as permanent. That claim is not in any OpenAI documentation at the time of writing, and Zhidx itself flags that the mechanism — retention policy, cache-hit billing, or a usage allowance — is unconfirmed. Treat it as a signal about direction, not a feature you can plan around.

What the skeptics get right

Two objections hold up.

The first is that the 2.5× write is a prepayment with no refund path. Every other caching decision in the stack — a CDN, a Redis layer, a database query cache — can be reversed mid-flight and you stop paying. Here the write is charged on the first request whether or not a second one ever arrives, and if the prefix shifts you pay again. For workloads with variable reuse, the expected value is genuinely negative and not obvious from the pricing table.

The second is accounting. OpenAI has been handing back credits for usage that did not match what customers expected: Zhidx reports roughly 40,000 accounts received credit refunds after the company noticed abnormal consumption. Cache writes have quietly become a large line item — the Codex-on-Bedrock report we covered in What is prompt caching described a run where cache writes were about 85% of spend with effectively zero hits. A feature that raises the write rate by 100% while depending on exact prefix matching is a feature that will produce more of those stories before it produces fewer.

The strongest counter-argument is simpler: 12 hours is not really for chatbots. It is for the workload everyone is actually building — long-running agents that re-send the same tool manifest and instruction block hundreds of times a day with gaps between turns. For that shape of traffic, a single write that survives the gaps is a large, boring, compounding saving, and the 30-minute default was never designed for it. OpenAI is now selling that window as a setting instead of leaving builders to write around the default.

What to watch next

Whether the option reaches the chat-completions surface. The reference documentation for that endpoint still lists 30 minutes as the only supported value for the cache lifetime setting, which would make 12 hours a Responses API feature for now.

Whether any lab publishes a cache hit-rate commitment rather than a retention window. A 12-hour TTL with a 40% hit rate is worse than a 30-minute TTL with a 90% one, and no provider currently exposes a number that lets a buyer compare them.

And whether Anthropic and Google answer with explicit TTL tiers of their own. Price cuts have moved in lockstep all year; cache lifetime is the newest dimension to compete on, and the first provider to publish a real hit-rate guarantee sets the terms for everyone else.

If you have moved a production workload onto the 12-hour cache, we want the before-and-after bill. Write to us via our contact page.