# OpenAI's 12-hour prompt cache: when the 2.5x write pays off

URL: https://infro.io/blog/openai-12-hour-prompt-cache
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-27
Last modified: 2026-10-27
Last reviewed: 2026-10-27 (next review due 2026-11-26)
Topic: Cost and FinOps
Format: Guide

> OpenAI's 12-hour prompt cache, added to the Responses API on 20 October 2026 for GPT-5.6 and later models, keeps a prefix eligible for cache-read pricing for at least 12 hours. A write costs 2.5x the input rate and a read 0.1x (0.05x on GPT-6.1 Sol and Terra), so it pays from the second read inside the window. Use it for shared context that is reused hours apart, where the 30-minute default would expire between requests; for traffic that arrives every few minutes the 30-minute cache at 1.25x is cheaper.

Key takeaways:
- On GPT-5.6 and later, the Responses API takes `prompt_cache_options.ttl` of `30m` (default) or `12h`; a 12-hour write costs 2.5x the input rate, a 30-minute write 1.25x.
- Reads cost 0.1x input on either lifetime, or 0.05x on GPT-6.1 Sol and GPT-6.1 Terra, so a 12-hour entry pays for itself from its second read.
- The 12-hour option is for context reused hours apart; when requests arrive every few minutes the 30-minute cache is cheaper.
- Measure with `cached_tokens`, `cache_write_tokens` and the `ttl_12h_tokens` breakdown in the response usage, not with prompt token counts.
- A 12-hour lifetime is a minimum for read pricing, not a promise of a hit on every request and not a deletion deadline.

OpenAI's 12-hour prompt cache pays off when a prefix is read at least twice inside 12 hours by requests spaced too far apart for the default 30-minute cache. A write to it costs 2.5 times the input rate and a read 0.1 times (0.05 on GPT-6.1 Sol and Terra), so the first read nearly covers the premium and the second puts you ahead[1]. OpenAI added it to the Responses API on 20 October 2026, describing it as a way to keep "shared instructions, tools, and context cached longer"[2].

The rest of this guide is the arithmetic, the request shape, the comparison with Anthropic and Gemini, and how to confirm in production that you are paying for reads rather than writes.

## What OpenAI changed

On GPT-5.6 and later models, prompt caching on the Responses API has two lifetimes, set with `prompt_cache_options.ttl`: `"30m"`, the default, and `"12h"`. Each can be overridden on an individual cache breakpoint with `prompt_cache_breakpoint.ttl`. These settings are separate from `prompt_cache_retention`, the older control that earlier models use[1].

|  | 30-minute (default) | 12-hour |
| --- | --- | --- |
| Setting | `ttl: "30m"` | `ttl: "12h"` |
| Write price | 1.25x input | 2.5x input |
| Read price | 0.1x input; 0.05x on GPT-6.1 Sol and Terra | Same |
| Minimum lifetime for read pricing | 30 minutes | 12 hours |
| Minimum prefix | 1,024 visible input tokens | Same |

Table: Prompt cache lifetimes on GPT-5.6 and later, from OpenAI's prompt caching guide and pricing page, read 2026-10-27.

Three details in the guide shape how you use it[1]:

- **The lifetime is a minimum, not a contract for hits.** "Minimum lifetime" is how long an entry is guaranteed to qualify for read pricing. OpenAI may keep entries longer, and the guide says the minimum does not guarantee that every request reuses stored tensors.
- **Write pricing replaces input pricing.** A written token is billed at 1.25x or 2.5x instead of the input rate, not in addition to it.
- **Reads do not restart the 12-hour clock.** The guide describes a 30-minute read of an entry with 12-hour coverage as moving expiry to the later of the existing expiry and 30 minutes after the read, with no new write charge. Plan for one 12-hour write per 12 hours of reuse.

