You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Codex CLI burns subscription tokens when only checking /status repeatedly #22040
What version of the Codex App are you using (From “About Codex” dialog)?
codex-cli 0.130.0
What subscription do you have?
Plus
What platform is your computer?
Linux 6.8.0-111-generic x86_64 x86_64
What issue are you seeing?
What happened:
Codex CLI appears to deplete usage limits even when no real work is done.
I checked /status a few consecutive times and saw my 5h limit drop significantly.
Example:
3 consecutive /status checks
about 12% of my 5h limit gone
no coding task, no file changes, no tool work
Environment:
Codex CLI version: codex-cli 0.130.0
OS: Linux 6.8.0-111-generic x86_64 x86_64
Plan/subscription: Plus
Model: gpt-5.5
Install method: npm
Notes:
I also burned through my weekly limit in four ~5h sessions, so I’m trying to understand if idle/status usage is being counted unexpectedly.
What steps can reproduce the bug?
Start Codex CLI
Run /status
Run /status again
Run /status again
Observe usage limit decrease
What is the expected behavior?
Checking /status should not consume meaningful usage, or at least the usage cost should be clearly explained.
Additional information
I burned through my weekly limit in four ~5h sessions, so I’m trying to understand if idle/status usage is being counted unexpectedly.
Additional Datapoint:
no file edits, no shell commands, no task execution between those checks.
The potential duplicates possibly could be the same bug on codex side, but I described different steps to reproduce the bug. That's why from my point of view this is not a duplicate.
I think this may just be that the status data doesn't actually seem to load every time you run /status. I seem to have to run /status 3 times to see an update, but further runs of /status don't deplete rate limits.
That’s what i thought at first too. But it took me a while to realize this also happens while idling.
In the example above, i did nothing in codex for about 10 minutes before the first /status check, and nothing during the three consecutive /status executions either.
Yeah sure, we can speculate about stale status data, delayed billing sync, proxy caching, etc.
But that is exactly the problem from the user side: I have no way to ask someone to verify the actual usage events.
So i’m left trying to test and figure out the real cause myself.
This is a paid $20/month product, the limit is already very constrained, and the reported usage behavior is confusing. I would really appreciate an official way to check whether idle time or repeated /status calls are counted against the limit.
Activity
github-actions commentedon May 10, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
ofeist commentedon May 10, 2026
The potential duplicates possibly could be the same bug on codex side, but I described different steps to reproduce the bug. That's why from my point of view this is not a duplicate.
kendonB commentedon May 11, 2026
I think this may just be that the status data doesn't actually seem to load every time you run /status. I seem to have to run /status 3 times to see an update, but further runs of /status don't deplete rate limits.
ofeist commentedon May 11, 2026
That’s what i thought at first too. But it took me a while to realize this also happens while idling.
In the example above, i did nothing in codex for about 10 minutes before the first /status check, and nothing during the three consecutive /status executions either.
emercons commentedon May 12, 2026
10 minutes is a short span, their billing server could be down and so the proxy was sending some outdated status that was from 1 hour ago.
ofeist commentedon May 12, 2026
Yeah sure, we can speculate about stale status data, delayed billing sync, proxy caching, etc.
But that is exactly the problem from the user side: I have no way to ask someone to verify the actual usage events.
So i’m left trying to test and figure out the real cause myself.
This is a paid $20/month product, the limit is already very constrained, and the reported usage behavior is confusing. I would really appreciate an official way to check whether idle time or repeated /status calls are counted against the limit.
ofeist commentedon May 14, 2026
In the meantime, as said, I am convinced this is a bug and the /status command or idling alone burns the usage.