Who on earth came up with 5 hour limits?
The day is 24 hours long.
While do our limit times shift by an hour each day.
Pls if you are going to have limits 4 or 6 hours.
Codex might be seriously broken right now.
Yup, Codex rant part 3
GPT-5.6 Sol is burning through quota at a completely stupid rate and everyone notices it.
Here’s my usage graph:
Jun 23, GPT-5.5 xhigh: 327.8M tokens
Jul 2, GPT-5.5 xhigh: 549.9M
Jul 20, GPT-5.6 Sol High: 3.3B
I had a bunch of resets, sure, and several tasks were running. That let me burn more.
It doesn’t explain how 5.6 chewed through 3.3B tokens in one day. I genuinely don’t know what the fuck I would’ve had to do to get 5.5 anywhere near that.
And apparently it’s not just me.
@theo already covered 3 different ways GPT-5.6 was nuking usage. Looks like there might be a fourth.
5.6 uses the new Code Mode tool path. It can batch independent tool calls with Promise.all, but it barely ever does. Instead, it keeps running them one by one.
That means another model cycle for every call, dragging the giant context along with it every single time.
One trace found Promise.all in only 5 of 739 GPT-5.6 exec cells:
https://t.co/IQ6gqGWhSK
My own retained logs show the same shape. After removing fork-history replay, the 5.6 peak had 23,791 model requests. My clean 5.5 baseline had 3,803.
That’s 6.26x more requests, while tokens per request were actually slightly lower.
It wasn’t writing much bigger responses. It was just going back to the model over and over and over again.
Then someone tested explicit batching across two unrelated codebases. In the repeated High/XHigh runs, it cut model cycles by ~52–55% and weighted usage by 27–45%:
https://t.co/FGvWZqE4Xm
I’m not saying this one thing explains every token I burned. Several tasks were active, my local rollout logs aren’t the billing ledger, and we still don’t know how much of the spike came from agents themselves.
But both issues are still open, and this looks pretty fucking real.
For now, I’m testing explicit batching guidance. I’m also avoiding the built-in subagent/fork workflow for long-running work and moving bounded jobs into fresh disposable Codex tasks instead.
Self-contained prompt, fire and forget, inspect the result in the main task, archive it. Less context coupling, and each job is actually measurable.
I hope other people can validate it, too.
@thsottiaux@reach_vb@OpenAIDevs if it's true, it should be addressed. Cuz it might be THE cause.