For models before GPT-5.6 nothing changed: `prompt_cache_retention` still takes `in_memory` or `24h` on the models that support it, and those models carry no separate cache-write charge[1]. The pricing page lists cache-write rates only for the GPT-5.6 and GPT-6 models[3].

## Break-even arithmetic

Call the write multiplier *w*, the read multiplier *r*, and the number of reads one write serves *N*. Without caching, one write plus *N* reads would cost (1 + *N*) units of input. With caching they cost *w* + *rN*. Caching is cheaper once *N* > (*w* − 1) / (1 − *r*).

| Cache | Write *w* | Read *r* | Break-even reads | Pays from |
| --- | --- | --- | --- | --- |
| OpenAI 30-minute | 1.25 | 0.1 | 0.28 | The first read |
| OpenAI 12-hour | 2.5 | 0.1 | 1.67 | The second read |
| OpenAI 12-hour, GPT-6.1 Sol or Terra | 2.5 | 0.05 | 1.58 | The second read |
| Anthropic 5-minute | 1.25 | 0.1 | 0.28 | The first read |
| Anthropic 1-hour | 2 | 0.1 | 1.11 | The second read |
| Anthropic 1-hour, Opus 5.5 or Sonnet 5.5 | 2 | 0.05 | 1.05 | The second read |

Table: Break-even reads per write, from each provider's published multipliers, read 2026-10-27. Anthropic figures from its prompt caching guide.

The formula ignores output tokens, which are billed the same either way, and assumes every read finds the entry. The second assumption is the one that fails in practice, and it is where the choice of lifetime matters.

### Why the 30-minute default can lose for sparse traffic

The 30-minute write pays from the first read, but only if a read arrives while the entry is alive. Traffic that reuses a prefix every two hours, such as a scheduled summary job, a support desk overnight, or an agent a developer resumes after lunch, can find the entry gone. In the worst case every request pays the 1.25x write and never reads, which costs more than no caching at all. That is the gap the 12-hour lifetime fills.

> **Example: Illustrative: a shared prefix reused every two hours**
> A 30,000-token policy and tool prefix on `gpt-6.1-sol`, listed at $2.00 per million input tokens, read at 0.05x ($0.10 per million)[3][1]. Six requests reuse it within 12 hours, two hours apart.
> 
> | Approach | Prefix cost per 12 hours |
> | --- | --- |
> | No caching: 6 x 30,000 tokens at $2.00/M | $0.360 |
> | 30-minute cache, worst case (entry expired each time): 6 writes at $2.50/M | $0.450 |
> | 12-hour cache: 1 write at $5.00/M + 5 reads at $0.10/M | $0.165 |
> 
> At this spacing the 12-hour cache costs less than half of no caching; if the six requests had arrived within one 30-minute window, the 30-minute cache would cost $0.075 + $0.015 = $0.090 and win. The volumes are hypothetical and the arithmetic uses list rates; your provider bills from its own usage records.

## How to enable it

Prompt caching is on by default for supported models. In OpenAI's **implicit** mode the platform places one breakpoint at the end of the latest eligible message; in **explicit** mode you place every breakpoint, and a request with none creates no cache writes. A request can create up to four cache writes, and in implicit mode the automatic breakpoint uses one of them[1].

To put a whole request on the 12-hour lifetime, set the request-level option:

```json
{
  "model": "gpt-6.1-sol",
  "prompt_cache_options": { "ttl": "12h" },
  "input": [
    { "role": "developer", "content": [{ "type": "input_text", "text": "<shared policy, tools and examples>" }] },
    { "role": "user", "content": [{ "type": "input_text", "text": "Summarize ticket 4812." }] }
  ]
}
```

