Codex weekly usage meter switches to inconsistent reset window

Open 💬 3 comments Opened May 17, 2026 by tsungxu

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex Desktop appears to switch the weekly subscription usage meter between inconsistent secondary rate-limit windows. In one local session log, the weekly bucket was 27% used with a reset on May 23. Roughly two hours later, a fresh thread reported the same secondary.window_minutes: 10080 bucket as 99% used with a reset on May 18. The reset timestamp moved backward by about five days.

This surfaced in the UI as weekly Codex usage jumping from about 75% remaining to about 1% remaining shortly after the user believed the subscription usage had recently reset.

Environment

Product: Codex Desktop
Originator in log: Codex Desktop
CLI version in log: 0.131.0-alpha.9
Plan type in rate-limit payload: pro
Local timezone: America/Los_Angeles
Date observed: May 17, 2026

Evidence from local session logs

Earlier same day:

{
  "timestamp": "2026-05-17T18:25:31.464Z",
  "rate_limits": {
    "limit_id": "codex",
    "secondary": {
      "used_percent": 27.0,
      "window_minutes": 10080,
      "resets_at": 1779571027
    },
    "plan_type": "pro"
  }
}

1779571027 corresponds to May 23, 2026 14:17:07 local time.

Later same day, in a fresh projectless thread:

{
  "timestamp": "2026-05-17T20:20:06.727Z",
  "rate_limits": {
    "limit_id": "codex",
    "secondary": {
      "used_percent": 99.0,
      "window_minutes": 10080,
      "resets_at": 1779144603
    },
    "plan_type": "pro"
  }
}

1779144603 corresponds to May 18, 2026 15:50:03 local time.

Why this looks wrong

Both payloads report secondary.window_minutes: 10080, which appears to be the weekly Codex usage window. But the reset timestamp moved backward from May 23 to May 18. If this is a single weekly subscription usage bucket, that should not happen.

Possible explanations:

The UI/backend is switching between different quota buckets while labeling both as weekly usage.
One of the resets_at timestamps is wrong.
A new thread is being attached to an older near-expired quota bucket.
secondary is not actually the subscription weekly allowance, but the UI presents it as such.

Relevant local log paths

Redacted local paths on the affected machine:

~/.codex/sessions/2026/05/17/rollout-2026-05-17T11-25-29-019e372f-a50a-7441-aa1b-87243bedfcd9.jsonl
~/.codex/sessions/2026/05/17/rollout-2026-05-17T13-19-53-019e3798-5ea5-7b01-bf43-d26b50270cbd.jsonl

I can provide more surrounding log excerpts if helpful.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#23188
#23063
#22282

Powered by Codex Action

astandrik · 3 months ago

After announcements of resetting limits my limits were reset yesterday
However now they are back to the state that was before reset

not sure if its relevant to current issue, but no idea where to report it to

hyang214 · 2 months ago

Adding CLI/TUI evidence for the same class of issue, with a narrower reproduction path.

Environment observed locally:

Codex CLI: 0.134.0 (@openai/codex latest on npm was 0.135.0 when checked)
Plan type in payload: pro
Model: gpt-5.5
Platform: Darwin 25.4.0 arm64 arm
Terminal: Warp v0.2026.05.06.15.42.stable_05
Local timezone: Asia/Shanghai
I also checked current main source at cf09110, and the relevant display/state behavior is still present there.

What I observed in redacted local rollout data:

new rollout outer timestamp: 2026-05-31T15:48:41.750Z
codex secondary: used_percent=12.0, window_minutes=10080, resets_at=1780279984
local reset: 2026-06-01 10:13:04 Asia/Shanghai

same rollout after live refresh: 2026-05-31T15:48:55.508Z
codex secondary: used_percent=1.0, window_minutes=10080, resets_at=1780846002
local reset: 2026-06-07 23:26:42 Asia/Shanghai

The first snapshot appears to be historical/replayed state from a forked/resumed thread, but because the new rollout record has a fresh outer timestamp, it is easy for /status or the status line to present it as current until a live rate-limit refresh arrives. That makes the weekly meter jump from one reset window/remaining percentage to another within seconds.

Reproduction path that does not require Desktop:

Have an existing recorded session under ~/.codex/sessions/... that contains TokenCount events with rate_limits.
codex fork <SESSION_ID> or resume/fork it from the TUI.
Immediately inspect /status or the configured status-line rate-limit items before a live refresh completes.
Send a small prompt or run /status again so account/rateLimits/read returns fresh data.
Compare secondary.window_minutes=10080, used_percent, and resets_at before and after the refresh.

Expected behavior:

Replayed/historical rate-limit snapshots should not be shown as current account state, or they should carry their original capture time and be clearly marked stale.
/status should avoid rendering a stale weekly reset/remaining value as current while the live account rate-limit refresh is pending.

Relevant source pointers from current main:

codex-rs/protocol/src/protocol.rs: RateLimitSnapshot / RateLimitWindow include resets_at, but no snapshot capture timestamp.
codex-rs/tui/src/chatwidget/rate_limits.rs: on_rate_limit_snapshot converts any received snapshot into display state using Local::now() as the capture time.
codex-rs/tui/src/chatwidget/slash_dispatch.rs: /status can render existing cached rate-limit state before the async refresh completes.
codex-rs/tui/src/status/rate_limits.rs: stale classification depends on the TUI-side capture time, so replayed snapshots can look fresh if they are reprocessed now.

This may explain both the Desktop report here and CLI/TUI cases where the weekly reset appears to move between unrelated windows.