OpenAI 12-hour prompt cache pricing

If your agent sends the same instructions, tool definitions and reference material all day, the default 30-minute prompt cache often expires between calls, and every refresh is billed at the write price. OpenAI’s Responses API now offers a 12-hour option for GPT-5.6 and later models. Prompt caching stores the unchanged start of a request, so a later call with the same opening can reuse it at the cached-input rate. OpenAI’s October 20 changelog puts a 12-hour write at 2.5× the standard input price, against 1.25× for the 30-minute default. Reads cost the same under either lifetime.

Key points

New option: The Responses API accepts prompt_cache_options.ttl set to "12h", alongside the default "30m". The caching guide says the option applies to GPT-5.6 and later models.
Prices: A 30-minute write costs 1.25× standard input and a 12-hour write costs 2.5×. Reads cost 0.1× on most models and 0.05× on GPT-6.1 Sol, whichever lifetime you choose.
GPT-6.1 Sol numbers: The Standard tab of OpenAI’s pricing page lists $2.00 per million input tokens, $0.10 cached, $2.50 for a 30-minute write and $5.00 for a 12-hour write.

Background

Prompt caching is not new. What changed is how long an entry can live. OpenAI’s changelog records extended retention, up to 24 hours, on November 13, 2025. The guide sets that through prompt_cache_retention, which applies to GPT-5.5 and earlier models. GPT-5.6 brought explicit prompt-caching controls on July 9, 2026, and Prompt Cache Diagnostics became generally available in the Responses API on September 8.

GPT-6.1 Sol is the model behind the prices above. The example in OpenAI’s launch post is a persistent agent, dots, which we covered earlier.

The facts

The table comes from the GPT-6.1 Sol row in the Standard tab of OpenAI’s pricing page. The page has a short- and long-context switch; we did not check the long-context numbers.

Item	30 minutes (default)	12 hours (new)
Write, relative to standard input	1.25×	2.5×
GPT-6.1 Sol write, per million tokens	$2.50	$5.00
Read, per million tokens (same for both)	$0.10	$0.10

A few rules in the guide decide what a request actually costs:

Lifetimes can be mixed. The request-level ttl applies to the implicit breakpoint and to explicit breakpoints without their own setting. A single breakpoint can override it with prompt_cache_breakpoint.ttl. Within one request, each token is billed once, at the longest lifetime among the writes that cover it.
Upgrades pay again. Turning valid 30-minute coverage into 12 hours charges a new 12-hour write for those tokens, with no credit for the earlier write.
Reads extend the short window. A 30-minute read pushes coverage to at least 30 minutes after the read. An entry already covered by 12 hours keeps its later expiry and is not charged another write.
The minimum is not a guarantee. The guide says cache entries “are not stored indefinitely” and that “12h” “does not set a deletion deadline.” The minimum lifetime decides whether a request gets the cached-read price. It does not promise that every request reuses the stored state, or that latency drops.
Routing matters. Cache state lives on individual machines. Traffic above 15 requests per minute can cause overflow routing, and a request reuses a prefix only if it reaches a machine that holds an unexpired match.
Scope is narrower than the price list. The guide documents the 12-hour option only for the Responses API. The pricing page’s Flex/Batch tab also lists a 12-hour write price for GPT-6.1 Sol ($2.50), but the guide does not say how Batch lifetimes are set.

Break-even math

Using the Standard numbers, here is what one cached prefix costs across several calls. We assume consecutive calls are more than 30 minutes apart, all within 12 hours of the first write, and each call carries the whole prefix. Figures are dollars per million prefix tokens, our arithmetic:

Calls	30-minute lifetime	12-hour lifetime
1	$2.50	$5.00
2	$5.00	$5.10
3	$7.50	$5.20
6	$15.00	$5.50
12	$30.00	$6.10

At two calls the 12-hour option costs $0.10 more, which is roughly even. From the third call it is cheaper. At twelve calls it costs about a fifth of the 30-minute option.

