Weekly quota temporarily jumped from ~3% to 52%, reset date moved Sep 15 → Sep 13, then rolled back and interrupted an active task

What subscription do you have?

ChatGPT Plus

Which model were you using?

GPT-5.6 Sol, Very High reasoning

What platform/client were you using?

Codex desktop on Windows. The same quota state was independently confirmed in the iOS app.

What issue are you seeing?

On September 9, 2026, my Codex weekly quota changed server-side in a way that I cannot explain through any manual reset, purchased reset, or credits.

I did not:

• apply a banked reset;
• purchase or apply an instant reset;
• change my subscription;
• manually modify the usage window.

Timezone for the observations below: UTC+3.

Initial state

Codex desktop showed approximately:

• weekly remaining: 4%, reset Sep 15;
• then weekly remaining: 3%, reset Sep 15.

The 5-hour window was also partially consumed.

Unexpected quota change

Without any action from me, the state suddenly changed to:

• 5-hour remaining: 100%;
• weekly remaining: 52%;
• weekly reset: Sep 13.

So both the allowance and the reset timestamp changed at the same time, and the weekly reset date moved backward:

Sep 15 → Sep 13

Independent iOS confirmation

At 20:18 UTC+3, the iOS app independently showed:

• 5-hour remaining: 89%;
• weekly remaining: 50%;
• weekly reset: Sunday 09:17 (Sep 13).

This was not a static UI artifact. I continued running Codex tasks while this state was active and the temporary allowance was actually consumed.

Quota state then rolled back

Later, without any action from me, the quota returned to the previous weekly window.

Desktop at approximately 20:52 UTC+3:

• 5-hour remaining: 49%;
• weekly remaining: 1%;
• weekly reset: Sep 15.

iOS at 20:53 UTC+3:

• 5-hour remaining: 47%;
• weekly remaining: 0%;
• weekly reset: Tuesday 10:56 (Sep 15).

The observed sequence was therefore:

~4% / Sep 15 → ~3% / Sep 15 → 52% / Sep 13 → 0–1% / Sep 15

Both desktop and iOS observed the temporary state, and both later observed the rollback.

This interrupted an active Codex task

This was not merely incorrect quota reporting.

While the temporary ~50% weekly allowance was active, Codex continued executing a long-running task and consumed a substantial part of that allowance.

When the weekly state reverted to the original exhausted window, the currently running Codex task was interrupted with a usage-limit-exhausted message, even though the 5-hour window still had roughly 45% remaining.

Therefore the quota transition directly changed server-side admission for an active task.

Support escalation

I also reported this through OpenAI Support. Front-line support confirmed the current server-side quota state but stated that it does not have access to the detailed server-side quota/reset event log. The case has been escalated to a support specialist.

Support also confirmed that credits are a separate mechanism and do not explain a weekly reset-date change.

Steps to reproduce

I do not know the server-side trigger and cannot reproduce it deterministically.

Observed sequence:

1. Use Codex normally on a ChatGPT Plus weekly quota.
2. Reach approximately 1–4% weekly remaining with reset date Sep 15.
3. Do not manually apply any reset.
4. Observe the quota unexpectedly change to approximately 52% remaining.
5. Observe the weekly reset date move backward to Sep 13.
6. Continue using Codex; the temporary allowance is actually consumed.
7. Later observe the server state revert to the original Sep 15 weekly window.
8. If the original window is exhausted, the active Codex task is interrupted.

Expected behavior

Quota accounting and the weekly reset window should be deterministic.

At minimum:

• a server-side reset/reconciliation should not temporarily expose an allowance and later revoke it while work is in progress;
• weekly remaining and reset_at should represent one authoritative window;
• the UI should not temporarily switch Sep 15 → Sep 13 → Sep 15 without an identifiable event;
• if an automatic/global reset is applied, its source and timestamp should be visible;
• an allowance that has already been granted and consumed should not silently disappear because the account is later reconciled against a previous window;
• long-running Codex work should not be interrupted because quota state oscillates between two server-side windows.

A small quota/reset event history in the Usage UI would also make this class of incident much easier to diagnose, for example:

• event type;
• event timestamp;
• previous weekly remaining/reset_at;
• new weekly remaining/reset_at;
• automatic/manual/purchased source.

Additional information

I have screenshots documenting the state transitions from both desktop and iOS.

The four desktop screenshots show, in chronological order:

1. 4% remaining / Sep 15
2. 3% remaining / Sep 15
3. 52% remaining / Sep 13
4. 1% remaining / Sep 15

The iOS screenshots independently confirm:

• 20:18 UTC+3: 50% remaining / Sep 13
• 20:53 UTC+3: 0% remaining / Sep 15

This does not appear to be a client-local rendering problem. It looks more like a temporary server-side quota-window replacement or reconciliation followed by rollback, but backend telemetry is required to determine the actual cause.

No repository file, test, or entry point is identified in the report. Start with the server-side quota/reset event log referenced by Support, then investigate the reported Sep 15 → Sep 13 → Sep 15 sequence and its interruption of an active task. Done would require a confirmed cause and an agreed fix for inconsistent quota windows.