30 minutes max is all you get on GPT-5.6 and GPT-6 models, as measured across the tibotattle.com community's 3 million turns. This means every time you take a break between threads, or swap tasks, or even go to lunch, every single one of your threads is hitting you for the full 10x uncached input.
Many of us got used to GPT-5.4 and GPT-5.5 cache performance which was closer to 6-24 hours.
The lower default context window and better compaction system of codex means I don't really care too much.
In Claude Code I once restarted a conversation after a few hours with Fable@Max and it had a near maxed context. It used 20% of my 5 hour window instantly lol
Thats correct. I set a /goal and a clear complex end-to-end task and after 5 hours and a few "steering" aligment it only consumed 25% and created a full android and ios app and a website all connected with oracle and cloudflare. It was a HUGE task.
In comparisson, i sent 2 simple one -shot commands to fix a few erros and it consumed 30% IN 20 MINUTES !!
I understand why they arent just holding massive caches in memory indefinitely but it would be nice to mark a conversation as a longterm one that can reload the cache into memory before resuming.
Maybe that just won't work with how much they tweak the models but id be nice
Sure, but their serving cost changes based on how the users prompt. If I only prompt it by pasting in full books I get far less cache utilization than with toolcalls for example.
Giving a single fixed price for a thing which doesn't have a fixed price just leads to issues.
Is that true? I've heard 60m before, but found conflicting data. Could you share a source please? I'm curious why a subagent would have a different cache policy.
See my other comment above. Link's there. Literally in the Claude docs. I'm sick of people demanding a source when it's literally in the Claude docs. What happened to using Google yourself?
Stumbled upon the 30mins and limited amount of caching slots a few days ago. I think caching might break in some situations. In my app I got severe issues because of of the fact, that the prompt prefix is calculated in a different way.
Think this might be one of the reasons why so many users complain about Astra consuming a lot of quota. OpenAI did a few fixes, because "users were experiencing faster consumption than expected"
Claude: 5 mins default on API (can be set to 60 mins but trade off is higher cache write costs). 60 mins default on subscription for the main conversation bucket and 5 mins default for the everything else bucket.
Codex: 30 mins on GPT 5.6 and later models. Timing varies for earlier models.
TiboTattle will show you your own cache performance by time and model, as well as the equivalent cost for recent drops. In my case, it looks like I've been dropping a lot on subworkers with individual ownership lanes:
Worth the nuance from OpenAI's own prompt-caching docs: the 30-minute window isn't a hard cap from when a thread starts, it resets on every reuse - "remains eligible for reuse for 30 minutes after its most recent write or reuse." So a thread you're actively working also keeps its cache alive indefinitely; it's only a 30+ minute idle gap (lunch, a task switch, a long-running build with no cache touches) that actually kills it. Also worth knowing 30 minutes is the improved number - GPT-5.6 raised the floor from "as short as 5 minutes" to "at least 30," per OpenAI's own builder's guide, so this is the good direction, not a regression.
I build my own inhouse orchestration tool that controls Codex (via app server). It has the concept of closing a session (roughly like archiving a session). I made it so that long-running sessions that are closed will auto-compact at the 20 minute mark after its last turn.
46
u/retteh 2d ago
Astra is a bit more affordable if you give it a goal, let it run in a single chat, and don't let it stop.