Codex CLI: /usage “redeem/reset limit” shows applied, but “usage limit reached” persists (macOS, codex-cli 0.145.0)

Open 💬 5 comments Opened Jul 23, 2026 by leeys-dnulbo
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.145.0

What subscription do you have?

Pro x20

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Mac OS Tahoe

What terminal emulator and version are you using (if applicable)?

cmux

Codex doctor report

What issue are you seeing?

When I run /usage in Codex CLI and choose “redeem/reset limit …”, the CLI indicates the reset was applied, but I still see “usage limit reached” in the CLI and on web even after ~1 hour. Logging in on the web does not change the state, so it doesn’t look like a session cache issue.

What steps can reproduce the bug?

Open Codex CLI

Ensure you are in a “usage limit reached” state

Type /usage

Choose the option to “redeem/reset limit …”

Observe the “applied/success” message

Attempt to use Codex again (still blocked). Also check the web UI (still blocked).

What is the expected behavior?

After consuming an earned reset, the eligible Codex rate-limit window should be reset, and after refreshing limits (via account/rateLimits/read) the CLI/web should reflect that usage is no longer blocked.

Additional information

_No response_

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 month ago

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

  • #33744
  • #33837
  • #34323
  • #34360
  • #34391

Powered by Codex Action

jmrpineda · 1 month ago

Additional report from another Codex Desktop user (2026-07-23):

  • A usage reset appears to activate successfully.
  • Codex Desktop shows 100% remaining in the usage indicator.
  • New chats are still rejected with a usage-limit error.
  • The web usage/Analytics page also fails to load the graphs and shows an error.
  • The problem persists across the app and the web UI, so it does not appear to be only a local UI/session cache issue.

Please check whether the reset is updating the displayed allowance but not the backend rate-limit state, and whether the Analytics endpoint is failing for the same account state.

jmrpineda · 1 month ago

This does not appear to be an isolated report. Related open reports describe the same reset/allowance inconsistency across multiple platforms and clients:

  • #33744 — redeemed reset reported as successful but not applied (Windows / CLI)
  • #33837 — Codex Desktop shows 100% after reset, but the allowance does not actually increase (macOS / app)
  • #34323 — reset briefly shows 100% and then falls back to the previous exhausted state (Windows / app)
  • #34360 — usage-limit error persists while the UI reports ~99% remaining (Windows / app)
  • #34391 — usage reset does not work (macOS / CLI)

The additional Analytics failure and the cross-client blocking suggest this may be a backend/account-state issue rather than a client-only display problem.

Gelloiss · 25 days ago

<img width="1105" height="693" alt="Image" src="https://github.com/user-attachments/assets/f5bcc7a4-3656-4707-b677-9bf5989f62a9" />
I’m experiencing the same issue on a paid ChatGPT Plus account, but I can add an important detail regarding purchased credits.

My Codex app showed 100% Weekly usage remaining, while every model returned:

“You’ve hit your usage limit. Upgrade your plan or add credits to continue, or try again at Aug 10, 2026, 5:59 AM.”

I tested multiple models, restarted the app, signed out/in, and the issue persisted.

Because I was in the middle of a work task and needed to continue, I purchased additional Codex credits.

Immediately after purchasing credits, Codex started working again.

I have now confirmed that Codex is consuming my purchased credits while the Usage page still shows 100% of my Weekly included usage remaining.

So this does not appear to be only a UI/display issue. The backend seems to treat my included subscription allowance as exhausted/unavailable while the usage service reports it as 100% available, and consequently bills usage against purchased credits.

I have also opened an OpenAI Support case and it has been escalated to a support specialist.

I can provide screenshots showing:

  • 100% Weekly usage remaining;
  • the simultaneous “usage limit reached” error;
  • purchased credits being consumed while Weekly remains at 100%.

This appears to be an entitlement / usage-accounting synchronization issue with billing impact.

wwdbsh · 23 days ago

Same failure here on every GPT-5.6 model - sol, terra, and luna are all blocked - and I think I can narrow down what is happening: the retry time in the error belongs to the pre-reset window, not the window being displayed.

I redeemed a banked reset on Aug 5 at ~13:11. Afterwards:

| Source | Reset time | Implied window start (-7d) |
|---|---|---|
| /status weekly limit (93% left) | Aug 12, 13:11 | Aug 5, 13:11 - when I redeemed the reset |
| Error message retry time | Aug 9, 8:30 | Aug 2, 8:30 - my pre-reset window |

So the reset did provision a new weekly window on the quota/display side, but the enforcement path appears to still be evaluating against the exhausted pre-reset window. That would explain why the "applied" message and the block are both truthful - they are reading different windows. It also fits the reports in this thread where the error's retry timestamp does not line up with the reset time shown in the UI.

Model isolation

I tested every model available to me:

| Model | Result |
|---|---|
| gpt-5.6-sol (reasoning high) | blocked |
| gpt-5.6-terra | blocked |
| gpt-5.6-luna | blocked |
| gpt-5.3-codex-spark | works normally |

Every GPT-5.6 model is blocked. Spark draws from its own bucket (100% remaining, resets Aug 12 15:31) and is unaffected. So it is not model-specific: everything drawing from the shared weekly pool is blocked, which rules out an account-level block and points at that one pool's enforcement record.

Both clients

Reproduced identically in Codex CLI and the Codex desktop app on the same account, consistent with the cross-client reports already collected above.

Current state

Banked reset consumed (settings now reads "No resets available"), 93% provisioned, 0% usable, 0 credits remaining so no fallback path. Following the report above about purchased credits being billed while the included weekly allowance stays at 100%, I have deliberately not purchased credits.

Screenshots

My dashboard is in Korean, so for reference: 주간 사용 한도 = weekly usage limit, 남음 = remaining, 초기화 = resets at, 남은 크레딧 = remaining credits, 사용 한도 초기화 = usage limit resets, 사용 가능한 초기화 없음 = no resets available.

1. Codex CLI /status - weekly limit 93% left, resetting Aug 12 13:11, while the usage-limit error at the bottom names Aug 9 8:30. Account email redacted.

<img width="808" height="447" alt="Image" src="https://github.com/user-attachments/assets/35d0112a-6d83-4858-ab64-89918f2e1009" />

2. Web usage dashboard - weekly 93% remaining resetting Aug 12, Spark 100% remaining, remaining credits 0.

<img width="1316" height="627" alt="Image" src="https://github.com/user-attachments/assets/fb66c532-166d-4d7c-b2d8-a35ad090c784" />

3. Settings - no resets available, i.e. the banked reset was consumed.

<img width="948" height="190" alt="Image" src="https://github.com/user-attachments/assets/50a189c5-fe04-4b93-a0d3-e2ab4c0cf393" />

Suggested check

Comparing the window returned by the quota service for account/rateLimits/read against the window the enforcement path uses on a rejected request should show the divergence directly. The two reset timestamps being exactly 7 days apart from different start points is the visible symptom.

Environment

Pro Lite, codex-cli 0.144.5, macOS, Codex desktop app.
Models tested: gpt-5.6-sol (reasoning high), gpt-5.6-terra, gpt-5.6-luna, gpt-5.3-codex-spark.
Session ID: 019fd09e-3a8a-7e33-a355-80652eb6e7b8