Twelve-hour prompt caching is not "the cache, but longer". It is a trade: you pay a higher write rate for a longer window in which the same prefix can be read back cheaply. The write rate for the default thirty-minute lifetime is 1.25x ordinary input, the twelve-hour write is 2.5x, and the read rate is the same for both lifetimes. So the decision reduces to one question about your workload: will the same prefix actually be reused inside that window? If the answer is no, the higher write rate buys nothing.
This is the first piece here that quotes OpenAI's published multiples, under the pricing policy that allows relative values while keeping absolute rates out. Everything below follows the current prompt caching guide and the changelog entry that introduced the option, checked on 2026-10-26. Verify against those pages before you change a production configuration.
What the option actually changes
The official description is compact: twelve-hour caching keeps shared instructions, tools, and context cached longer, so you can benefit from lower cached-input pricing even when requests are hours apart. That sentence contains both halves of the trade. The benefit is the longer reuse window. The cost is stated in the next sentence of the changelog: twelve-hour cache writes cost 2.5x the input token price.
Nothing about the read side changes. The guide is explicit that subsequent reads cost 0.1x the ordinary input rate on most current models and 0.05x on GPT-6.1 Sol, regardless of the selected lifetime. So the common worry, that choosing the longer lifetime makes every read more expensive, is unfounded. The premium is charged once, at write time.
The three rates that matter
Every input token in a cached request falls into one of three buckets, and keeping them separate prevents most confusion.
Uncached input is the ordinary rate. A cache write costs 1.25x ordinary input for the default thirty-minute lifetime, or 2.5x for twelve hours. A cache read costs 0.1x on most models and 0.05x on GPT-6.1 Sol. The guide also notes that cache-write pricing is not an additive fee: each input token is billed at one of the three rates, not at the ordinary rate plus a surcharge.
That framing matters when you compare options. Moving from thirty minutes to twelve hours does not change what a hit costs. It changes what a miss costs to populate.
The official cost examples, and what they do not say
The guide gives two worked comparisons at the 0.1x read rate with thirty-minute writes. Writing a prefix once and fully reusing it once costs 1.35x its ordinary input cost, against 2x for processing it twice without caching. Across ten requests, one write and nine full reads cost 2.15x, against 10x without caching.
Those are ratios, not bills, and the article will not turn them into bills. The useful reading is structural. Caching wins when reads dominate writes, and the break-even point is early: a single reuse already puts you ahead at the thirty-minute write rate. With the twelve-hour write rate the arithmetic shifts, which is exactly why the reuse question has to be answered before the setting is chosen.
The guide also mentions that cached input is discounted by up to 95% relative to ordinary input. That is the ceiling of the read discount, not a promise about your traffic.
When twelve hours pays
The option is designed for a specific shape of workload: a large, stable prefix that is reused across gaps measured in hours rather than seconds. Shared instructions, tool definitions, and long reference material are the canonical examples. If a team opens new sessions throughout the day against the same preamble, the twelve-hour lifetime keeps that preamble readable between sessions instead of letting it expire between them.
The test is concrete. Take the prefix you intend to cache, and ask how many times it will be read within twelve hours of a write. More than once, and the longer lifetime is doing work. Exactly once, and you are paying the higher write rate to save a single read, which is a bad trade unless that read is enormous. Zero times, and you have donated the premium.
A second, subtler case: prefixes that change on a daily cadence. A policy document or a product catalogue that is regenerated each morning and read all day fits the twelve-hour window well. A prefix that changes every few minutes does not, no matter how large it is.
When it loses, and the trap that makes it worse
The losing cases are the mirror image. A one-shot batch process reads each prefix once and never returns. A pipeline that injects a timestamp or a request identifier into the system prompt produces a different prefix on every call. A workload that runs once a day has nothing to reuse inside the window. In all three, the twelve-hour write is a premium paid for a window nobody uses.
Then there is the trap that costs money even when the workload is right. The guide states it plainly: upgrading valid thirty-minute coverage to twelve hours charges a new twelve-hour write for those tokens, without credit for the earlier write. In other words, the experiment "run it on the default first, then switch to twelve hours" pays twice for the same tokens.
The practical consequence is to decide the lifetime before the first write, not after. If a prefix is meant to serve the whole day, configure it as twelve hours from the start. If you are unsure, the cheaper mistake is to begin at thirty minutes and accept that promoting later will re-charge the write, rather than to write at twelve hours speculatively and discover the prefix was never reused.
What twelve hours is not
The lifetime is a minimum, not a deadline. The guide says OpenAI may retain entries longer than the requested minimum, and that twelve hours does not set a deletion deadline or change the maximum data-retention policy. Two misreadings follow. It is not a promise that data disappears after twelve hours, so it cannot be used as a retention control. And it is not a guarantee that entries survive that long, because retention beyond the minimum is not assured.
There is a related detail worth knowing: a thirty-minute read refreshes coverage to at least thirty minutes after that read, and if the entry has valid twelve-hour coverage, the read preserves the later of the existing expiry and thirty minutes after the read. It does not restart the twelve-hour clock and does not incur another write charge.
Setting it without guessing
The configuration surface is small. In the Responses API, prompt_cache_options.ttl sets the minimum lifetime for the request. It applies to the implicit breakpoint and to explicit breakpoints that do not carry their own ttl. A breakpoint can override it with prompt_cache_breakpoint.ttl. Omitting both preserves the default "30m" behavior, and unsupported values are rejected with an invalid_request_error.
The guide's recommended split is worth adopting as a default pattern: keep material reused throughout the day at the start of the prompt and give its breakpoint a "12h" lifetime, while session context that changes more frequently stays at "30m". This is the mix-lifetimes pattern, and it captures the economics without paying the premium on content that will not be reused.
These settings apply to the current models; they do not change the older-model prompt_cache_retention parameter, which uses its own values. Check the model-differences table before assuming which knob applies to your deployment.
Two structural constraints shape how many breakpoints you can use. Each request can create up to four cache writes. In implicit mode, the implicit breakpoint consumes one of those four slots, leaving three for explicit breakpoints. And in explicit-only mode, content after the last selected breakpoint is processed at the uncached input rate without a cache-write charge, which is the clean way to keep volatile content, such as the current question or a fresh identifier, out of the cached prefix.
If you are still working out where your prompt boundaries should be, the prompt caching in practice piece covers the mechanics, and the order of operations for cutting costs puts caching in the right sequence relative to model choice and prompt design. The request shape itself, which determines where breakpoints can sit, is covered in the API shape comparison.
What breaks a hit
Three conditions have to hold before any of this pays, and each one fails silently.
The entire rendered prefix must match. The cache stores key-value tensors rather than tokens, and a change anywhere before a breakpoint invalidates everything after it. That is why a timestamp interpolated into the system prompt is so destructive: it is small, it looks harmless, and it guarantees a miss for every request.
The prefix must meet the minimum cacheable length. For GPT-5.6 and later, the guide puts it at 1,024 visible input tokens, and hidden system content does not count toward the minimum. A short prompt with a twelve-hour breakpoint is simply not eligible.
And a hit is not guaranteed even when the prefix matches. Entries live on individual machines, caches are not shared across organizations or regional processing boundaries, and routing determines whether a request reaches a machine holding a matching entry. The guide is direct that the minimum lifetime governs eligibility for cache-read pricing, not a guarantee that every request reuses stored tensors or responds faster. Maintaining a session can preserve a shared prefix, but it does not guarantee a hit either.
Verifying, then deciding
Two official tools answer the "is it working" question. The Prompt Caching Dashboard reports cache read hit rates and the composition of reads, writes, and uncached input, which is where the ratio of reads per write becomes visible. The Prompt Cache Diagnostics tool investigates why a request missed. Use them together: the dashboard tells you that the economics are off, and diagnostics tells you which prefix broke.
Keep a record of the lifetime chosen, the breakpoint layout, and the observed reads per write, with the field discipline from the logging guide. When hit rates fall, the failure triage map is the right first stop before you touch the configuration. And if you are validating a prompt change at the same time, the testing guide keeps the two experiments from contaminating each other.
The checklist
- Count how many times the prefix will be read within twelve hours of a write.
- Confirm the prefix is stable: no timestamps, identifiers, or per-request text before the breakpoint.
- Confirm the prefix clears the minimum cacheable length for the model.
- Choose the lifetime before the first write, not after.
- Put day-long material at the front with a twelve-hour breakpoint, and keep session context at thirty minutes.
- Do not run at thirty minutes and promote later unless you accept a second write charge.
- Watch reads per write in the dashboard, and use diagnostics when the ratio disappoints.
- Re-read the official pricing terms before publishing any claim about savings.
Twelve-hour caching is a bet that a prefix will be reused across hours. The read rate stays the same, so the entire question is whether the longer window gets used. Answer that with data from your own traffic, and the setting becomes a straightforward decision rather than a default to switch on.
All figures and behaviors above follow the official pages as checked on 2026-10-26; confirm them against the current documentation before relying on them.