To keep only the long-lived part on 12 hours and the session on 30 minutes, OpenAI's guide shows explicit mode with a different lifetime per breakpoint: a request-level `"prompt_cache_options": {"mode": "explicit", "ttl": "30m"}`, a `"prompt_cache_breakpoint": {"mode": "explicit", "ttl": "12h"}` on the shared developer instructions, and a breakpoint with no `ttl` (so 30 minutes) on the session context[1]. Two placement rules from the guide: top-level `instructions` cannot hold an explicit breakpoint, so put reusable instructions in an `input_text` block of a developer message; and the cached prefix must be byte-identical, so keep timestamps, request ids and per-user data after the last breakpoint.

On GPT-5.6 and later, `prompt_cache_key` is optional and routing is automatic; keys are useful to keep cache accounting separate per customer and to prevent cache-hit probing across users[1].

## How the alternatives compare

**Anthropic.** Claude's cache has a 5-minute default and a 1-hour option set with `"ttl": "1h"` on `cache_control`. Writes cost 1.25x and 2x the input rate; reads 0.1x, or 0.05x on Opus 5.5 and Sonnet 5.5 and 0.025x on Fable 5.1. Each read refreshes the lifetime at no charge, and a top-level `cache_control` turns on automatic breakpoint placement[4]. For steady traffic a 1-hour Anthropic entry that is read at least once an hour can live all day on a single write. Anthropic loses to OpenAI's 12-hour option when gaps between reads exceed an hour; OpenAI's option loses when reads are frequent, because Anthropic's refresh keeps one cheaper write alive indefinitely.

**Gemini.** Implicit caching is on by default for Gemini 2.5 and later, with a 4,096-token minimum on Gemini 4 Argon, 3.8 Flash and 3.6 Flash[5]. Explicit caches on `generateContent` take any TTL ("no minimum or maximum bounds"), default to one hour, and bill storage for as long as the tokens persist; they are not available for Gemini 4 Argon and later, which use implicit caching only[6]. Gemini 3.8 Flash lists $0.75 input, $0.075 cached and $0.50 per million tokens per hour of storage through 31 December 2026, doubling on 1 January 2027[7]. Twelve hours of storage is $6.00 per million tokens held, so at those rates an explicit cache needs roughly nine reads in the window before it beats sending the prefix uncached. Storage pricing favours short TTLs with dense traffic; OpenAI's 12-hour write favours sparse traffic.

|  | OpenAI 12-hour | Anthropic 1-hour | Gemini explicit |
| --- | --- | --- | --- |
| Cost to keep a prefix | One 2.5x write per 12 hours | One 2x write, refreshed by reads | Storage per token-hour |
| Loses when | Reads are minutes apart | Reads are more than an hour apart | Reads are few compared with hours stored |
| Control | `prompt_cache_options` or per breakpoint | `cache_control` with `ttl` | Cache object with a TTL or expiry time |

Table: Long-lived prompt caches compared, from each provider's documentation read 2026-10-27.

## Measure it

Do not judge caching from prompt token counts. OpenAI's usage object separates what you paid for[1]:

- `usage.input_tokens_details.cached_tokens`: billed cache reads; it excludes tokens charged as writes.
- `usage.input_tokens_details.cache_write_tokens`: tokens written in this request.
- `cache_write_tokens_details.ttl_30m_tokens` and `ttl_12h_tokens`: the split of those writes by lifetime; they do not overlap and sum to `cache_write_tokens`.

The healthy pattern for a 12-hour prefix is one request with `ttl_12h_tokens` near the prefix length, then reads on later requests. Track per workload, per day: write tokens, read tokens, and reads per write. If reads per write falls below two, the 12-hour option is costing you money; if `ttl_12h_tokens` appears on many requests in the same window, the prefix is changing between them.

On data handling, OpenAI states that prompt caching is compatible with Zero Data Retention, that the cache holds encrypted key-value tensors rather than prompt text with a maximum retention of 24 hours, that the 12-hour setting is not a deletion deadline, and that caches are not shared across organizations or regional processing boundaries[1].

## Checking cache behaviour through INFRO

