Repository navigation
Limit reset used but not applied #44217
Description
What version of Codex CLI is running?
codex-cli 0.153.4 (same behaviour in the Codex desktop app on the same account)
What subscription do you have?
ChatGPT Pro
Which model were you using?
gpt-6-astra, medium reasoning
What platform is your computer?
macOS, Darwin 25.6.0 arm64
What terminal emulator and version are you using (if applicable)?
No response
Codex doctor report
What issue are you seeing?
Two separate problems with weekly usage limits on 2026-09-09, both measured from
payload.rate_limits in the session rollout files (window_minutes = 10080). The values
are identical across concurrent CLI and desktop sessions on the same account, so this
is server-side state, not a client display glitch.
-
Requests are refused while the reported state says the limit is NOT reached.
17:06:24Z a fresh codex-tui turn failed with:
"You've hit your usage limit. Visit .../settings/usage to purchase more
credits or try again at Sep 14th, 2026 6:43 AM."
17:06:59Z rate_limits snapshot for the same account, 35 seconds later:
{"limit_id":"codex",
"primary":{"used_percent":25.0,"window_minutes":10080,"resets_at":1789361043},
"secondary":null,
"credits":{"has_credits":false,"unlimited":false,"balance":"0"},
"rate_limit_reached_type":null,"plan_type":"pro"}
resets_at 1789361043 is exactly the "Sep 14th 6:43 AM" quoted in the refusal, so
both refer to the same weekly window. -
Redeeming a usage-limit reset does not restore the allowance to 0%, and the second
redemption moved the window end ~21 hours EARLIER than the window it replaced:
09:33Z used 82% resets_at = 2026-09-15 03:34 (local)
09:57Z used 27% resets_at = 2026-09-15 03:26 (local) <-- after redemption 1
16:54Z used 73% resets_at = 2026-09-15 03:26 (local)
16:56Z used 22% resets_at = 2026-09-14 06:44 (local) <-- after redemption 2
17:04Z used 24% (climbing normally afterwards)
What steps can reproduce the bug?
- Use a ChatGPT Pro account until the weekly Codex limit is near exhaustion.
- Redeem an available usage-limit reset. Observe in the rate_limits snapshots that
usage drops to ~22-27% instead of 0%, and that resets_at moves to a new value. - Keep working normally for a few minutes.
- Start a new codex CLI session and send any prompt. The turn fails with
"You've hit your usage limit ... try again at <resets_at of the current window>",
while the rate_limits payload for the same window reports ~25% used and
rate_limit_reached_type = null.
What is the expected behavior?
Either the request is served while the reported usage is 25%, or the reported state
shows the limit as reached. A redeemed reset should restore the weekly allowance to
~0% and must never move the window end earlier than the window it replaces.
Additional information
The account has no purchased credits (balance 0), so "purchase more credits" is the
only remedy offered on an otherwise plan-covered account. Related open reports:
#31532, #33118, #37396, #41969.
Activity
github-actions commentedon Sep 9, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
applicate2628 commentedon Sep 9, 2026
Adding a closely related Pro 20x account case from Sep 9, 2026. I am closing my separate report #44240 as a duplicate and consolidating the evidence here.
Observed sequence:
@codex reviewrequests plus 79 issue-level@codexrequests. I therefore do not claim the 40-vs-371 comparison by itself proves incorrect charging.Provided git ref ... does not existafter PR heads changed.That last observation makes this look less like simple fast consumption and more like a server-side reset/reconciliation event. The combination I observed was therefore:
Full banked reset redeemed -> old weekly reset anchor remains -> allowance reaches 0 -> allowance later recovers on its ownPlease include this account timeline when reconciling the Sep 9 reset incident. I can provide screenshots privately, including the Usage reset timestamp and PR-review analytics.