Repository navigation
GPT-5.6 Plus weekly usage suddenly drained from ~99% to 0% within hours — possible usage accounting regression #40067
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.818.41509
What subscription do you have?
ChatGPT Plus
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
My ChatGPT Plus Codex weekly usage appears to have been depleted abnormally fast on August 21, 2026.
My weekly allowance had recently reset. On the morning of Aug 21, the Usage Dashboard showed approximately 99% remaining. Within only a few hours, it suddenly reached 0% remaining and Codex became blocked.
At approximately 14:41 GMT+7, requests began returning:
HTTP 429 - usage_limit_reached
plan_type: plus
The visible Usage Dashboard currently exposes only the weekly limit. The previous 5-hour meter is no longer shown on my account since the recent GPT-5.6 usage changes.
I was using a local Hermes Agent connected through OpenAI/ChatGPT OAuth (openai-codex), not an API key. The workload that morning consisted mainly of routine agent tasks, scheduled briefings, Telegram integration testing, and operational-reminder setup.
I audited the complete local Hermes agent log for the relevant period. Before the limit was reached it recorded:
- 107 successful Codex model calls
- 101 GPT-5.6 Luna calls
- 6 GPT-5.6 Sol calls
- approximately 9.39M gross input tokens
- approximately 8.35M cached input tokens (~88.9%)
- approximately 1.05M uncached input tokens
- approximately 84K output tokens
There was no large successful Hermes workload between approximately 13:30 and 14:41 GMT+7. At 14:41 Codex immediately began returning usage_limit_reached.
However, Codex Desktop Profile analytics later reported 81.7M tokens for Aug 21.
This creates two concerns:
- The server-side Profile total (81.7M) is much larger than the successful model activity I can reconcile from the Hermes local log (~9.39M gross tokens).
- Even if the full 81.7M Profile total is correct, exhausting nearly the entire weekly allowance is inconsistent with historical usage on the same account.
For comparison, my Codex Profile shows:
- Aug 19: ~59.2M tokens, which I observed consuming only approximately 10-12% of my available usage.
- Aug 12: ~96.7M tokens during an intentionally very heavy usage day, which consumed roughly 60%+ rather than the entire allowance.
- Aug 21: 81.7M tokens, yet the weekly allowance went from approximately 99% remaining to 0%.
I understand that raw token counts do not map 1:1 to rate-limit consumption because models, cached input, reasoning and weighting differ. However, the magnitude and suddenness of this change appear inconsistent with the historical behavior of the same Plus account.
Please investigate whether this is caused by incorrect usage accounting, duplicated OAuth attribution, delayed/background usage attribution, or a regression in GPT-5.6 weekly rate-limit weighting.
What steps can reproduce the bug?
This is not reliably reproducible on demand because the suspected problem is server-side usage accounting. The observed sequence was:
- Start with a recently reset ChatGPT Plus weekly Codex allowance.
- Confirm that the Usage Dashboard shows approximately 99% remaining.
- Use Codex through a ChatGPT/OAuth-connected local agent (Hermes Agent) with GPT-5.6 Luna and GPT-5.6 Sol.
- Perform normal/light-to-moderate agent tasks, including scheduled briefings, file reads, Telegram testing and operational-reminder setup.
- Observe normal usage initially; one morning briefing appeared to reduce the visible weekly allowance by only around 1%.
- Continue normal usage for several hours.
- At approximately 14:41 GMT+7, observe Codex immediately return HTTP 429 usage_limit_reached.
- Open the Usage Dashboard and observe 0% remaining even though it had been approximately 99% earlier that day.
- Later inspect Codex Desktop Profile analytics and observe 81.7M tokens attributed to Aug 21.
- Compare this with local OAuth-agent logs, which show only 107 successful Codex calls and approximately 9.39M gross input tokens during the investigated period.
Relevant investigation window:
August 21, 2026
approximately 08:00-14:45 GMT+7
approximately 01:00-07:45 UTC.
I can provide sanitized local logs containing timestamps, model names, cached/uncached token counts and the final HTTP 429 response.
What is the expected behavior?
Weekly usage should decrease consistently according to the actual weighted Codex workload.
A ChatGPT Plus weekly allowance that is approximately 99% available should not suddenly become 0% within a few hours unless the account actually performed enough weighted inference to consume the full allowance.
OAuth-connected agents should not have requests duplicated, incorrectly attributed or charged multiple times.
If background tasks, subagents, automatic reviews or another Codex/Work surface consumed the allowance, the user should have an auditable usage breakdown showing which surface, model and activity caused the consumption.
The Codex Profile token analytics and the rate-limit meter should also be sufficiently consistent and transparent that a user can determine why an allowance was exhausted.
If the weekly allowance or per-model weighting changed with GPT-5.6, that change should be reflected clearly in the product and documentation rather than appearing as a sudden unexplained depletion.
Additional information
I searched existing openai/codex issues before filing this report.
Potentially related reports include:
- Weekly limit is draining like the old 5-hour limit #33685 — "Weekly limit is draining like the old 5-hour limit"
- Usage limits draining abnormally fast on Plus: 70% to 100% in about 6 minutes on July 2, 2026 #30918 — Plus usage limits draining abnormally fast
- Codex (gpt-5.5, Plus plan) — rate-limit cost per token jumped ~10-20x since June 16, draining the 5h budget in 2-3 prompts #28879 — rate-limit cost per token increased dramatically
- Codex subagents drain full week quota overnight - usage counting broken #35463 — weekly quota drained abnormally with subagent activity
- GPT-5.6 Sol rarely parallelizes programmatic tool calls, multiplying model turns and quota usage #32503 — GPT-5.6 tool-call behavior multiplying model turns and quota usage
My case appears related but is not identical.
Important differences in this report:
- ChatGPT Plus
- GPT-5.6 Luna was used for most of the successful calls
- The visible 5-hour meter has disappeared; only the weekly allowance is shown
- Weekly usage changed from approximately 99% remaining to 0% within a few hours
- Codex Profile eventually attributed 81.7M tokens to Aug 21
- The investigated Hermes OAuth client log accounts for only ~9.39M gross input tokens from successful calls during the relevant period
- Approximately 88.9% of those locally recorded input tokens were cached
- No large successful Hermes workload is visible between approximately 13:30 and the first usage_limit_reached response at 14:41 GMT+7
- Historical usage on the same account was substantially more predictable: ~59.2M tokens on Aug 19 consumed only around 10-12% by my observation, while a ~96.7M-token intentionally heavy day on Aug 12 still did not instantly consume the entire allowance.
I also contacted OpenAI Support. The issue was escalated to a specialist, but the first-line support view could only confirm that the weekly allowance was fully consumed and could not provide a per-request usage breakdown.
Evidence available:
- Screenshot of 0% weekly usage / reset date
- Screenshot of Codex Profile showing 81.7M tokens on Aug 21
- Historical Profile token activity
- Sanitized Hermes agent log with model calls, token counts, cache ratios and timestamps
- HTTP 429 usage_limit_reached log entries
I can provide additional sanitized diagnostic data if requested.
Activity
github-actions commentedon Aug 22, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
kevintimeline commentedon Aug 22, 2026
Major update — usage continued dropping while Codex Profile reports 0 tokens for Aug 22
I used my available Full Usage Reset on Aug 22 at approximately 12:59 PM GMT+7, which restored my weekly usage to 100%.
After the reset, I performed only a very small controlled Hermes test. My local Hermes logs showed approximately 43K successful OpenAI Codex tokens from two GPT-5.6 Luna calls (~21.5K each).
The weekly meter then continued decreasing:
~12:59 PM — 100% remaining
~1:28 PM — 94%
~1:52 PM — 89%
~3:27 PM — 67%
During the later period I was not running Hermes prompts, Discord/Telegram agent tasks, Codex tasks, or Work. I was only playing a game on the computer.
I also checked Hermes logs for recent Codex activity and the filtered log returned no matching API calls during the checked window.
Most importantly, Codex Desktop → Profile → Token Activity currently reports “0 tokens on Aug 22”, while Usage & Billing shows only 67% weekly usage remaining.
For comparison, the same Profile correctly shows 81.7M tokens on Aug 21.
Therefore, the Codex Desktop UI currently shows:
Aug 22 Token Activity: 0 tokens
Aug 22 weekly usage consumed after Full Reset: 33%
I understand that Profile analytics may potentially have reporting delay, but this creates a significant observable inconsistency between the Profile analytics and the weekly usage meter.
I have screenshots of:
100% immediately after Full Reset
96%, 94%, 90%, 89%, and 67% remaining
Codex Profile showing 0 tokens on Aug 22
Hermes local logs
I am stopping further tests to preserve the remaining quota and will check whether the weekly meter continues decreasing while the local Hermes machine is completely powered off.
zerox80 commentedon Aug 22, 2026
same issue here, probably some context caching issue
SpadesZ commentedon Aug 24, 2026
Independent Windows/Plus reproduction from a second account:
Codex Plus weekly usage regression evidence
Date: 2026-08-24 (Asia/Taipei)
Platform: Windows, Codex desktop integration build 26.818.41509
Plan: ChatGPT Plus
Primary model: GPT-5.6 Sol
Reasoning: xhigh
Service tier: default, not Fast mode
Reported regression
The user estimates that the same normal workflow now completes about 70% less work per weekly allowance than it did before the last two weeks. The model and reasoning configuration did not change during that comparison period.
Local measurements
1. Initial context did not grow
Median first-request input tokens across newly created local sessions:
The recent median is 7.4% lower, so the regression is not explained by larger initial prompts.
2. Direct OpenAI reproduction
Window: 2026-08-24 04:48:56 to 05:03:32 UTC.
openai3. Headroom-path reproduction
By 2026-08-24 05:13:33 UTC in a new task:
headroomThis shows the rapid drain on both the direct OpenAI path and the Headroom path.
4. Small-task boundary crossing
A separate new task used only two model responses:
The meter is integer-rounded, so this event alone does not prove that the task consumed a full 1%. It does show that a small visible task can cross a displayed percentage boundary.
5. Measured amount lost
The 25.2% figure is an approximation because the meter is integer-rounded and the seven-day window can move. It is independent support for a real decline, but it is not claimed as the exact account entitlement change.
Headroom findings
Headroom was active. Its current window reported:
Headroom saves little here because 93% to 96% of input is already cached. It preserves the cached prefix instead of rewriting it, because rewriting it would destroy the provider cache. It can compress only the eligible uncached tail. It also does not reduce the number of Codex agent/tool round trips or change the server-side weekly allowance.
Recent runtime correlation
Local session metadata shows runtime changes during the reported regression window:
This is correlation only. It does not prove which release changed behavior.
Requested investigation
Please check:
Private project content and full transcripts are deliberately omitted. Sanitized event rows and session identifiers can be provided through a private OpenAI channel if required.
FromAriel commentedon Aug 27, 2026
Cross-linking this Plus sudden-depletion/local-vs-server attribution case to #41220, the new meta tracker for abnormal Codex usage/quota depletion and usage-accounting inconsistencies. This report adds a particularly useful same-account historical baseline plus a large discrepancy between locally reconcilable OAuth-client activity and later Profile attribution. The tracker asks maintainers to correlate these bounded windows server-side rather than assume all linked cases share one mechanism.
evanziwen commentedon Aug 28, 2026
Hi — I’m working on a small, local-first regression analysis project for Codex incidents, and this is one of the clearest usage-accounting cases I’ve found.
The part I’m especially interested in is the reconciliation gap between the activity visible in your local Hermes/OAuth logs and the much larger Codex Profile / weekly-usage movement — including your Aug 22 update where the weekly meter kept dropping while Profile showed 0 tokens.
If you’re still willing to share a sanitized subset of the logs you mentioned, I’d be happy to do an independent incident autopsy for free and return the analysis to you (publicly or privately, whichever you prefer).
I don’t need credentials, prompt contents, source code, or account identifiers. Timestamps, model names, cached/uncached token counts, request outcomes, meter observations, and the 429 boundary would be enough to start.
The goal would not be to assume an OpenAI accounting bug, but to separate what the client-side evidence can actually establish, what it rules out, and what server-side evidence would still be required.
kevintimeline commentedon Aug 28, 2026
Hi — thanks for offering to take a look. I found that I still had more of the retained evidence than I expected, so I prepared a sanitized incident package.
It includes:
per-call Hermes/OpenAI-Codex timestamps, model names, input/output token counters, cache telemetry where available, latency, and outcomes;
pseudonymized session aggregates;
the Aug 21 HTTP 429 / usage-limit boundary;
a small sanitized set of Codex Desktop observations and a later idle/control window;
cropped screenshots documenting the weekly-meter sequence after reset; and
a README that explicitly separates what the client-side evidence establishes from what would still require server-side data.
I removed credentials, OAuth/cookie material, prompt contents, source code, account identifiers, thread/request IDs, business/customer data, personal paths, and chat IDs. One limitation: I could not find a retained sanitized artifact that independently verifies the specific “Profile showed 0 tokens” state from my earlier update, so I did not present that as machine-verified evidence. I did retain a Profile screenshot showing 94.4M tokens on Aug 22, plus the weekly-meter screenshots and the local 429 boundary.
I also want to be transparent that the same personal account may have been active on more than one device I personally control during the broader incident period, so the package should not be treated as a complete server-side/account-wide trace.
I’d be very interested in your independent read, especially whether the retained local activity can reconcile with the meter movement under any plausible accounting model, and what server-side evidence would still be needed to distinguish delayed posting, unobserved activity, or an accounting issue.
Codex_Sanitized_Incident_Package_Aug2026.zip
evanziwen commentedon Sep 1, 2026
Thanks — I worked through the sanitized package and did a first independent reconciliation pass. The package integrity checks out, and your own limitation notes are important to the conclusion.
My current read is:
usage_limit_reachedsignal is 14:41:48.905, leaving a ~71.3-minute bounded gap with no successful Hermes API-call records in this file.That 71-minute interval is useful negative evidence, but because the same account may have been active on other personally controlled devices/clients, it cannot be interpreted as an account-wide quiet period.
So the strongest statement I think the evidence supports is:
The minimum server-side export that would make this substantially more attributable would be account-scoped ledger rows containing event time vs accounting-post time, originating surface/client/device class, resolved model/reasoning tier, cached/uncached/output/reasoning quantities actually used for accounting, effective rate-limit/weighting policy version, per-event weekly-meter delta, retry/subagent/auxiliary classification, deduplication/idempotency information, and entitlement/reset events.
If you want to run one more client-side control after a clean weekly reset, the highest-value experiment would be: stop/sign out every known Codex/OAuth client except one designated test client, record exact meter state, run a small frozen workload with full local telemetry, stop that client completely, then record meter snapshots at fixed times through a bounded quiet window. That would not reveal the server formula, but it would remove the largest current confounder: incomplete account-wide activity visibility.
Thanks again for preparing the package so carefully — especially for explicitly separating retained evidence from claims you could no longer independently verify.
jankinable-gmail commentedon Sep 17, 2026
Same behavior detected from the Desktop application. It drops without even being used.
krsx commentedon Sep 22, 2026
This issue still persist in both Codex CLI and Desktop App.
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.
This is another “large effective depletion within hours” data point, although on a different surface/plan context. The key request is server-side reconciliation between actual model/task activity and the percentage removed from the weekly bucket.