INFRO is a control plane in front of the provider accounts you connect; OpenAI bills you directly for every token, cached or not, and INFRO's charge is a separate subscription.

**The option reaches OpenAI.** On an OpenAI connection, INFRO's `POST /v1/responses` sends the body as you wrote it, so `prompt_cache_options` and per-breakpoint settings reach OpenAI unchanged. A request INFRO has to translate for a Chat Completions target cannot carry them. See [coding agents](https://infro.io/docs/coding-agents).

**Reads are visible per request.** Each request row and response carries the provider's cached token count (`prompt_tokens_details.cached_tokens` on chat, `input_tokens_details.cached_tokens` on Responses), and [usage analytics](https://infro.io/docs/observability/analytics) group requests and estimated provider cost by model, key and project. [Traffic changes](https://infro.io/docs/observability/traffic-changes) raise a finding when the cached share of prompt tokens on a model drops by 10 percentage points or more, the usual sign that a prefix stopped matching.

**What INFRO does not do yet.** INFRO's estimate does not price OpenAI cache writes separately: written tokens are estimated at the ordinary input rate, so a 12-hour write, billed at 2.5x, is under-estimated in INFRO's figures. Use OpenAI's own usage fields above, or [reconciliation](https://infro.io/docs/cost/reconciliation) against your provider's cost report, for the true write cost. INFRO's own [response cache](https://infro.io/docs/features/caching) is a different feature: a hit there never reaches your provider at all.

## Questions

### How do I turn on OpenAI's 12-hour prompt cache?

On the Responses API with a GPT-5.6 or later model, set prompt_cache_options.ttl to "12h" for the request, or set ttl "12h" on a single prompt_cache_breakpoint inside an input content block. The default lifetime is "30m". OpenAI documents the option for the Responses API; its guide does not describe it for Chat Completions.

### How much does a 12-hour cache write cost?

2.5 times the model's input rate, against 1.25 times for a 30-minute write. Reads cost 0.1 times the input rate on either lifetime, or 0.05 times on GPT-6.1 Sol and GPT-6.1 Terra. The write price replaces the input price for the tokens written; it is not an extra fee on top.

### When is the 12-hour cache worth it?

When the same prefix of at least 1,024 tokens is read at least twice within 12 hours and the requests are far enough apart that a 30-minute entry would have expired. For requests a few minutes apart, the 30-minute cache costs less per write and is refreshed by its reads.

### How do I know the 12-hour cache is working?

Read the response usage: input_tokens_details.cached_tokens counts billed cache reads, cache_write_tokens counts tokens written, and cache_write_tokens_details splits writes into ttl_30m_tokens and ttl_12h_tokens. One ttl_12h write followed by cached reads on later requests is the pattern you want.

### Does a 12-hour cache keep my prompt for 12 hours?

OpenAI says the cache stores encrypted key-value tensors, not prompt text, with a maximum retention of 24 hours, and that the 12h setting does not set a deletion deadline or change the data-retention policy. Prompt caching is compatible with Zero Data Retention, and caches are not shared across organizations.

## Sources

1. Prompt caching — OpenAI. https://developers.openai.com/api/docs/guides/prompt-caching (accessed 2026-10-27)
2. Changelog — OpenAI. https://developers.openai.com/api/docs/changelog (accessed 2026-10-27)
3. Pricing — OpenAI. https://developers.openai.com/api/docs/pricing (accessed 2026-10-27)
4. Prompt caching — Anthropic. https://platform.claude.com/docs/en/build-with-claude/prompt-caching (accessed 2026-10-27)
5. Context caching — Google. https://ai.google.dev/gemini-api/docs/caching (accessed 2026-10-27)
6. Context caching (generateContent) — Google. https://ai.google.dev/gemini-api/docs/generate-content/caching (accessed 2026-10-27)
7. Gemini Developer API pricing — Google. https://ai.google.dev/gemini-api/docs/pricing (accessed 2026-10-27)