Codex CLI: /usage “redeem/reset limit” shows applied, but “usage limit reached” persists (macOS, codex-cli 0.145.0)
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_
5 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Additional report from another Codex Desktop user (2026-07-23):
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.
This does not appear to be an isolated report. Related open reports describe the same reset/allowance inconsistency across multiple platforms and clients:
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.
<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:
This appears to be an entitlement / usage-accounting synchronization issue with billing impact.
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) |
|---|---|---|
|
/statusweekly 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/readagainst 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