Two caveats apply. If calls arrive less than 30 minutes apart, the 30-minute window keeps refreshing, and the 12-hour write is extra cost with no gain. And the table counts only the prefix. In explicit mode, content after the last breakpoint is billed at the standard input rate with no write charge.

DenDen’s analysis on note.com reaches the same conclusion: roughly even at two calls, cheaper from three. DenDen’s example reads at 0.1× rather than GPT-6.1 Sol’s 0.05×, so these figures (15 against 3.6 at twelve calls, with standard input as 1) do not carry over. The table above does.

What others say

OpenAI’s launch post frames the option around persistent agents: “Persistent agents, like dots, reuse context throughout the day.” It adds that shared instructions and tools can stay cached “even when requests are hours apart.” That is a use case, not a hit-rate claim.

Tibo (@thsottiaux) went further in a “Day 16” post on October 21 at 01:10 UTC. The post says that for logged-in users of Codex and Work the cache is kept forever, returning to an old conversation carries no penalty, and users are “guaranteed to hit the cache.” That is a product claim about Codex and Work, not an API term. PANews’s English headline, “Retained Permanently,” paraphrases the same post. The API guide is narrower: entries are not stored indefinitely, and nothing in it promises a hit. The two cover different things, so keep them apart.

AI Weekly’s write-up, by Alexis Dufresne, quotes the same changelog, guide and price figures. Its editor’s note reduces the break-even question to one thing: how often each cached block gets reused before the 30-minute window expires. DenDen adds a point worth keeping in mind. Cached input tokens still count toward tokens-per-minute limits, so the 12-hour option lowers the price per token but does not raise the rate limit. The guide says the same.

In the sources we could reach, we found no independent hit-rate measurements, latency figures or critical analysis. A Hacker News search for “prompt caching” over the past week returned no discussion of this change.

Our take

This fits long-running agents that send the same long instructions, tool definitions or reference material many times a day, with hours between calls. OpenAI’s example, the persistent agent dots, has that shape. Scheduled batch jobs that run every few hours do too.

It does not pay off in three cases: dense traffic with gaps under 30 minutes, where the default window already does the job; prompts whose prefix changes on every call; and workloads that call the model once or twice.

Watch the write bill. A 12-hour write costs twice a 30-minute write, and that premium pays back only if the prefix is reused enough times. This is a tool for stable prefixes with long gaps. It is not a general “caching is cheaper” story.

Two things the guide leaves open: the Chat Completions and Batch parameters, and whether organizations with Zero Data Retention can use the 12-hour lifetime. Check both before you build on them.

How to try it

Confirm the model is GPT-5.6 or later (for example gpt-6.1-sol) and that you call the Responses API.
Put the stable material (instructions, tool definitions, reference documents) at the start of the request. The cached prefix needs at least 1,024 tokens.
Set the 12-hour breakpoint at the end of the stable block. The JSON below is a shortened version of the guide’s example. Replace the placeholders with your own content.

{
  "model": "gpt-6.1-sol",
  "prompt_cache_options": { "mode": "explicit", "ttl": "30m" },
  "input": [
    {
      "role": "developer",
      "content": [
        {
          "type": "input_text",
          "text": "...stable instructions and reference material...",
          "prompt_cache_breakpoint": { "mode": "explicit", "ttl": "12h" }
        }
      ]
    },
    {
      "role": "user",
      "content": [
        { "type": "input_text", "text": "...the current question..." }
      ]
    }
  ]
}

In the response, read usage.input_tokens_details.cache_write_tokens_details. It splits writes into ttl_30m_tokens and ttl_12h_tokens, and the two sum to cache_write_tokens. If ttl_12h_tokens is zero, that write did not use the 12-hour lifetime.
To check the bill, follow the guide’s formula: ordinary input tokens at the input price, cached reads at the read price, ttl_30m_tokens at 1.25× input, ttl_12h_tokens at 2.5× input, summed and divided by 1,000,000.