[Plus][Windows] Weekly quota jumps 29% → 100% exactly when 5-hour window resets 92% → 0%

What subscription do you have?

ChatGPT Plus.

What platform are you using?

Windows / Codex local sessions. The evidence below was extracted from local ~/.codex/sessions/**/rollout-*.jsonl files with PowerShell.

What issue are you seeing?

The Codex weekly quota appears to have jumped from 29% used to 100% used in about one minute, at exactly the same timestamp that the 5-hour window reset from 92% used to 0% used.

Before the jump, the weekly meter was increasing gradually and consistently. Afterward, the ChatGPT usage UI showed the 5-hour allowance almost fresh while the weekly allowance was fully exhausted.

This looks like a possible server-side quota rollover/accounting issue. I am not claiming the local telemetry alone proves the root cause; I am asking for the server-side usage ledger for this window to be reconciled.

Local rate-limit timeline

Timestamps below are copied from the local Codex event_msg.payload.rate_limits telemetry.

Weekly window (window_minutes = 10080, limit_id = codex)

2026-09-09 16:48:21  weekly used = 24%
2026-09-09 16:49:42  weekly used = 25%
2026-09-09 16:51:21  weekly used = 26%
2026-09-09 16:53:29  weekly used = 27%
2026-09-09 16:55:01  weekly used = 28%
2026-09-09 16:55:53  weekly used = 29%
2026-09-09 16:57:03  weekly used = 100%

So the weekly bucket moved 29% → 100% between the final two observations.

Earlier that day it had started at 0% and climbed gradually:

2026-09-09 12:30:34  weekly used = 0%
2026-09-09 12:30:43  weekly used = 1%
...
2026-09-09 15:53:52  weekly used = 12%
...
2026-09-09 16:28:19  weekly used = 20%
...
2026-09-09 16:55:53  weekly used = 29%

5-hour window (window_minutes = 300, limit_id = codex)

2026-09-09 16:48:21  5h used = 58%
2026-09-09 16:48:35  5h used = 61%
2026-09-09 16:49:42  5h used = 64%
2026-09-09 16:51:21  5h used = 72%
2026-09-09 16:53:29  5h used = 77%
2026-09-09 16:55:01  5h used = 85%
2026-09-09 16:55:53  5h used = 90%
2026-09-09 16:56:16  5h used = 92%
2026-09-09 16:57:03  5h used = 0%

The 5-hour rollover itself looks expected. The suspicious part is that the weekly bucket simultaneously jumps to 100% at the exact rollover timestamp.

Why this appears anomalous

• The weekly bucket was moving gradually from 0% to 29% over several hours.
• The final weekly transition is a discontinuous +71 percentage points.
• The discontinuity occurs at the same timestamp as the 5-hour bucket resets to 0%.
• The next UI state is consistent with this telemetry: the 5-hour allowance is nearly fresh while the weekly allowance is exhausted.

This could theoretically be delayed server-side accounting from earlier work, so please reconcile the backend ledger rather than assuming the local percentage jump alone establishes incorrect charging.

Expected behavior

The 5-hour bucket should reset independently. A 5-hour rollover should not cause the weekly bucket to jump from 29% to 100% unless there is real chargeable work sufficient to explain the 71-point increase.

Please check whether the weekly quota was:

1. incorrectly changed during the 5-hour rollover;
2. switched to a different denominator / entitlement state;
3. updated with a large delayed charge that is not attributable from local telemetry; or
4. otherwise mis-accounted during this timestamp.

If the server-side ledger confirms incorrect deduction, please restore the incorrectly consumed weekly allowance.

Privacy / additional evidence

I have the local rollout logs and can provide sanitized token_count / rate_limits excerpts if maintainers need them. I am not posting raw JSONL files publicly because they can contain prompts, code, local paths, and workspace details.

Related reports

• #41220 — meta tracker for abnormal quota depletion / accounting inconsistencies
• #21216 — weekly usage discontinuity associated with a quota/entitlement state change
• #32827 — delayed weekly quota updates / attribution inconsistencies

Start with the sanitized event_msg.payload.rate_limits excerpts from ~/.codex/sessions/**/rollout-*.jsonl and compare the weekly and 5-hour timestamps. Confirm the server-side usage ledger explains the 29%→100% weekly transition at the 5-hour reset, or identify the accounting discrepancy.