Entire 5-Hour + 22% Weekly Limits + All Credits Burned Without Running
What version of Codex CLI is running?
codex-cli 0.99.0
What subscription do you have?
Pro
Which model were you using?
gpt-5.3-codex
What platform is your computer?
Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 x86_64
What terminal emulator and version are you using (if applicable)?
ZSH Windows Terminal (WSL)
What issue are you seeing?
I just updated to the latest version of codex cli/tui about an hour and a half ago, and it seemed to be going great for a while. However, I was just finishing up with some manual tasks in my IDE and then went to start up a new codex TUI session, and my usage limits had been 100% drained for my 5 hour limit (I've never even gotten close with my Pro sub), the 139.905 credits I had were all burned through, and my weekly limits went from 67% at the end of my last session, to now down to 45% weekly, without having had codex running even. I was worried I was hacked or something, but double checked what I could and have MFA and passkeys set to login to my account, and looks like that was not the case.
My best guess is that I had just recently, after upgrading to codex-cli 0.99.0, enabled the experimental features for memory_tool and search_tool, which could potentially be the issue.
What steps can reproduce the bug?
Setting the following from config.toml and starting a new session running codex-cli 0.99.0 from the tui.
[features]
apply_patch_freeform = true
unified_exec = true
shell_snapshot = true
steer = true
sqlite = true
apps = true
collab = true
memory_tool = true
search_tool = trueWhat is the expected behavior?
Drain 5-hour usage limits and any available credits completely without running a prompt/
Additional information
Would be awesome to get the credits and weekly limit reset back to what they were prior to this.
19 Comments
Same
Please fix this ASAP, I can't work without codex 👼🏻
<img width="1268" height="421" alt="Image" src="https://github.com/user-attachments/assets/55ade041-db10-4bdb-8dc2-ac34518a0d35" />
@BjornMelin, you mentioned that the credits were consumed "without running", but in your description you mentioned that you were running a task recently in the TUI. Is it possible that the session you were running consumed all of the remaining usage and credits? I notice that you have the
collabexperimental feature enabled. That can drain limits quickly if the session spins up a bunch of subagents.@aurexav, can you provide more details, similar to what @BjornMelin posted? Are you using any experimental features?
After a 5h limit checkpoint reach, a chat would reset it.
I used these
---
I’m not sure how to reproduce this but it occurs after upgrading to 0.99.
Before the upgrade I was simply coding and it seems the upgrade broke it.
@etraut-openai No, it is not possible... sorry I didn't clarify that well. I meant that I had ran a session successfully (without this issue occurring) using
codex-cli 0.99.0without an issue earlier today. No tasks were running and I checked my limits in that session once it completed and they were at 67% for my weekly limit, and I still had 139.905 credits that I haven't touched since early January. I have collab enabled, but have instructions set so it will only trigger subagents when explicitly asked (haven't had a subagent triggered in ~1 week). My last session in the TUI had concluded, with my limits still at the earlier mentioned values, and then about an hour later, after reviewing/refactoring some things manually in Cursor, I tried to open a new TUI session, and was shown the same message as @aurexav posted above. 5-hour limit, credits, and 22% weekly limits drained without even having a TUI session, or IDE session running (checked IDE, TUI, session logs, codex web, and can't figure out why or how this happened).Adding to my last response, with double usage rates right now, and a pro subscription, the closest I've gotten, even with running 2-3 TUI sessions in parallel to the 5-hour limit, is about 60%. I feel like it'd be extremely challenging to drain the 5-hour limit to 0 by actually coding. @etraut-openai
I believe it’s a bug in the CLI or web version. The usage differs; on the website, it shows I have a lot of remaining time but in the CLI it shows zero.
@BjornMelin, are you also seeing a disconnect between the CLI and the web usage stats?
You both mentioned that you saw this shortly after upgrading to CLI 0.99. Could you try downgrading to 0.98 to see if there is maybe a regression in our client-side usage accounting logic?
<img width="1282" height="361" alt="Image" src="https://github.com/user-attachments/assets/7fd5aa0c-c810-4bc4-9f0e-957e0a75dc09" />
I'm noticing the same here, it happens when the memory tool is enabled. It consumed 1000 credits for me as well, plus used the full token utilization for the 5 hour window across 2 pro accounts. No sessions were running, just CLI running with memory tool enabled.
I think the memory summarization agent is going a little too hard on generating memory and using all available tokens.
To test, I've just let an empty terminal with gpt 5.1 codex mini open and in ~10 minutes it used 2% of the tokens available in my 5 hour window. No sessions were run across any surface. It seems like it's the memory tool.
Thanks for making that connection, @mweinbach.
The
memory_toolis still under active development. Not recommended for use at this point. Please do not enable it.There’s a big difference between under development and knowingly buggy to the point that it makes users lose money (reaching the limit = money spent). Telling the users to not enable a feature that is available to be enabled is senseless. If it’s not ready for user testing it can’t exist.
I had it on too, (read your answer to late Eric) and yep, it consumes usage limit like crazy. Took around 27% of my weekly limit on pro plan.
(if you guys tried to fix this with a recent commit, like i saw jif adding something that it does drop CoT, it didn't help, since i used the alpha that came out after the commits, alpha 9).
Anyway, turned it off now until it is stable. 😅
@thehumanworks, we do our development in the open, but that means there will be code in the repo for features that are not yet ready for use. We clearly mark these features as "under development" and provide a prominent warning in the TUI if you attempt to enable one of these features. If you ignore this warning, then you're taking on the risks associated with using a feature that is not yet ready.
I checked with the developer who is working on this feature. The behavior you're seeing here is not a bug. It intentionally consumes a lot of tokens right now because we're tuning the backend models for this feature.
@etraut-openai Sounds like a great opportunity for a TUI warning flash that makes some one click yes or no for accepting risks of significant token loss, should be global in all such cases. The tolerance for experimental bugs that crash or do weird stuff is exponential orders of magnitude higher than ones that may empty your token bank account. It needs to be called out in a "do you accept the risk" type opt-in manner for the latter and future features and functions need to be audited and scored for this potential.
I don't want to be spiteful here, and I think it's important I first add that I admire and absolutely appreciate and adore the work you guys do. So thank you first and foremost. - but you will agree that "under development" means there is instability and things to polish, there's a difference between "this is beta/alpha" and "this is just sand but it will be a sandcastle".
The main issue with the feature is that I actually have 0 visibility of how many tokens it consumes. It doesn't show as "cli" or "exec" or "other" in my usage dashboard. It doesn't even show in the performance metrics and usage reports that I have switched on. That's the main problem.
It's ok if an under development feature feels a bit like a toy gun that shoots more toy bullets than I initially thought. It's more of a problem if the bullets are invisible.
Can you add an explicit warning in the "features list" section that this tool may lead to high token usage?
There is a warning notification for unstable features. But a "it's unstable and may consume tokens insanely fast" is a great way for me to know if I'm feeling "bungee-jumping level adventurous" or just "I'll go out without a jacket" adventurous
is this a one time activity to build up a memory? does the memory tool and sql lite instance per project? can they be check-into git with the codebase so team members can also use it? thx
I built a really nice mem tool. But it requires some setup.
https://github.com/hack-ink/ELF
@etraut-openai thanks for all the follow up here! Sorry I was out over the holiday weekend and never followed up. I'll just proceed with your recommendation and wait for stable
memory_toolrelease.