Skip to content

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

Open

Description

@In-Bound

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.

Image Image

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.

Activity

  1. added
    rate-limitsIssues related to rate limits, quotas, and token usage reporting
    on Sep 9, 2026
  2. dterenyi commented on Sep 9, 2026

    @dterenyi

    I consolidated my full Windows Desktop / Pro 20x evidence in this comment on #44210, alongside the recovery updates and other independent account observations already there.

    My weekly remaining sequence was 66% → 75% → 74% → 66%, with reset dates September 15 → September 14 → September 15. My changed interval was 16:57:17.765 to 17:41:17.488 UTC on September 9. Your changed and restored readings at 17:11:11 and 17:39:58 UTC fall inside it.

    The linked comment compares all five bot suggestions in a compact table. A shared cause remains unconfirmed.

  3. hirosenokensan commented on Sep 10, 2026

    @hirosenokensan

    I am seeing what appears to be the same underlying issue on ChatGPT Plus / Codex Desktop 0.153.4 on Windows 10, and my local rollout JSONL provides an additional banked-reset example.

    All times below are JST.

    Before the full reset:

    2026-09-09 21:28:26
    weekly used = 74%
    weekly reset = 2026-09-15 13:55:51
    

    A fresh quota state was then recorded:

    2026-09-10 02:08:33
    5h used = 0%
    weekly used = 0%
    weekly reset = 2026-09-17 02:08:25
    

    Codex performed substantial real work after that, and by 02:21:04 the state was:

    5h used = 99%
    weekly used = 16%
    weekly reset = 2026-09-17 02:08:31
    

    The root rollout then contains no model responses or tool executions between approximately 02:21:04 and 07:55:38. The JSONL ordinals are consecutive across this interval.

    On the first quota snapshot after resuming:

    2026-09-10 07:56:00
    5h used = 0%
    weekly used = 74%
    weekly reset = 2026-09-15 13:55:51
    

    The important part is that the backend did not merely report higher weekly usage. It returned the exact same pair that existed before the banked reset:

    74% used
    2026-09-15 13:55:51 reset
    

    So the observed sequence is:

    74% / Sep 15
    → full reset
    0% / Sep 17
    → legitimate usage
    16% / Sep 17
    → idle
    74% / Sep 15
    

    This strongly resembles a switch back to an older weekly quota ledger/window rather than 58 percentage points of normal usage occurring during the idle interval.

    I can provide sanitized token_count / rate-limit excerpts or the complete rollout files privately if useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingrate-limitsIssues related to rate limits, quotas, and token usage reporting

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions