GPT-5.6 Plus weekly usage suddenly drained from ~99% to 0% within hours — possible usage accounting regression

Open 💬 5 comments Opened Aug 22, 2026 by kevintimeline
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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:

  1. 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).
  2. 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:

  1. Start with a recently reset ChatGPT Plus weekly Codex allowance.
  2. Confirm that the Usage Dashboard shows approximately 99% remaining.
  3. Use Codex through a ChatGPT/OAuth-connected local agent (Hermes Agent) with GPT-5.6 Luna and GPT-5.6 Sol.
  4. Perform normal/light-to-moderate agent tasks, including scheduled briefings, file reads, Telegram testing and operational-reminder setup.
  5. Observe normal usage initially; one morning briefing appeared to reduce the visible weekly allowance by only around 1%.
  6. Continue normal usage for several hours.
  7. At approximately 14:41 GMT+7, observe Codex immediately return HTTP 429 usage_limit_reached.
  8. Open the Usage Dashboard and observe 0% remaining even though it had been approximately 99% earlier that day.
  9. Later inspect Codex Desktop Profile analytics and observe 81.7M tokens attributed to Aug 21.
  10. 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:

  • #33685 — "Weekly limit is draining like the old 5-hour limit"
  • #30918 — Plus usage limits draining abnormally fast
  • #28879 — rate-limit cost per token increased dramatically
  • #35463 — weekly quota drained abnormally with subagent activity
  • #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.

<img width="917" height="630" alt="Image" src="https://github.com/user-attachments/assets/e9a3c2ae-b893-4ad7-a4b4-724a3a9d8861" />

<img width="918" height="521" alt="Image" src="https://github.com/user-attachments/assets/9ca54bc7-8a22-4b56-bb54-cb31822502b8" />

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 6 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #40043
  • #39818
  • #39699
  • #38728

Powered by Codex Action

kevintimeline · 6 days ago

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.

<img width="1751" height="957" alt="Image" src="https://github.com/user-attachments/assets/e0bc634c-5b53-4809-bb8f-d475be3cd9f6" />

<img width="1276" height="823" alt="Image" src="https://github.com/user-attachments/assets/6b9a897a-bf01-46c7-8175-6115d538eb06" />

zerox80 · 6 days ago

same issue here, probably some context caching issue

SpadesZ · 4 days ago

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:

| Period | Sessions | Median first input |
|---|---:|---:|
| 2026-07-25 to 2026-08-06 | 14 | 36,564 |
| 2026-08-18 to 2026-08-24 | 6 | 33,870 |

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.

  • Provider recorded by Codex: openai
  • Model responses: 38
  • Input tokens: 4,981,341
  • Cached input tokens: 4,617,600 (92.7%)
  • Uncached input tokens: 363,741
  • Output tokens: 17,652
  • Reasoning output tokens: 4,934
  • Visible weekly usage: 0% to 6% used
  • Approximate GPT-5.6 Sol rate-card equivalent: 91.38 credits

3. Headroom-path reproduction

By 2026-08-24 05:13:33 UTC in a new task:

  • Provider recorded by Codex: headroom
  • Input tokens: 3,023,861
  • Cached input tokens: 2,881,024 (95.3%)
  • Output tokens: 16,493
  • Reasoning output tokens: 8,386
  • Visible weekly usage: 6% to 8% used
  • Approximate GPT-5.6 Sol rate-card equivalent: 51.34 credits

This 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:

  • Total input tokens: 53,869
  • Total output tokens: 716
  • Visible weekly usage crossed from 4% to 5% used

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

  • User-observed usable-work reduction: about 70%.
  • Coarse local quota-density estimate:
  • Earlier median: about 28.2 Sol-equivalent credits per displayed 1%.
  • Current partial window: about 21.1 Sol-equivalent credits per displayed 1%.
  • Difference: 25.2% less weighted work per displayed percentage point.

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:

  • API requests: 122
  • Requests compressed: 29
  • Average compression on eligible requests: 3.9%
  • Tokens removed: 63,416
  • Requests left uncompressed because the provider prefix was already cached: 90
  • Net cost reduction: 1.9%

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:

  • Early August: 0.147 series
  • From 2026-08-18: 0.148 series
  • From 2026-08-23: 0.149 series

This is correlation only. It does not prove which release changed behavior.

Requested investigation

Please check:

  1. Whether GPT-5.6 weekly weighting or Plus entitlement changed during the August rollout.
  2. Whether cached input is being charged with the documented weighting.
  3. Whether agent/tool round trips are duplicated or attributed more than once.
  4. Whether OAuth, direct OpenAI, and local-proxy requests are all attributed to the correct account and task.
  5. Whether Codex can expose a per-thread breakdown of weighted credits, not only raw tokens and an integer percentage.

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 · 12 hours ago

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.