Weekly Codex quota oscillates between two different reset windows (Sep 15 ↔ Sep 12) with large usage jumps

What issue are you seeing?

I am seeing what appears to be a server-side Codex weekly quota bucket/window switching issue.

My account appears to have two different weekly quota states, and the backend is switching between them.

Background:

• On Sep 5, I used a banked reset. This produced a weekly reset date of Sep 12.
• On Sep 8, after the global Codex reset announced by Thibault Sottiaux, my weekly quota was actually reset to 100%, and the reset date changed to Sep 15.
• I continued using Codex normally after that.

On Sep 10, I observed the backend suddenly switch between these two weekly quota states.

This is not just a UI or cache issue. I verified the changes directly from the HTTP response headers recorded in the local Codex logs.

First transition:

At 2026-09-10 02:10:43 KST:

• x-codex-primary-used-percent: 32
• x-codex-primary-window-minutes: 10080
• x-codex-primary-reset-at: 2026-09-15 18:49:42 KST

At 2026-09-10 02:11:11 KST, only 28 seconds later:

• x-codex-primary-used-percent: 46
• x-codex-primary-window-minutes: 10080
• x-codex-primary-reset-at: 2026-09-12 23:46:49 KST

The backend therefore switched from:
Sep 15 reset / 32% used

to:
Sep 12 reset / 46% used

Later, it switched back again.

At 2026-09-10 02:39:24 KST:

• used: 47%
• remaining: 53%
• reset: 2026-09-12 23:46:49 KST

At 2026-09-10 02:39:58 KST, only 34 seconds later:

• used: 32%
• remaining: 68%
• reset: 2026-09-15 18:49:43 KST

After that, the Sep 15 window remained active and usage increased normally from 32% to 33%.

The same quota state was observed across GPT-5.6 Sol, GPT-5.6 Terra, and Codex auto-review requests.

This strongly suggests that the backend is switching between two separate weekly quota ledgers/windows:

1. The older weekly window created by my Sep 5 banked reset:

   • reset: Sep 12
   • usage: approximately 46–47%

2. The newer weekly window created by the Sep 8 global reset:

   • reset: Sep 15
   • usage: approximately 32–33%

The active quota state appears to oscillate between these two windows without any action from me.

Because both x-codex-primary-used-percent and x-codex-primary-reset-at change together in the server response headers, this does not appear to be a local UI caching issue.

Please investigate whether multiple weekly quota ledgers can remain active after a global reset and whether the backend can incorrectly switch between them.

What steps can reproduce the bug?

1. Use a banked reset, creating a new weekly quota window.
2. Later receive a global Codex reset that creates another weekly reset date.
3. Continue using Codex normally.
4. Observe the weekly quota state in Codex or the Usage page.
5. Inspect the x-codex-primary-used-percent and x-codex-primary-reset-at response headers.
6. In my case, the backend switched between the old and new weekly quota windows multiple times within seconds.

What is the expected behavior?

The weekly Codex quota should remain associated with a single consistent active quota window.

After the Sep 8 global reset created a new weekly window with a Sep 15 reset date, the backend should continue using that window until it naturally expires or another explicit reset occurs.

The backend should not switch back to an older Sep 12 quota window, nor should the reported used percentage jump between two different values without corresponding usage activity.

Both the reset timestamp and usage percentage should remain consistent across Codex clients, conversations, models, and the Usage page.

Additional information

I already submitted this issue through the Codex in-app /feedback flow with diagnostic logs included.

Feedback ID: 01a080b7-7b20-7ce1-8054-c1c2d3513ccd

Additional information:

• I already submitted this issue through the Codex in-app /feedback flow with diagnostic logs included.
• The quota changes were independently verified in the local Codex logs from the actual HTTP response headers returned by the backend.
• The relevant headers were:
  • x-codex-primary-used-percent
  • x-codex-primary-window-minutes
  • x-codex-primary-reset-at
• The backend switched from the Sep 15 window to the Sep 12 window, and later switched back again.
• The transitions occurred within tens of seconds and affected both the reported usage percentage and reset timestamp at the same time.
• The same quota state was observed across GPT-5.6 Sol, GPT-5.6 Terra, Codex auto-review, and the web Usage page.
• Screenshots are attached showing different quota states observed from the same VS Code environment and the web Usage page.

I can provide additional local log excerpts with row IDs and timestamps if needed.

Start by reviewing the local Codex logs and the x-codex-primary-used-percent, x-codex-primary-window-minutes, and x-codex-primary-reset-at response headers, then reproduce the reset-window transitions described above. Done means identifying why the Sep 12 and Sep 15 quota states alternate and ensuring one active weekly window remains consistent across clients and the Usage page.