Quota windows anchor to first post-reset use, causing lost subscription time

Summary

Normal Codex usage windows appear to anchor to the first request after a reset/blackout, rather than to the scheduled reset boundary. This can cause users to lose paid subscription time when they do not use Codex immediately after a reset.

This report is about the normal quota-window behavior. It is separate from surprise/bonus mid-week resets, which are a different product behavior and now have a partial answer via banked/user-triggered resets.

Weekly window example

Suppose my weekly Codex usage resets on June 14 at 5:00 PM.

If I do not use Codex again until June 20, the next weekly reset appears to become June 27 instead of June 21.

That means the period from June 14 to June 20 provided no usable benefit from the weekly subscription allowance. The seven-day quota window was effectively delayed until first use, causing six days of paid weekly access to be lost.

5-hour window example

The same behavior appears to affect 5-hour windows.

Suppose a 5-hour window refreshes at 9:00 AM, but I do not send a prompt until 11:00 AM. The next 5-hour reset appears to move to 4:00 PM instead of 2:00 PM.

This creates a bad incentive: users are encouraged to send keepalive/ping prompts just to open the next quota window at the start of their workday, even when they do not actually need Codex yet.

Expected behavior

Quota windows should be deterministic and should begin when the previous quota window resets, not when the user sends their first prompt after that reset.

For the weekly window:

• If the previous weekly window ends on June 14 at 5:00 PM, the next window should run from June 14 at 5:00 PM to June 21 at 5:00 PM.
• The next reset should not depend on whether the user sends their first post-reset prompt immediately, one day later, or six days later.
• The reset timestamp shown in /status and the usage dashboard should be deterministic and stable.

For the 5-hour window:

• If a 5-hour window refreshes at 9:00 AM, the next 5-hour window should be anchored to that refresh boundary.
• It should not be necessary to send a dummy prompt to avoid losing useful workday coverage.

Actual behavior

The next reset appears to be calculated from first Codex usage after a reset/blackout, not from the prior reset boundary.

This causes users who do not immediately use Codex after reset to lose time from the paid allowance.

Why this matters

This makes "weekly limit" and "5-hour limit" misleading. The product behaves less like a fixed subscription allowance and more like "seven days/five hours starting from the next time you remember to use it."

It also creates avoidable load. If users learn that first-use anchoring affects reset timing, rational users will run scheduled keepalive prompts just to preserve window timing. That is worse for users and for OpenAI.

Relevant citations and related reports

An OpenAI Community thread includes a user quoting OpenAI support-bot guidance that the Codex weekly timer usually starts when the model is first used for that cycle:

https://community.openai.com/t/weekly-limit-for-codex-how-can-i-determine-when-it-ends-resets/1359565

That may explain the observed behavior, but it also confirms the product issue: users can lose paid subscription days when the quota window is anchored to first use instead of the scheduled reset boundary.

A closely related GitHub issue asks for weekly resets to be deterministic and says the weekly reset clock should not be based on "the time of the first prompt after the blackout period":

https://github.com/openai/codex/issues/9508

A comment on that issue reports running a codex-keepalive scheduler that opens 5-hour windows shortly after each 5-hour reset with a short ping. That is a strong signal that the first-use anchoring problem also affects the 5-hour window:

https://github.com/openai/codex/issues/9508

There is also a Reddit thread where users describe the 5-hour reset as occurring "5h after your first usage" and discuss sending a trivial prompt at the start of work to move the next reset earlier:

https://www.reddit.com/r/codex/comments/1sxwg8w/when_does_5h_limit_reset/

Official Codex pricing docs describe local messages and cloud tasks as sharing a five-hour window and note that additional weekly limits may apply, but do not clearly document first-use anchoring:

https://developers.openai.com/codex/pricing

Distinction from bonus or unexpected resets

This issue is not about surprise mid-week resets, milestone resets, or banked bonus resets.

Those are separate from the normal deterministic reset behavior. This report is about what happens after the normal weekly or 5-hour quota window resets: the next window appears to be anchored to the first post-reset request, causing lost usable time.

Proposed semantics

To answer the open questions from #9508:

Canonical reset anchor

The quota window should be anchored to the prior scheduled reset boundary, not to first post-reset use.

I am not strongly opinionated about whether the canonical weekly anchor is:

• account creation time,
• plan activation time,
• prior weekly reset timestamp, or
• a fixed global boundary such as Monday 00:00 UTC.

The important requirement is that it must be deterministic, visible, and advance by exactly the documented window length from the previous boundary.

Backend vs display-only fix

This needs to be a backend enforcement change, not only a client display change.

If /status displays a deterministic reset but the backend still enforces first-use anchoring, users will still lose time. A display-only fix would make the UI cleaner but would not solve the subscription-usage loss.

Fixed calendar vs rolling window

Either model is acceptable if documented and enforced consistently:

• Fixed calendar schedule: reset every week / five hours at a known account or global boundary.
• Rolling schedule: each window runs exactly seven days / five hours from the prior reset boundary.

What is not acceptable is "rolling from first post-reset use," because it turns unused time after reset into lost paid access and incentivizes synthetic keepalive traffic.