OpenAI adds 12-hour prompt caching to the Responses API

What OpenAI changed

OpenAI now lets developers keep a cached prompt prefix alive for at least 12 hours instead of 30 minutes. The option appeared in the API changelog on 20 October 2026 as a feature of the Responses API, with a one-line pitch: keep shared instructions, tools and context cached longer to benefit from lower cached-input pricing, "even when requests are hours apart."

The catch is the write price. A 12-hour cache write costs 2.5 times the normal input-token price, double the 1.25 times OpenAI charges for the default 30-minute lifetime. Reading from the cache costs the same under either setting. In practice the feature is a bet you place up front: pay more once, and save on every request that would otherwise have found the cache already cold.

That makes it most interesting for the kind of software that has become common this year: agents that run on a schedule, background jobs that wake every hour or two, and assistants that sit idle between bursts of use but carry the same long system prompt and tool list every time.

How prompt caching works

When a model reads a prompt, it computes intermediate key-value states for every token. According to OpenAI's prompt caching guide, caching saves those states for a reusable prefix, the unchanged tokens at the start of a prompt, so a later request with the same beginning can skip that work. The cache stores the computed tensors, not the text itself, and only an exact match of the whole rendered prefix counts.

For GPT-5.6 and later models, a prefix must be at least 1,024 visible tokens long to be cached. OpenAI can place the cache breakpoint automatically at the end of the latest eligible message, or developers can switch to explicit mode and mark breakpoints themselves. Each request can create up to four cache writes, which lets an app cache layers that change at different speeds: fixed instructions, a document set, then the running conversation.

Caching is on by default for supported models. The savings come from the read price: cached input costs 0.1 times the normal rate on most current models and 0.05 times on GPT-6.1 Sol. The same idea underpins the KV-cache products AI Lookout has covered, such as Tensormesh's enterprise cache layer, but here it is built into OpenAI's billing.

The price of a longer cache

OpenAI's pricing page now lists two write columns for each current model. For GPT-6.1 Sol at short context, input is $2.00 per million tokens, a 30-minute write $2.50, a 12-hour write $5.00 and a cached read $0.10. GPT-6 Astra runs $10.00, $12.50, $25.00 and $1.00 on the same columns, and the small GPT-6 Luna $0.10, $0.125, $0.25 and $0.01. Long-context requests cost twice as much on each line.

OpenAI stresses that these are total rates rather than surcharges: a token billed as a cache write is not also billed as ordinary input. When one request contains both a 12-hour and a 30-minute breakpoint, each token is charged once, at the longest lifetime that covers it.

There are subtleties for teams already caching. Upgrading a prefix that has a valid 30-minute entry to 12 hours charges a fresh 12-hour write for those tokens, with no credit for the earlier write. A 30-minute read of a 12-hour entry keeps whichever expiry is later but does not restart the 12-hour clock, and it does not trigger another write.

When 12 hours pays off

The arithmetic is simple. A 12-hour write costs the same as two 30-minute writes, so it breaks even as soon as it saves one rewrite and comes out ahead from the second. If an app calls the model every few minutes, the cheaper 30-minute cache stays warm on its own and the longer lifetime is wasted money.

The gap shows up when calls are spread out. AI Lookout worked through one example from the list prices: a 50,000-token prefix sent six times, two hours apart, on GPT-6.1 Sol. With no caching that costs $0.60. With a 30-minute cache that has expired before every call, the app pays for six writes, $0.75, which is more than not caching at all. With a 12-hour cache it pays for one $0.25 write and five reads, about $0.28 in total.

That example is illustrative; real bills depend on whether requests actually hit the cache and on the rest of each prompt. The developer Azeem Hassni, in a write-up of the change, makes the same point: the old default "expires before the next call" for scheduled jobs and agents that run every few hours, while anything calling within 30 minutes should stay on the standard rate. Cost questions like this are why AI Lookout looked closely at how much a browser agent's cache saves earlier this month.

How to turn it on

In the Responses API, developers set prompt_cache_options.ttl to "12h" for a request, or override it on a single explicit breakpoint with prompt_cache_breakpoint.ttl. Leaving both unset keeps the 30-minute default, and an unsupported value returns a 400 error. OpenAI's own example sets 30 minutes for the request but 12 hours for the developer instructions at the top, so shared material stays warm all day while fast-changing session context uses the cheaper rate.

Explicit mode helps control cost. Anything after the last breakpoint, such as the user's current question, is billed as ordinary input with no write charge, so apps do not pay to cache text they will never reuse. The guide also tells developers to keep timestamps and user-specific details out of the shared prefix, append to conversations rather than rewriting them, and avoid changing tools or reasoning settings mid-stream, since any of those can break the match.

On GPT-5.6 and later, OpenAI routes requests to cached machines automatically, so prompt_cache_key is now optional and mainly useful for separate cache accounting per customer. That also helps prevent one user probing whether another user's content is cached. The 12-hour option is the latest in a run of API changes from OpenAI this month, which also brought the Decisions API beta.

Older models and data retention

The new setting applies only to GPT-5.6 and later models in the Responses API. Older models keep the separate prompt_cache_retention parameter, with values "in_memory", which typically lasts five to ten minutes of inactivity and up to an hour, and "24h", which typically holds entries for around 30 minutes and can keep them up to 24 hours. GPT-5.5 and GPT-5.5 Pro accept only "24h". Those older models do not charge a separate cache-write fee.

OpenAI notes that the minimum lifetime governs eligibility for cache-read pricing, not a guarantee that every request will reuse stored tensors or run faster. It may keep entries longer than requested, and "12h" does not set a deletion deadline or change the maximum data-retention policy. Caches are never shared across organisations or across regional processing boundaries. Teams still on the oldest models should also watch OpenAI's planned GPT-4o and GPT-4.1 API shutdown.

How it compares with Anthropic

Anthropic has offered a similar choice for some time. Its prompt caching documentation lists a five-minute default and a one-hour option, with one-hour cache writes priced at two times the base input rate. OpenAI's new tier is twelve times longer than Anthropic's longest documented lifetime, at a write premium of 2.5 times rather than two.

The two systems are not directly comparable on price, because base rates, read discounts and model quality differ. But the direction is the same: as agents run longer and less predictably, providers are selling cache lifetime as a separate knob, and developers have to model their own traffic to know which setting is cheaper.

Limits and open questions

OpenAI documents the 12-hour option for the Responses API only, so apps on other interfaces should not count on it. Cached states also live on individual machines, and OpenAI says traffic above about 15 requests per minute can lead to overflow routing to other machines, where a matching entry may not exist.

OpenAI has not published data on how often 12-hour entries actually survive to be read, or how much customers have saved in testing. The best check for now is OpenAI's prompt caching dashboard and cache diagnostics tool, which show real hit rates per project. For anyone running agents on a timer, a few days of those numbers will show whether the higher write price is worth it.