OpenAI Extends Prompt Caching to 12 Hours for Long-Running Agents

OpenAI has added a 12-hour time-to-live option to its prompt caching guide, extending the previous 30-minute default. Supported agents can now reuse stable system instructions, tool definitions, and reference context across requests made hours apart while paying the discounted cached-input rate.

The change targets agents that remain active throughout a workday but receive sporadic user events, scheduled jobs, or tool callbacks. Developers can set prompt_cache_options.ttl to "12h", retain the "30m" default, or use explicit cache breakpoints to combine both retention windows in one request.

A cache window built for idle agents

Under the previous behavior, a cached prefix remained eligible for reuse for 30 minutes after its latest write or read. OpenAI could retain the entry longer, but applications could not rely on a hit after that window. Agents that paused for several hours therefore had to process large, unchanged prefixes again at the standard input-token rate.

The 12-hour option keeps those prefixes available across longer gaps. OpenAI identifies Dots, its persistent-agent product, as one example: the agent retains the same instructions, tools, and shared context while handling requests throughout the day.

The reuse math

For GPT-5.6 and later, OpenAI prices a cache write at 1.25 times the standard input-token rate. Cached reads cost 0.1 times that rate on most supported models and 0.05 times on GPT-6.1 Sol. The public guide does not list an additional multiplier specific to the 12-hour tier.

Assuming the full prefix matches on every request, the first cached reuse offsets the higher write price. The following totals express cost relative to processing the prefix once at the standard input rate:

Higher reuse counts increase the savings, provided the cached prefix remains identical and requests arrive before its TTL expires.

One request, multiple cache clocks

Explicit caching supports multiple breakpoints within a request, allowing prefixes that change at different rates to expire independently. A cache breakpoint identifies the end of a reusable prefix, and each request can create up to four cache writes.

Workloads that gain the most

Workloads with large, stable prefixes and idle periods longer than 30 minutes have the clearest cost advantage. Common examples include:

• Scheduled agents that wake every hour
• Support assistants with long gaps between messages
• Evaluation harnesses that reuse a fixed rubric
• Background workers with large tool manifests
• Persistent agents that share reference material across tasks

Bursty conversations that already keep the 30-minute cache warm receive little additional benefit from the longer TTL. Prompts also need a cacheable prefix of at least 1,024 visible input tokens on GPT-5.6 and later; shorter prefixes bypass the cache regardless of the selected retention period.

Enable the TTL and verify the hits

Enabling the longer window requires one request field. This explicit-mode example sets a 12-hour TTL and places a breakpoint after the stable developer content:

{
  "model": "gpt-6.1-sol",
  "prompt_cache_options": {
    "mode": "explicit",
    "ttl": "12h"
  },
  "input": [
    {
      "role": "developer",
      "content": [
        {
          "type": "input_text",
          "text": "Stable instructions and shared reference material...",
          "prompt_cache_breakpoint": {
            "mode": "explicit"
          }
        }
      ]
    },
    {
      "role": "user",
      "content": "The user's current question..."
    }
  ]
}

The response reports cache activity through usage.input_tokens_details.cached_tokens and cache_write_tokens. Teams can also use the Prompt Caching Dashboard to track hit rates and compare cache costs with an uncached baseline.

Cache reuse still requires an exact match for the entire rendered prefix. Changes to system text, tool definitions, reasoning effort, structured-output schemas, or content ordering create a different prefix and prevent a hit. Stable content should therefore appear first, with frequently changing conversation turns placed after the final long-lived breakpoint.

Teams evaluating the feature should measure write volume, cached-token volume, hit rate, and the time between requests. Those figures show whether the 12-hour window reduces repeated input processing enough to justify its higher write cost.