›_ Codex Issues
Codex Issues / #26370

Codex Desktop usage-limit meters start at 99% instead of 100%

Open 💬 7 comments Opened Jun 4, 2026 by claell
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From "About Codex" dialog)?

Codex Desktop, current build observed on 2026-06-04.

Exact app version was not captured yet.

What subscription do you have?

Unknown / not confirmed. The issue is visible in the Codex usage-limit UI.

What platform is your computer?

Windows desktop app.

What issue are you seeing?

The usage-limit percentages in Codex Desktop appear to start from 99% instead of 100%.

For example, after the 5-hour usage window should be fully available, the UI shows the 5-hour limit as 99% rather than 100%. This appears to be a regression: the same UI used to show a freshly available usage window as 100%.

I am not sure whether this is only a presentation/rounding bug in the desktop UI or whether the underlying usage-limit snapshot is now reporting a value that is already one percentage point lower than the true full limit. Either way, a fresh/full window should not appear partially consumed before any new work is done.

What steps can reproduce the bug?

  1. Open Codex Desktop.
  2. Wait until the 5-hour Codex usage window has reset / should be fully available.
  3. Open or inspect the usage-limit UI.
  4. Check the displayed 5-hour usage-limit percentage.

Observed result:

  • The 5-hour usage limit starts at 99%.

Expected result:

  • A fresh/full 5-hour usage window starts at 100%.

What is the expected behavior?

Codex Desktop should display fully available usage windows as 100%, as it did previously.

If the UI is showing remaining capacity, it should not round or clamp a full bucket down to 99%.

If the UI is showing consumed capacity, the label should make that explicit and a fresh/full bucket should display 0% used rather than an ambiguous 99%.

Additional information

I searched existing openai/codex issues before filing this.

Closest but not exact matches:

  • #24445: Codex Desktop shows an out-of-messages banner while Analytics reports 99% remaining. That appears to be about a false exhausted/banner state, not the usage meter starting one point below full.
  • #24274: compact status-line labels for 5h/weekly limits were ambiguous and a maintainer said a label fix would be implemented. That issue was about label semantics, not a full/reset window rendering as 99% instead of 100%.
  • #14593 and #23671: broad reports of quota draining too quickly. The issue here may be only a UI/regression in how full usage-limit windows are displayed.

This report is intentionally scoped to the off-by-one display/regression: a fully available 5-hour window should start at 100%, not 99%.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 1 month ago

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

  • #25483

Powered by Codex Action

cssbruno · 1 month ago

One minute after yesterday’s reset, it was already at 98%. On 20x pro plan

arctouch-leecooper · 1 month ago

Confirming this on a ChatGPT Team workspace seat (observed June 12, 2026). The issue is not just UI rounding — /backend-api/wham/usage itself returns "used_percent": 1 on the 5-hour primary_window while the account is fully idle: no Codex clients running, and daily-token-usage-breakdown shows zero usage events for the day. Also reset_after_seconds stays pinned at 18000 (reset_at is always "now + 5h"), so the displayed reset time is meaningless. A personal (non-workspace) account checked the same way correctly reports used_percent: 0 / 100% remaining. Symptom began around early June.

pylrn · 1 month ago

i have this exact problem as well. im noticing my weekly and hourly usage also slowly decrementing a little by little in spite of not using it.

faithzjy · 29 days ago

我发现我的Codex自动重置了5小时使用限额后，剩余用量显示是99%或者98%，而不是100%，这让我感到困惑

mperezjodal · 21 days ago

I am seeing what looks like the same 5-hour usage-window class of bug on macOS Codex App, with one extra UI symptom: after the 5-hour window reaches its reset boundary and the meter replenishes, the next reset label can render as now instead of the next concrete reset time.

Environment:

  • Codex App: 26.623.61825
  • Embedded CLI: codex-cli 0.142.3
  • Platform: Darwin 25.5.0 arm64 arm
  • macOS: 26.5.1 (25F80)
  • Plan: ChatGPT Pro

Observed behavior:

  • The 5-hour limit reached the reset boundary.
  • The usage meter returned to 100%.
  • The reset label showed now instead of the next reset time for the newly available 5-hour window.

Expected behavior:

  • Once the 5-hour window replenishes, the reset label should advance to the next concrete reset time/date.
  • If the backend snapshot has not yet advanced, the app should avoid rendering now as the next reset because it reads as a stale/immediately expiring window.

I also checked recent local Codex session rate_limits metadata, extracting only the quota fields and omitting conversation content. These snapshots show the same primary 300-minute window moving across the day:

2026-06-28T23:36:30.031Z  primary.used_percent=100  primary.window_minutes=300  primary.resets_at=2026-06-29T03:39:39Z
2026-06-29T00:26:56.817Z  primary.used_percent=45   primary.window_minutes=300  primary.resets_at=2026-06-29T04:56:11Z
2026-06-29T11:30:10.031Z  primary.used_percent=21   primary.window_minutes=300  primary.resets_at=2026-06-29T16:09:04Z

This may be a related edge case to the existing 99/98% reset behavior in this issue, but the visible symptom I observed is specifically the reset label rendering as now right after the meter replenishes.

claell · 5 days ago

Still not fixed. Without any maintainer response.

@etraut-openai