Repository navigation
Quota drained instantly: 100 credits gone after 1 message, 5h limit reset to 0% #29955
Description
What issue are you seeing?
What version of the Codex App are you using (From "About Codex" dialog)?
Latest
What subscription do you have?
[Pro*5]
What platform is your computer?
[macOS]
What issue are you seeing?
My Codex 5-hour usage quota and credits are being consumed instantly with no actual usage.
Steps observed:
- 5-hour usage limit was reset to 0% — I sent one single message and it immediately dropped back to 0%.
- I was granted 100 bonus credits (likely from the reset/refill promotion). After refreshing the page, the credits showed as available. Then I sent one message and the credits went from 100 → 0 instantly.
- This is completely reproducible — the quota is being burned through in seconds, not hours.
This is consistent with the known quota accounting bugs reported in:
- Pro 5x: weekly limit dropped from ~ to ~ after June 1; quota drains passively even when not using Codex #26512 (passive quota drain since June 1)
- Codex Desktop open → 5-hour usage decreases after reset despite no active task, no CLI, and no credit-history event. #21966 (quota decreases while idle)
- Codex automatically consumed my token reset opportunity during long-running task #28525 (auto-consumed reset opportunity)
- Quotas draining like crazy: burnt 100% of my 5h limit in 10 min on Business #20153 (burnt 100% of 5h limit in 10 min)
What steps can reproduce the bug?
- Wait for 5-hour quota to reset
- Send one normal message
- Observe quota drops to 0% instantly
- If bonus credits are available, refresh page → credits show 100 → send one message → credits = 0
What is the expected behavior?
- A single message should consume a small fraction of the 5-hour limit, not 100%
- 100 credits should last for many messages, not vanish after one
- Quota consumption should be proportional to actual token usage
Additional information
- Subscription: pro
- Platform: MacOs
- This appears to be a server-side quota accounting bug, not actual token overconsumption
- Multiple users are reporting identical symptoms since early June 2026
- OpenAI engineering (Tibo Sottiaux) acknowledged a "rare glitch" and reset limits for some users — I am likely affected by the same issue
- Please reset my quota/credits to reflect actual usage. Thank you.
What steps can reproduce the bug?
- Wait for 5-hour usage quota to reset (shows 0% used)
- Send ONE normal message (no large codebase, no heavy context)
- Observe: 5-hour usage immediately drops to 0% (fully consumed)
- If 100 bonus credits are available, refresh the page — credits show 100
- Send ONE message — credits drop from 100 to 0 instantly
- This is 100% reproducible every time quota resets
What is the expected behavior?
Expected: A single message should consume a small fraction of the 5-hour limit. 100 credits should last for many messages.
Actual: One message burns 100% of the 5-hour limit AND all 100 credits instantly. The quota appears to have a server-side accounting bug where consumption is massively overreported.
This is consistent with recent reports:
- Pro 5x: weekly limit dropped from ~ to ~ after June 1; quota drains passively even when not using Codex #26512 (passive quota drain since June 1, 2026)
- Codex Desktop open → 5-hour usage decreases after reset despite no active task, no CLI, and no credit-history event. #21966 (quota decreases while app is idle)
- Codex automatically consumed my token reset opportunity during long-running task #28525 (auto-consumed reset opportunity during task)
- Quotas draining like crazy: burnt 100% of my 5h limit in 10 min on Business #20153 (100% of 5h limit burned in 10 min)
OpenAI engineering (Tibo Sottiaux) previously acknowledged a "rare glitch affecting <1% of users" and reset limits. I appear to be affected by the same or a similar issue.
Please investigate and reset my quota/credits. Happy to provide screenshots or account details if needed.
Additional information
Activity
github-actions commentedon Jun 25, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
buenokai917-ux commentedon Jun 25, 2026
We met the same issue. Moreover, we have two 200$ pro users. Both capacity are gone.
amarbunty commentedon Jun 25, 2026
$200 plan also draining fast, fix the issue.
yxd7822544 commentedon Jun 25, 2026
me too
Scott-Nx commentedon Jun 25, 2026
Same issue on ChatGPT Plus.
Around 08:00 ICT (UTC+7) on 25 June 2026, my 5-hour Codex allowance went from over 90% remaining to 0% after one short prompt that produced one line of code.
I used my one available reset token. The allowance showed 100% immediately after reset, then dropped to 49% after one short prompt and later reached 0%.
This also consumed my reset opportunity.
Apache-0201 commentedon Jun 25, 2026
I'm the same. After sending a message, my credit limit was used up. I purchased 200$ plan
ycyyds123 commentedon Jun 25, 2026
Quota drains while idle: 100 credits consumed and 5h limit decreases even without running a task
s4vophan-a11y commentedon Jun 25, 2026
no-active-thread-019efcfe-bb54-7190-a0c1-fd484390afec
hahasasa commentedon Jun 25, 2026
Adding another data point: I'm hitting the same accounting over-consumption pattern described here, with hard evidence from the upstream error stream.
On 2026-06-25, one of my Pro accounts hit usage_limit_reached, then the 5h limit reset, and the SAME account reached usage_limit_reached again only ~41 minutes later. Across that 41-minute window, actual billed usage for the two active Pro accounts combined was only ~1.35M tokens (~1.05M input + ~6K output across 48 successful requests) — i.e. a small amount of real usage burned 100% of a freshly-reset 5h Pro limit.
For comparison, the same account earlier the same day consumed ~156M tokens inside a 5h rolling window before the limit triggered. So the same plan/account hit the same limit at 1.35M tokens (41 min) vs 156M tokens (5h) — a ~115x discrepancy that cannot be explained by real token consumption.
Relevant upstream error payload I captured:
status: 429
error: { "type": "usage_limit_reached", "message": "The usage limit has been reached", "plan_type": "pro", "resets_in_seconds": 15648, "eligible_promo": null }
Symptoms match exactly:
This strongly suggests a server-side quota accounting bug where consumption is massively over-reported after a reset, rather than proportional to actual token usage.
LettleCreator commentedon Jun 25, 2026
mee too
abcdshiwo commentedon Jun 25, 2026
same, pro20x -->plus
abcdshiwo commentedon Jun 25, 2026
And someone got pro5x --> pro 20x, make this really weird.
9 remaining items
sadeq-sardari commentedon Jun 25, 2026
having the same issue unfortunately. two 20x accounts
galdea commentedon Jun 25, 2026
Same here! please fix! I used up half of my weekly plus allowance in a minute.
fubin1999 commentedon Jun 26, 2026
It seems to have been fixed in Codex App 26.623.31443? I'm not quite sure though.
DM-Kevin commentedon Jun 26, 2026
我的plus套餐一个上下文压缩就用了10%的额度！
Norton-Jul commentedon Jun 26, 2026
Adding another Windows Desktop datapoint.
Environment:
Norton-JulObserved on 2026-06-26: Codex usage/credits were consumed abnormally fast during ordinary interactive troubleshooting, far more than expected relative to the visible work in the thread. This was not an intentionally long autonomous run. The symptom looks consistent with the quota/credit accounting issues described in this thread and related reports.
Please investigate server-side usage accounting for affected accounts/sessions. I can provide timestamps, screenshots, and session details privately if needed.
mattyatea commentedon Jun 26, 2026
I’m seeing the same issue as well.
I’m using ChatGPT Pro 5x , but recently the rate limits feel much stricter than before. Previously, even the 5-hour limit felt generous enough that it was difficult to fully use it up during normal work. Now, with a similar usage pattern, I can reach the weekly limit in around two days.
This feels like abnormal behavior rather than normal usage, and it may be related to the quota accounting / rate-limit issues reported here.
Could you please check whether this is expected behavior, or whether there is a regression affecting Pro 5x users?
I can provide a /feedback session ID if that would help with the investigation.
Feedback ID
Norton-Jul commentedon Jun 27, 2026
Adding an updated anonymized datapoint from Windows / Plus plan.
Date/timezone: 2026-06-27, Asia/Shanghai.
Observed behavior:
cc-switch) reported only about 355,515 real consumed tokens for that same period.This looks disproportionate: 2 user prompts / ~355k real tokens should not appear to consume 22% of a 5-hour Codex usage window on Plus within several minutes.
Please investigate whether the 5-hour quota accounting is being over-debited, whether cache-hit tokens are counted incorrectly, or whether background/session requests are being charged against the interactive quota unexpectedly.
galdea commentedon Jun 27, 2026
Same here!!
Neriysp commentedon Jun 28, 2026
Is there any update on this, I can't use my plan, cuz it will get wasted in 1 prompt.
Maloquiin commentedon Jun 29, 2026
Try to logout and login, but before you can check at codex cli /status and see your plan become is Free (I think they have incident at this day and some problems with it), after re-login you see your real plan.
I hope its will be helpful
amarbunty commentedon Jul 2, 2026
from codex cli update @0.142.4 / 0.142.5 tokens are depleting faster like Titanic ship is sinking in the sea due to bottom hole.
gititya commentedon Jul 2, 2026
Summary
Codex usage accounting appears to drain the 5-hour limit abnormally fast on ChatGPT Plus, especially on July 2, 2026. Based on local Codex session logs on macOS, the primary 5-hour usage jumped from 70% to 100% in about 5 minutes 48 seconds during ordinary interactive use, and another local session shows 71% already consumed before the visible prompts in that session began.
This issue was written with a 5.5 Medium - 18% was drained in that. Before that, I had used a banked reset - the 100% 5hr from that drained within 26 minutes. This issue was not fixed. I was seriously considering upgrading from my Plus -> Pro, but if this is how its going to be then I'm not doing that.
This does not look like normal model usage. It looks like either:
incorrect usage accounting,
hidden/background usage attribution,
or a serious regression in per-turn weighting.
Environment
Platform: macOS
Plan: Plus
App: Codex Desktop / VS Code source
Observed models in affected sessions:
gpt-5.5 with medium effort
another July 2 investigation session on gpt-5.4 with medium effort also continued draining rapidly
Strongest evidence
Post-reset timeline on July 2, 2026
From local Codex usage log events after the reset:
2026-07-02 15:18:21 IST -> 1%
2026-07-02 15:18:30 IST -> 2%
2026-07-02 15:18:46 IST -> 3%
2026-07-02 15:19:21 IST -> 6%
2026-07-02 15:19:41 IST -> 7%
2026-07-02 15:20:00 IST -> 9%
Then later in the same local session history:
2026-07-02 15:40:11 IST -> 70%
So the local logs show a post-reset climb from 1% to 9% within about 1 minute 39 seconds, followed by a jump to 70% within about 21 minutes 50 seconds. I am not attaching raw session files here because they contain prompts, outputs, and local workspace details. I can provide sanitized token_count / rate_limits lines only if needed.
Session 019f1ee9-693d-7251-bd45-953c7de51d84
Feedback ID: 019f1ee9-693d-7251-bd45-953c7de51d84
This session is explicitly recorded as gpt-5.5 with medium effort.
Primary 5-hour usage timeline:
2026-07-01 23:51:00 IST -> 5%
2026-07-01 23:51:04 IST -> 7%
2026-07-01 23:52:49 IST -> 15%
2026-07-01 23:53:44 IST -> 20%
2026-07-02 15:18:21 IST -> 1%
2026-07-02 15:18:30 IST -> 2%
2026-07-02 15:18:46 IST -> 3%
2026-07-02 15:19:21 IST -> 6%
2026-07-02 15:19:41 IST -> 7%
2026-07-02 15:20:00 IST -> 9%
2026-07-02 15:40:11 IST -> 70%
2026-07-02 15:40:22 IST -> 72%
2026-07-02 15:42:05 IST -> 77%
2026-07-02 15:42:39 IST -> 80%
2026-07-02 15:43:13 IST -> 84%
2026-07-02 15:43:56 IST -> 87%
2026-07-02 15:44:58 IST -> 95%
2026-07-02 15:45:37 IST -> 98%
2026-07-02 15:45:59 IST -> 100%
That is a rise from 70% to 100% in about 5 minutes 48 seconds.
Session 019f224e-b04a-7ee2-a2ab-b61b66f3c944
Feedback ID:
019f224e-b04a-7ee2-a2ab-b61b66f3c944
This session shows:
2026-07-02 15:42:07 IST -> 77%
2026-07-02 15:43:16 IST -> 85%
2026-07-02 15:43:25 IST -> 86%
2026-07-02 15:43:33 IST -> 87%
Important detail: another local session file showed the early post-reset 1%-9% steps above, but this session history is where the later 70%-100% drain is clearly visible.
Session 019f17cd-bde4-7802-8e91-07528398fb02
Feedback id: 019f17cd-bde4-7802-8e91-07528398fb02
This earlier session shows a much more gradual pattern at the beginning:
2026-06-30 14:46:27 IST -> 3%
2026-06-30 14:46:33 IST -> 4%
2026-06-30 14:46:46 IST -> 5%
2026-06-30 14:47:06 IST -> 6%
2026-06-30 14:47:50 IST -> 7%
2026-06-30 14:48:16 IST -> 8%
2026-06-30 14:48:31 IST -> 9%
2026-06-30 14:48:36 IST -> 10%
2026-06-30 14:49:13 IST -> 11%
2026-06-30 14:49:19 IST -> 12%
2026-06-30 14:49:33 IST -> 13%
This makes the July 2 behavior stand out as abnormal.
Why this looks broken
A local gpt-5.5 session rose from 70% to 100% in under 6 minutes.
Another July 2 local session already started with most of the 5-hour budget gone, with no local session artifact from 15:25 IST to 15:40 IST explaining that jump.
The earlier June 30 session shows a much more incremental consumption pattern.
OpenAI publicly said a Codex usage-drain fix had been deployed on June 30, 2026, but this July 2 behavior still appears broken.
Ask
Can you investigate whether usage accounting is overcharging or attributing hidden/background work to the 5-hour limit?
Can you confirm whether per-turn weighting changed for Plus users around July 1-2, 2026?
If useful, I can provide the exact local JSONL session files and the token_count / rate_limits events from those files.
egilewski commentedon Jul 2, 2026
Nice breakdown, @gititya. I guess doing
/feedbackin each of the mentioned session-chat will give support more data than those files.aqua5230 commentedon Aug 24, 2026
Similar drain patterns reported elsewhere too. If it helps document this: usage tracks quota history locally so you can show exactly when a message ate that much.
KaanSevinc commentedon Sep 28, 2026
same here codex 5-hour quota draining instantly after a single task plus subscription