Codex Reset Date Keeps Moving: Separate Automatic, Banked, and Paid Resets

Separate the usage states#

These labels are easy to mix up:

OpenAI’s current paid reset guidance says an eligible instant reset applies immediately and pulls the normal allowance forward; it is not an extra weekly allocation. The separate banked reset guidance says a banked reset remains available until it is used or expires. Availability and wording vary by plan, account, workspace, and region, so treat the option shown for your account as authoritative.

Check the live state inside the current session#

In the Codex CLI, open the affected session and run:

1
/status

Record these fields before trying another long prompt:

• the signed-in account or plan shown by the session;
• the 5-hour and weekly remaining percentages;
• each displayed reset time and its time zone;
• any available banked reset or instant-reset offer, including an expiry if shown;
• the active model and reasoning mode, if shown;
• the Codex CLI version and the time you ran the check.

/status is thread-scoped interactive information. Do not build a CI monitor around codex status unless your installed version explicitly provides a supported machine-readable command.

The app-server protocol documents the same concepts as structured rate-limit fields: a percentage used, a window duration, a Unix reset timestamp, and available reset credits. That is useful for understanding the data model, but it is not a promise that every client exposes every field in the same screen.

Why the reset time can change#

There are three expected state transitions and one mismatch to separate:

1. An included limit refreshes. A 5-hour or weekly window can refresh without creating a banked entitlement or adding credits.
2. A banked reset is redeemed. The saved reset can refresh eligible windows and change the weekly reset date; it is not a flexible balance.
3. A paid instant reset is applied. The weekly period is anchored by the first Work or Codex request after application, so the next date may move even when the payment happened earlier.
4. The service changes or corrects the account state. A usage correction, delayed entitlement update, or backend mismatch can change the next reset shown by the client. That is different from an expected reset transition.

Use the observation—not only the displayed hour—to choose the next step:

Do not infer a reset schedule by comparing only the hour on two screenshots. Keep the date, time zone, remaining percentage, and whether a reset was redeemed together. A moving timer by itself does not show that usage was miscounted; a rejected request while both the dashboard and /status show remaining quota is a separate mismatch worth recording.

When Codex rejects a request even though quota remains#

The open Codex issue “You’ve hit your usage limit” but usage dashboard and /status both show 43% is a useful example of the evidence to collect. It reports a visible remaining percentage, an immediate limit error, and a reset timestamp. The issue is a report, not confirmation that every account has the same bug.

Use this order when the same symptom appears:

1. Run /status again in the same thread and save the output without publishing account identifiers.
2. Refresh the usage page in the same account and note whether the 5-hour and weekly values changed.
3. Start a small new session only after recording the original state. A new thread can have different thread-scoped context, but it is not a guaranteed quota repair.
4. Check the exact limit banner: it may offer credits, a reset, an upgrade, or a reset time.
5. If the two views still disagree, report the timestamp, time zone, CLI or app version, model, plan, exact error, and redacted /status output to OpenAI support or the official repository.

Avoid spending a banked reset as a blind test. If the problem is an account-state mismatch, consuming the reset can make the evidence harder to interpret and may not fix the rejected request.

Plan long tasks around checkpoints#

The usage page is most useful before a long task, not only after the limit error. For work that may run for a while:

• save the current diff or checkpoint before starting a large refactor;
• split discovery, implementation, and verification into resumable turns;
• keep a short note of the model, effort, and repository scope used by the task;
• stop and record the state when the remaining percentage changes unexpectedly;
• keep a second provider or a local verification path available for work that can safely continue elsewhere.

If you need a separate CLI provider while waiting for a Codex window, the OpenCode Go provider setup is a different authentication and model-selection path. It does not share Codex’s quota, so treat it as a separate workflow rather than a way to repair the OpenAI account state.

The takeaway is simple: a Codex reset date is part of a rolling account state. Read /status and the usage page together, preserve the evidence when they disagree, and choose a reset, credits, or waiting only after you know which limit you actually reached.

FAQ#