OpenAI's 12-Hour Prompt Cache Costs 2.5x to Write. Here's the Three-Request Break-Even for Your Agent.
OpenAI announced this week that you can choose 12-hour prompt caching in the API, pitched at persistent agents that reuse the same instructions and tools all day. The pitch is real. The price is also real: a cache write at the 12-hour setting costs 2.5 times the normal input rate, and the default 30-minute write already costs 1.25 times. If your agent calls the model a few times an hour, whether this saves you money comes down to counting requests.
What the docs actually say
On GPT-5.6 and later, you set prompt_cache_options.ttl to "12h" in the Responses API. The default is "30m". A cache read costs 0.1 times the ordinary input rate, or 0.05 times on GPT-6.1 Sol, and reads cost the same whichever lifetime you picked. There is no separate surcharge on top: the 2.5 times figure is the whole write price, and every input token is billed at one rate whether it was uncached, cached or written.
Two details are easy to miss. Upgrading existing 30-minute coverage to 12 hours triggers a fresh 12-hour write charge, with no credit for the earlier write. And 12 hours is a minimum, not a deletion deadline, so OpenAI may keep entries longer. The minimum prompt length is 1,024 visible input tokens, and hidden system content that OpenAI adds does not count toward it.
Older models work differently. On gpt-5.5, gpt-5.4, gpt-5.1 and the other listed earlier models, you set prompt_cache_retention to "24h", there is no extra write charge, and reads use the model's cached-input rate. Organizations without Zero Data Retention default to 24h there already.
The break-even math
Measure everything in units of "the shared prefix billed once at the normal input rate." Without caching, N requests cost N units. With a 12-hour write followed by N minus 1 reads, you pay 2.5 plus 0.1 times (N minus 1).
At two requests that is 2.6 against 2.0, so the cache loses. At three requests it is 2.7 against 3.0, so it wins, and every request after that widens the gap. Three requests inside the window is the break-even for a 12-hour cache, assuming every read hits.
Now compare it to the default. Say your agent wakes up once an hour, ten times a day, with a long shared prefix. The 30-minute cache expires between calls, so every call is a write: 10 times 1.25 is 12.5 units, which is 25% worse than not caching at all. The 12-hour cache costs 2.5 plus 9 times 0.1, or 3.4 units, about two thirds cheaper than no caching. On GPT-6.1 Sol, with 0.05 reads, it drops to about 2.95.
Flip the pattern and the result flips too. If the agent fires every ten minutes, a 30-minute cache is warm the whole time: 1.25 plus 0.9 is 2.15 units over ten calls, while the 12-hour version is 3.4. Dense traffic wants the cheap short write. The docs I read do not say whether a read extends an entry's lifetime, so I assumed it does not, which is the conservative case for the short cache.
Who this is for
It fits agents with a big stable prefix and sparse, irregular traffic: a support bot that gets a few tickets an hour, a daily research agent, a scheduled job that runs every hour or two. It does not fit chatty products where each user session already keeps the cache warm on the default setting.
What I'd actually do
Log your request gaps for a week before touching the setting. Take the time between consecutive calls that share a prefix, and sort them into under 30 minutes, 30 minutes to 12 hours, and over 12 hours. If most gaps fall in the middle bucket, switch that endpoint to 12 hours and watch the cached-token counts in the usage object. If most gaps are under 30 minutes, leave the default alone. If they are over 12 hours, caching is not your lever at all, and you should look at shortening the prefix instead.
If you are still on an older model, check your retention setting before anything else. Since 24 hours has no write surcharge there, the break-even is effectively one repeat request, and that may be a reason to pause before upgrading models purely for the new TTL.
Where this could be wrong
My math assumes every read hits. Cache hits depend on the prefix matching exactly, so a timestamp or user name near the top of your prompt will quietly turn a 0.1 times read into a 2.5 times write. Check that first, because it matters more than the TTL setting.
Author
Lukas
@lukcombinatorSources
Prompt caching, OpenAI API documentation OpenAI Developers announcement on X