OpenAI's 12-hour prompt cache is live: split your agent context into two TTLs

On October 20 OpenAI added a 12-hour option to prompt caching in the Responses API. prompt_cache_options.ttl now accepts "12h" next to the default "30m", on GPT-5.6 and later models. Shared instructions, tools, and context stay cached across requests that are hours apart, at cached-input pricing instead of a full reprocess ( changelog ).

The headline everyone quotes is the 12 hours. The part that changes how I structure agent requests is smaller and better: you can set a different cache lifetime per prefix inside one request. One block rides a 12-hour clock, another rides 30 minutes, and the tail opts out of cache writes entirely. That is a config decision, and it is worth getting right, because the write rate doubled.

Three facts from the prompt caching guide, stated exactly:

Omit everything and you keep the 30-minute default. Pass an unsupported value and the request fails with 400 invalid_request_error, so a config typo here becomes a visible outage rather than a silent fallback. I prefer that, but it means the TTL belongs in reviewed config, not in a script someone edits at 18:00 on a Friday.

OpenAI's own worked example first: write a prefix once at 30m and reuse it fully once, and you paid 1.35x its ordinary input cost, against 2x for processing it twice uncached. One write plus nine full reads across ten requests costs 2.15x, against 10x uncached. Caching was already the default for a reason.

The 12-hour tier changes a different term. At 2.5x per write and the 0.1x read rate, one write plus two full reads costs 2.7x, against 3x for three uncached requests. Two reuses and you are already ahead. The real question is how often the 30-minute cache expires under you:

Dead even at two rewrites. From the third rewrite on, the 12-hour write wins, and it saves 1.25x per avoided rewrite. This assumes the prefix is fully reused each time, which is exactly what keeping it stable buys you.

The agents that cross the two-rewrite line are the unattended ones. A cron agent that runs every hour. An overnight review loop that sleeps between steps. A session resumed after lunch. Every gap longer than 30 minutes used to mean a fresh 1.25x write of the whole stable prefix, which is the spike pattern I hit and measured in why your agent bills spike mid-task.

Interactive chat does not cross the line. Requests seconds apart keep the 30-minute cache warm anyway, and a 2.5x write on a large stable block is money spent for nothing. Keep the default there.

Here is the layout the docs example points at, trimmed to the shape that matters:

{ "model": "gpt-6.1-sol", "prompt_cache_options": { "mode": "explicit", "ttl": "30m" }, "input": [ { "role": "developer", "content": [ { "type": "input_text", "text": "Rules, conventions, reference material that changes at most daily", "prompt_cache_breakpoint": { "mode": "explicit", "ttl": "12h" } } ] }, { "role": "user", "content": [ { "type": "input_text", "text": "Session context, files read this session", "prompt_cache_breakpoint": { "mode": "explicit" } }, { "type": "input_text", "text": "The current question" } ] } ] } Enter fullscreen mode Exit fullscreen mode Three zones. The developer block carries the 12h override because it holds material that survives the day: system rules, coding conventions, reference docs. The request-level "30m" covers every breakpoint without its own TTL, which is the session context that lives for minutes.

The last block, the current question, gets no breakpoint and no cache write at all, because nobody will ever reuse it.

The refresh semantics are friendlier than I expected. A read served by a 30-minute entry extends coverage to at least 30 minutes after the read. A read served by a 12-hour entry keeps the later of the existing expiry and 30 minutes out. Neither one restarts the 12-hour clock, and neither incurs another write charge. An agent that polls every few minutes rides the single original write all day.

One caveat the guide states plainly: 12 hours is a minimum lifetime, not a deletion deadline. OpenAI may retain entries longer, and the setting does not change the maximum data-retention policy. If your concern is retention rather than price, this parameter is not the control you are looking for.

Three boundaries worth writing down. The 12h value applies to GPT-5.6 and later models, so a mixed fleet pins some requests to 30m no matter what the config asks for. These settings do not change the older prompt_cache_retention parameter, which still does its own thing on older models. And the knob lives in the Responses API; a stack still calling the older endpoints gets nothing from this until it migrates.

Tool definitions belong there, and they are bigger than people think. I measured nine MCP servers costing 41k tokens before the first user prompt; that block is part of the prefix, and under a 12h TTL it is written once per day instead of once per cold session. Rules files belong there too, with one discipline attached: the block must actually stay stable. Edit a rule mid-day and you re-pay the full prefix at the 2.5x rate, because the cache keys on the unchanging start of the request. Stable means stable.

The volatile tail is everything else: file contents you just read, command output, the question itself. Ordering violations now cost in both directions. Churn inside the 12-hour block forces expensive rewrites. Stable material left at the tail means you pay ordinary input on it every single request, which is the exact waste caching exists to remove.

Two related reads if you are rethinking layout: what survives compaction covers the sibling problem at the context-window end, and if your 12-hour block would hold twenty rules your agent ignores anyway, the cheaper fix is cutting the rules first. The best cache prefix is the one you shortened before you paid to store it.