OpenAINews

· Intermediate

Illustration: an hourglass with rounded glass bulbs, most of the sand still in the top bulb and a thin stream falling, drawn in grey on black.
Illustration

OpenAI API adds 12-hour prompt caching for context reused all day

Agents that come back to the same instructions hours later can now keep the cached rate. Writes cost more, so do the math first.

If your agent or app reuses the same instructions, tools or reference files through the day, you can now ask the OpenAI API to keep that prefix cached for at least 12 hours instead of 30 minutes, so requests hours apart still pay the cached-input rate.

What changed#

Before, GPT-5.6 and later cached for a 30-minute minimum, still the default. On Oct 20 OpenAI's changelog added: "You can now choose 12-hour prompt caching in the API." The docs say it works in the Responses API. A 12-hour write costs "2.5× the uncached input-token rate," against 1.25× for 30 minutes, and "Cache-read rates are the same for both lifetimes": 0.1× on most models, 0.05× on GPT-6.1 Sol. For GPT-6.1 Sol at standard speed, the 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.

@OpenAIDevs posted: "Persistent agents, like dots, reuse context throughout the day."

Why it matters#

Our read, using the docs' rates: send the same prefix every two hours for 12 hours, six requests. If each 30-minute entry has expired, six writes at 1.25× cost 7.5 times the prefix's normal input price. One 12-hour write and five reads cost 2.5 + 0.5 = 3 times. No caching costs 6 times. OpenAI may keep entries longer than the minimum, so 7.5 is the worst case. For context reused every few minutes, stay on 30 minutes.

How to use it#

These steps follow OpenAI's prompt caching docs.

  1. In the Responses API, set prompt_cache_options.ttl to "12h", or keep the "30m" default.
  2. To mix lifetimes, put material reused all day first and give its prompt_cache_breakpoint a ttl of "12h".
  3. Keep fast-changing session context on "30m", and put the current question after the last breakpoint so it isn't billed as a write.
  4. In the response usage, check input_tokens_details.cache_write_tokens_details, which splits writes into ttl_30m_tokens and ttl_12h_tokens.

OpenAI's docs example (official, trimmed to the 12-hour part):

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

Good to know#

  • 12 hours is a minimum for cache-read pricing. The docs say it "does not guarantee that every request reuses stored KV tensors or has lower latency."
  • Upgrading a 30-minute entry to 12 hours "charges a new 12-hour write for those tokens, without credit for the earlier write," per the docs.
  • Each prefix must meet the minimum cacheable length, 1,024 tokens on GPT-5.6 and later. Older models keep the separate prompt_cache_retention parameter.
  • Tibo Sottiaux, whose X bio reads "Codex & ChatGPT @OpenAI," posted that "for logged in users across Codex & Work we keep cache forever." The docs cover only the API.
  • Watch next: whether the changelog adds 12-hour lifetimes outside the Responses API.

Sources

  1. developers.openai.com
  2. developers.openai.com
  3. developers.openai.com
  4. x.com
  5. x.com
  6. x.com

Something wrong? Tell the bot