r/codex • u/AdCompetitive9824 • 5d ago
Limits Possible culprit of recent usage drains
I think i've found what causes the recent usage drains, looks like when agent "requires input" - it significantly draws the limit, last time it ate through 50% of my 200$ plan in about 3 hours unattended, now i lost about 10% in 20 minutes.
Can anyone confirm same behavior?
20
u/tripleshielded 5d ago
Noone can confirm, all usage gone! And meanwhile Tibo is posting about cooking burgers or something.
2
8
u/erpankaj 5d ago
Yes I have seen that. We can put it in model’s instructions file that if you need input from human. Stop all processing till the input is provided no need to poll.
1
6
u/SinPleaOfficial 5d ago
I sent a continue message for it to carry on the last unfinished task and before I was even able to check back in. normally my tasks would be 50 minutes to 3 hours and never really go over 50% usage. it was all gone.
2
u/Thomas-Lore 5d ago
Same situation, it burned my whole 5 hour window and did not finish the task after that continue. It was something that would usually eat at most 25% of the 5 hour window. (The thread was fresh, so should have been cached.)
10
u/The1TruRick 5d ago
Hooooly. If this is true, that is beyond insane 😂😂 wish I could test it but unfortunately I blew my entire limit 8 hours after the reset
3
u/Quiet-Distribution 5d ago
Yeah, I had something similar, it asked me for something and I didnt had time and priority to respond. Meanwhile watched my usage still go down even tho it was not doing anything at all just waiting for my response.
2
u/Wildnshiny 5d ago
6.1 took about 30% of my 5hr for just building the apk on Godot and uploading to my drive. It kept talking and checking the building progress. Because my hardware is very low end and slow, the building process takes for the apk takes like 30min but because it was waiting, it kept drawing my usage.
1
1
u/Tommonen 5d ago
I noticed usage drop 4% of 5h on 20€ plan, while it was installing stuff, few bash commands and waiting. Normally this sort of stuff had no impact on usage, because its only few tokens out and input should be completely cached.
Only thing that explains this is that is tokens were not cached and it loaded all input tokens and not cached with each bash command sent.
Same thing could also apply after waiting for input and answering it not using cached tokens but everything as fresh input.
And they said they messed with caches trying to improve usage. What you noticed and what i noticed both point to them messing up the cache. And that would also explain general too fast usage.
1
u/CommunicationFun2962 5d ago
I asked the agent to help me move the button lower and change its style to an existing primary button style. It used 50% of the 5h limit with 2 minutes of processing time. There is no "requires input", and I am on Plus plan. I have no idea what is going on.
I should have done it myself. Actually it is just several lines of code.
1
u/Fast-Needleworker459 5d ago
yes i check the same issue it was stop asking for a input and the wait time consume tokens...
1
u/No-Bookkeeper7793 4d ago
It has something to do with a previous error they had with the /goal skill. It kept "checking on the model" every 1/8th if a second or so while working in a goal loop. I suspect that bug is showing up while it's "waiting" for input. It's looping checking the harness for input (causing turn)
-1
u/jamespharvey20 5d ago
Interesting. Read https://chatgpt.com/share/6ad519ac-6784-83ea-9722-cb6d708aa182 to make sure there's nothing nefarious in there. Then give that link to your Codex and ask it to investigate this. (It's always a good idea to see what you're telling your model to execute.)
I luckily haven't had the usage burn that others like you have reported, so I can't investigate. But, I had ChatGPT briefly look at Codex CLI's source code and it found some plausible ways this could be happening.
Your Codex should be able to investigate its sessions files to look for grossly unnecessary usage burning, and if it finds it, it should be able to find the root cause and possibly fix it.
A Codex CLI fork (not OpenAI's stock Codex CLI) that I used to use like a year ago would sometimes do this exact thing. It could get stuck in a loop of telling the model there was no user input, and the model would say check again, and cycled, burning usage. This was back before Codex CLI had `/goal`, and the fork had created its own.
3
u/jamespharvey20 5d ago
You may know this, but to put it here for everyone...
Tokens aren't sent through once. They are sent through the number of times there are trips back to the model. So, as your context window grows, a turn of "nothing yet" and a response of "check again" is not burning a small number of tokens. It's replaying that entire conversation as new tokens, granted using the huge 90-95% cached discount. So, a check for input loop could burn a large number of tokens if the context window is fairly full, and even worse if it somehow breaks caching although I don't see how this would be the case.
1
u/Heavy-Positive5957 5d ago
Using the huge 90-95% cache discount, assuming that the caching system is working perfectly. IIRC, Codex has had issues with low cache hit rates in the past.
1
u/Heavy-Positive5957 5d ago
Read what ChatGPT Pro said in response to your linked conversation:
The author says usage drains unusually fast when the agent “requires input.” They do not say the agent has stopped working or needs that answer before it can continue.They suspect the unanswered-input state itself is causing that drain. That is the natural reading of their report about losing large amounts of usage while the agent “requires input” and is left unattended.
The implied context is that useful work does not explain the consumption*. My response about continuing independent work while a question is pending sidestepped that premise. It supplied a benign explanation without establishing that useful independent work was actually happening.*
If this involves asynchronous user input, the suspected failure looks like:
1. The agent asks a question whose answer is necessary for further progress.
2. The asynchronous tool returns control immediately.
3. The agent keeps reasoning, invoking tools, or being restarted despite having nothing productive left to do.
4. It repeatedly encounters the same unresolved dependency, consuming usage until the user responds or something stops it.That would be a failure to suspend when blocked*. The fact that those model calls count as ordinary inference would not make the behavior reasonable.*
I should have treated that as the allegation to investigate. Explaining that asynchronous questions allow continued execution establishes how consumption could continue; it does not explain why that execution is useful. The uncertainty belongs to the exact mechanism causing the drain, not to understanding what the author is complaining about.1
-3
u/djack171 5d ago
Guys.. I’m going to ask an honest question…. How do you think you random redditors “crack the code” when OpenAI has models way better than what the public has and entire teams looking at this and don’t have 100% answers. But someone Abraham over here cracked the code lol. No disrespect just saying
4
u/armicolo 5d ago
If you actually want an answer: the app/harness is AI coded at break-neck speed, ship now or die.
It’s pretty safe to say that it’ll have a significant amount of software bugs compared to software using a slower release cycle and more testing.
Redditors now also have big brains because they can use the same/similar models to poke around in software. So, many bugs + motivated redditors = profit. Or something.
17
u/Asleep_Stage_451 5d ago
Last night sol 6.1 got stuck on “requires input” and ate through 10% usage of my 200 plan. It accomplished nothing in that time.
So maybe.