Repository navigation
Abnormal Codex usage accounting exhausted remaining weekly allowance instantly #40895
Description
What issue are you seeing?
I am seeing what appears to be abnormal Codex usage accounting today (August 26, 2026).
Immediately before the incident, my Codex usage dashboard showed approximately 78% remaining. Shortly afterward, the remaining allowance suddenly dropped to 0%. When I inspect today's usage, it shows an abnormally large amount of usage that appears to have consumed all of the remaining allowance at once.
This does not match my observed Codex activity and is substantially different from my normal usage pattern.
Request
Could the Codex team please investigate the server-side usage/accounting records for my account and determine:
- What specific Codex sessions/tasks generated the unusually large usage today.
- Whether token/compute usage was counted correctly.
- Whether a stuck/background session, subagent, retry loop, duplicated accounting, or other usage-accounting issue caused the sudden consumption.
- Why the remaining allowance changed from approximately 78% to 0% in a very short period.
- Whether incorrectly counted usage can be corrected/restored after investigation.
There are other open reports in this repository describing unusually high usage or quota changes without corresponding activity, so this may be related to an existing rate-limit/usage-accounting issue.
Please let me know what additional identifiers, timestamps, screenshots, session/thread IDs, or diagnostic information are needed to trace the affected usage.
Activity
github-actions commentedon Aug 26, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
FromAriel commentedon Aug 27, 2026
Cross-linking this Aug 26 sudden-depletion report to #41220, the new meta tracker for abnormal Codex usage/quota depletion and usage-accounting inconsistencies. The ~78% remaining → 0% discontinuity is a useful recent server-side reconciliation target. The meta issue specifically asks maintainers to correlate bounded incidents like this against deployments, background activity, entitlement state, and accounting changes.
jin44194649 commentedon Sep 30, 2026
Related current data point from Sep 29, 2026 (America/Chicago): on a $200 ChatGPT Pro account, the weekly meter reset/upgrade time was 18:09. The main ChatGPT Work session lasted about three hours (to ~21:09) and was used for eight chapters of writing/review. By 22:32 the weekly meter showed 89% remaining. I am not claiming the same root cause as this issue, but the effective consumption was unexpectedly high and the UI did not provide enough task-level attribution to reconcile the drop. I added the fuller timeline in #40527.
The common symptom is a sharp weekly-meter drop that is difficult for the user to reconcile with foreground work. Please include Work-surface accounting when investigating sudden depletion.
jdg511 commentedon Oct 6, 2026
This sounds similar to my issue: no-active-thread-01a110cf-8630-7742-b060-3818eb3e2f72
I'll be away from chatgpt desktop all day, but then login to see my 5hrs is up, and that I'll get new usage at, (for example: 4am, when it is currently 5am)!