Codex Reset Date Keeps Moving: Check the Seven-Day Usage Window

Separate the three usage states#

These labels are easy to mix up:

OpenAI’s current Codex usage guidance says usage varies with the task, model, context, and where the task runs. It also lists waiting, applying an available reset, adding credits, or upgrading as separate options. Treat the option shown for your plan as authoritative instead of copying a reset rule from another account.

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;
• 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 two different causes:

1. A rolling window starts at a different time. OpenAI Support has explained that the weekly limit is seven days rather than a fixed calendar week. After a reset, the next window can be anchored to the next Codex use, so the displayed time can move.
2. The service changes or corrects the account state. A product-wide reset, a usage correction, or a delayed entitlement update can change the next reset shown by the client. That is different from a normal request consuming a fixed weekly bucket.

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#