OpenAI adds 12 hour prompt caching with a higher write price
OpenAI added a 12 hour prompt caching option to its Responses API on October 20, allowing applications to reuse shared context across requests separated by hours. The release announcement covers instructions, tools and other repeated context. The tradeoff is a higher initial write charge, not a blanket reduction in every request’s cost.
Longer retention costs more upfront
For GPT 5.6 and later supported models, developers can set prompt_cache_options.ttl to "12h". The default remains "30m". OpenAI’s caching guide sets the write rates at 2.5 times ordinary input pricing for 12 hours and 1.25 times for 30 minutes. These are total write prices, not additional surcharges. Reads cost the same under either lifetime.
A request can also mix lifetimes through explicit breakpoints. For example, a stable reference document can receive longer coverage while short lived session context keeps the default. Extending existing 30 minute coverage to 12 hours incurs a new long duration write without credit for the earlier write.
A small calculation shows when it pays
The standard short context price table lists GPT 6.1 Sol at $2 per million uncached input tokens, $2.50 for a 30 minute write, $5 for a 12 hour write and $0.10 for a cached read.
Consider a hypothetical, unchanged 10,000 token prefix used three times within 12 hours. Assume each gap outlasts the shorter cache’s actual coverage, while the longer cache produces two valid reads. Three short writes would cost $0.075. One long write plus two reads would cost $0.052. With only two uses, however, short writes cost $0.050 versus $0.051 for the long write and one read.
Those figures cover only that prefix, excluding output, tools, new input and any other charges. They are arithmetic from the published rates, not measurements. If shorter coverage survives the gaps, its reuse can make the shorter option cheaper. The useful question is how often the application actually rewrites the same material.
A lifetime setting cannot repair a changed prompt
OpenAI’s diagnostics documentation says reuse requires an exact prefix match and compatible settings. Switching the model or service tier, altering tools, or editing earlier input can prevent an expected hit. Longer retention does not correct those changes.
Developers can compare a request with a recent completed response by setting prompt_cache_options.comparison_response_id. The resulting prompt_cache_diagnostics can identify a mismatch, while usage.input_tokens_details.cached_tokens reports actual reuse. The comparison does not load the earlier conversation or change cache behavior.
A useful rollout check is to compare cached tokens, written tokens and total cost over representative requests. Diagnostics are best effort. An unavailable result is not proof of a hit or a miss.
Twelve hours is not a deletion deadline
The lifetime rule establishes a minimum for cache read pricing. OpenAI may retain entries longer, and the setting does not replace its maximum data retention policy. Nor does it guarantee lower latency on every request. Applications handling sensitive material should distinguish a billing lifetime from a deletion commitment.
Related coverage explains OpenAI service tier restrictions for API projects. Those access controls are separate from the cache lifetime setting.
Illustrative photograph by Simon Hattinga Verschure via Wikimedia Commons. Public domain under CC0. This is not a photograph of an OpenAI product interface.
