OpenAI 12-hour prompt caching: when it pays, and when it costs more

OpenAI's Responses API can now keep a cached prompt for 12 hours instead of 30 minutes. Set ttl to "12h" and the shared start of your prompt, such as instructions, tools and reference documents, stays cached between requests that arrive hours apart. The catch is the price of writing it: 2.5 times the normal input price, against 1.25 times for the default. The 12-hour cache saves money when the same prefix is used more than about 4 times a day with gaps longer than 30 minutes. Closer together than that, the default is cheaper.

OpenAI added it on 20 October 2026 for GPT-5.6 and later models. Reading a cached prefix costs 0.1 times the input price on either setting, or 0.05 times on GPT-6.1 Sol. So the whole decision is how many writes you pay for.

How the 2 cache lifetimes are priced

Prompt cachingPrompt CachingLetting the API keep the processed start of a prompt for a few minutes, so later requests that begin the same way are cheaper and quicker. stores the processed start of a prompt so the next request with the same start skips the work and pays less for those tokens. On GPT-5.6 and later, OpenAI charges for putting a prefix in the cache and much less for each use of it:

A read keeps the 30-minute entry alive for another 30 minutes. A steady stream of requests therefore pays one write and then only reads, all day. The trouble starts when requests are further apart than that. Each one finds the cache expired, pays 1.25x to write it again, and nobody reads it. That is 25% more than sending the same prompt with no caching at all.

The 12-hour setting is the fix for that gap. One write at 2.5x covers half a day, and every request in between pays 0.1x.

The sum: when the 12-hour cache wins

Count in units of the prefix at full input price. Take requests spread evenly through the day, more than 30 minutes apart, and assume the 12-hour entry is written twice a day:

• 30-minute cache: every request writes. A day costs 1.25 times the number of requests.
• 12-hour cache: 2 writes at 2.5, the rest are reads at 0.1. A day costs 5, plus 0.1 for each request after the first 2.

At 4 requests a day the default costs 5 and the 12-hour cache 5.2. At 5 it is 6.25 against 5.3, and the gap grows from there until requests are 30 minutes apart (48 a day). Past that point the default cache never goes cold, and the 12-hour one only adds a dearer first write.

Try your own prefix, traffic and model price:

Try itDoes OpenAI's 12-hour cache pay for your prompt?

Shared prefix

20Ktokens

1K20K200K

Requests a day

12

every 2.0 hours

1485,000

Input price

$2per 1M tokens

$0.05$2$20

Cached read

0.1x input0.05x (GPT-6.1 Sol)

If nothing were cached

$0.48 / day

30-minute cache (default)

$0.60 / day

12-hour cacheCheaper

$0.24 / day

For a single prompt the money is small. A 20,000-token prefix used every 2 hours on a model at $2 per million input tokens saves about $0.36 a day. The sum gets interesting when there are many prefixes, each used a few times a day. Examples include an assistant that loads each customer's account history, a coding agent that keeps each repository's context, and a support bot with a long policy document per product. A thousand prefixes like that save about $360 a day.

When the 12-hour cache pays

• Per-customer or per-project context that each user returns to a few times a day: account notes, a contract, a codebase summary.
• Scheduled jobs that run every hour or 2 with the same instructions and tools: a report, a triage pass over new tickets, a data quality check.
• Agents that pause for a person. A review step that waits an hour for approval used to restart with a cold cache.
• Evaluation runs spread over a working day with the same rubric and examples.

When it costs more

• Busy prompts. A shared system prompt hit many times a minute stays warm on the default setting. Changing it to 12 hours doubles the cost of each write and saves nothing.
• Prefixes used once or twice a day. One write at 2.5x is dearer than 2 uncached requests.
• Prefixes that change. A cache is matched on the exact start of the prompt. If a timestamp, a user name or a tool list changes in the first part, nothing is reused on any setting. Put what changes at the end.

How to set 12-hour caching

In the Responses API, prompt_cache_options.ttl sets the lifetime for the request. In explicit mode you mark where the cached part ends with a prompt_cache_breakpoint, and a breakpoint can carry its own ttl. That lets you keep a stable reference block for 12 hours while the rest uses the 30-minute default:

{
  "model": "gpt-6.1-sol",
  "prompt_cache_options": { "mode": "explicit", "ttl": "30m" },
  "input": [
    {
      "role": "developer",
      "content": [
        {
          "type": "input_text",
          "text": "<the product policy, 20,000 tokens>",
          "prompt_cache_breakpoint": { "mode": "explicit", "ttl": "12h" }
        }
      ]
    },
    { "role": "user", "content": "Can I return an opened item after 40 days?" }
  ]
}

The prefix must be at least 1,024 tokens to be cached. OpenAI says the 12 hours is a minimum lifetime, not a deletion deadline, and its normal data retention policy still applies.

How to check it worked

Each response's usage.input_tokens_details says what happened:

• cache_write_tokens, split into ttl_30m_tokens and ttl_12h_tokens, counts what was written and at which price.
• cached_tokens counts what was read at the cheap rate.

The first request of the day should show the prefix under ttl_12h_tokens. Requests after it, even hours later, should show it under cached_tokens and write nothing. If they keep writing, something at the start of the prompt changes between requests.

OpenAI's 12-hour cache and Claude's 1-hour cache

Anthropic's Claude has the same 2-tier idea with shorter lifetimes: a 5-minute default that writes at 1.25x and a 1-hour option that writes at 2x, with reads at 0.1x, or 0.05x on Claude Opus 5.5 and Sonnet 5.5. The reasoning carries over. The longer cache pays when requests are further apart than the short lifetime but close enough to share a write. Our prompt caching calculator runs that sum for each Claude model, and prompt caching vs KV caching explains what is actually being stored. If the cache never hits at all, why prompt caching is not working goes through the causes in order.