[Pro 20x] Full banked reset appears partially applied: weekly reset anchor stayed Sep 14 and quota exhausted after only 40 PR reviews #44240

What subscription do you have?

ChatGPT Pro 20x.

What platform / Codex surface are you using?

Windows / ChatGPT Codex GitHub integration and Codex Usage dashboard.

What issue are you seeing?

I believe a Full banked Codex reset on September 9, 2026 was only partially applied or incorrectly reconciled.

The strongest evidence is the weekly reset timestamp.

I applied a Full banked reset on Sep 9, 2026. Afterward, Settings → Usage still showed:

Your rate limit resets on Sep 14, 2026, 9:47 AM

That appears to be the pre-existing weekly window associated with the Sep 7 reset. The weekly reset anchor did not move after the Full banked reset.

OpenAI's documentation says a Full banked reset refreshes both the short and weekly Codex usage windows and changes the weekly reset date. Therefore, regardless of how much work was subsequently performed, the unchanged Sep 14 reset timestamp looks inconsistent with a successfully re-anchored weekly reset.

There is a second account-level comparison from the same usage history:

• Sep 7: the refreshed quota supported approximately 371 PR reviews.
• Sep 9 after the Full banked reset: only 40 PR reviews were completed before the weekly allowance reached zero.

So the Sep 9 allowance produced only about 10.8% as many completed PR reviews as the Sep 7 refreshed allowance.

I acknowledge that the Sep 9 workload was unusually large and concurrent, so I am not claiming that 40 vs 371 alone proves incorrect metering. After the reset, a large batch was submitted:

• 104 repeated @codex review requests on pull requests where the previous review had failed, hit quota, stalled, or covered an older commit;
• 79 issue-level @codex requests on open Nabla issues;
• PRs already reviewed successfully on their current head were not intentionally re-requested.

This is 183 Codex jobs in total, and such concurrency can legitimately consume substantial allowance.

However, many of these jobs did not produce useful results: some were rejected because the Codex code-review quota was already exhausted, while some started and later failed with errors such as Provided git ref ... does not exist after the PR head changed. This makes server-side per-job reconciliation important.

The large workload may explain fast consumption if a full weekly allowance was actually provisioned, but it does not explain why the displayed weekly reset anchor remained Sep 14 after the Full banked reset.

A plausible failure mode is that the banked reset was considered consumed after refreshing only one eligible window (for example the short window), while the weekly window remained on its previous Sep 7 → Sep 14 schedule. I cannot verify this from the client side and am requesting backend reconciliation rather than asserting that mechanism as the cause.

Observed sequence

1. Sep 7, 2026: account receives/refills Codex allowance; usage history later shows roughly 371 PR reviews for that refreshed allowance period.
2. Sep 9, 2026: I redeem a Full banked reset.
3. Usage initially appears refreshed.
4. Settings → Usage nevertheless still shows the weekly reset as Sep 14, 2026, 9:47 AM.
5. A large concurrent GitHub Codex workload is submitted: 104 PR review requests plus 79 issue-level Codex requests.
6. Only 40 PR reviews are shown as completed for Sep 9 before the weekly allowance reaches zero.
7. Multiple subsequent Code Review requests return the quota-exhausted message; several started reviews also fail because their recorded git ref no longer exists.
8. The banked reset is consumed, while the weekly reset date remains on the old Sep 14 anchor.

What is the expected behavior?

For a Full banked reset:

1. The weekly allowance should actually be refreshed.
2. The weekly reset timestamp should be reconciled/re-anchored consistently with that reset.
3. The banked reset should not be consumed while leaving the weekly window on the previous schedule unless that behavior is explicitly intended and documented.
4. Usage charged to large concurrent GitHub workloads should be auditable per job, especially for jobs that fail, are rejected for quota, or terminate on a stale/nonexistent git ref.

Requested investigation

Please reconcile the server-side account ledger around the Sep 9 banked reset and determine:

1. The exact banked-reset event timestamp and whether it was recorded as successful.
2. The weekly window start/end timestamps immediately before and after the banked reset.
3. Whether the weekly allowance was actually replenished, and to what entitlement/capacity.
4. Why the displayed next reset remained Sep 14, 2026, 9:47 AM after the Full banked reset.
5. Whether only one eligible rate-limit window was refreshed while the weekly window remained unchanged.
6. The allowance immediately before and immediately after the reset.
7. Usage attribution for the 104 PR-review jobs and 79 issue-level Codex jobs, including failed/rejected/stale-ref jobs.
8. Whether concurrent jobs can continue consuming the same weekly bucket after the account crosses the limit, and how that is reconciled.
9. If the banked reset or subsequent deductions were incorrectly applied, please restore the affected reset/allowance.

I have screenshots of the Usage page and the PR-review analytics showing 40 PRs reviewed on Sep 9, and can provide additional timing/account-specific evidence privately if needed.

Related current reports

This may be part of the same current reset/accounting incident, although I am not assuming one common root cause:

• Codex rate-limit bug: banked reset consumed, 94% weekly quota dropped to 0% #44221 — banked reset consumed and weekly quota dropped to 0
• Weekly reset timestamp appears stale after Sep 7 global Codex reset #44201 — weekly reset timestamp appears stale after the Sep 7 global reset
• [Windows][Pro 20x] Weekly usage display jumped 60%→97% while reset timestamp changed #44210 — Pro 20x weekly usage and reset timestamp changed unexpectedly
• [Meta] Abnormal Codex usage/quota depletion and usage-accounting inconsistencies — cross-report tracker #41220 — abnormal Codex usage/quota depletion and accounting cross-report tracker
• Weekly Codex quota reset/reconciliation appears broken — quota exhausted with no local activity #42660 — weekly quota reset/reconciliation appears broken

The distinctive evidence in this report is the combination of a manually redeemed Full banked reset whose weekly reset timestamp did not move, plus a same-account historical baseline of 371 PR reviews versus 40 before exhaustion.