Repository navigation
[CLI][WSL] Repeated retry-exhausted HTTP 429 with only 3 active sessions and 69% allowance remaining #54010
Description
Summary
Codex CLI repeatedly stops with:
exceeded retry limit, last status: 429 Too Many Requests
The user reports only 3 active sessions and a usage display showing 69% remaining when reporting this problem. The errors continue despite this apparently low session concurrency and substantial displayed allowance.
This is not a claim that the displayed allowance rules out every short-term rate limit or that session count equals the number of in-flight backend requests. The UI does not provide enough information to identify the applicable limit or distinguish throttling from a service/capacity error.
Environment
- Client: Codex CLI in WSL on Windows.
- Current CLI version verified locally while preparing this report:
codex-cli 0.160.0. This is not independent verification of the version at every earlier failure. - Latest report: October 15, 2026, Asia/Seoul (UTC+9). Exact wall-clock timestamps of failed requests were not captured.
- Subscription tier, affected model/reasoning configuration, and allowance window: not independently verified for this report.
Observed behavior
- Use Codex for ordinary development work in separate sessions.
- Only 3 sessions are reported as actively used.
- Account usage display reportedly shows 69% remaining.
- Multiple attempts nevertheless end with the retry-exhausted HTTP 429 message above.
This is repeated user-observed behavior, not a deterministic minimal reproduction. No request IDs, Retry-After header, detailed rate-limit error code, or diagnostic feedback ID have yet been collected. No claim is made that model inference, compaction, or automatic review is the specific failing request path.
Expected behavior / requested investigation
- Investigate repeated HTTP 429/retry exhaustion under these conditions.
- Identify which limit or backend condition rejected the request, rather than leaving users to infer it from the remaining-allowance display.
- Where applicable, expose an actionable retry time and distinguish exhausted allowance, short-term throttling, reviewer limits, and temporary capacity/service failures.
- Clarify the supported diagnostic information needed to correlate these failures privately.
Related reports
- Windows Codex Desktop: HTTP 429 across multiple tasks while ~70% of weekly allowance remains #53978 reports HTTP 429 with approximately 70% allowance remaining on Windows Desktop.
- [Windows][Pro] Critical Codex performance degradation, stalled agents and repeated HTTP 429 errors #54004 reports repeated 429 and performance degradation with allowance remaining.
These have similar symptoms but do not establish that the CLI report shares their root cause.
Privacy and evidence boundaries
This public report contains no project source, raw conversation logs, private session/account identifiers, email addresses, credentials, or private filesystem paths. The 69% figure and active-session count are user-reported observations; they are not a backend quota audit. This report was submitted at the user's explicit request.
Activity
github-actions commentedon Oct 14, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
roy-tong commentedon Oct 15, 2026
Repeated 429-exhaustion with only 3 parallel sessions is worth reading at the retry level rather than the session level: each retry of a failed call re-sends its working context, so a burst of 429 loops can burn far more of your quota than the session count suggests. From auditing agent usage tooling, retry amplification is the single most common multiplier. If you want to see it in your own rollout files:
pip install agentmeasurethenagentmeasure checkreports retry chains and their execution counts locally - nothing uploaded. If it shows e.g. '5 executions carry 1 logical operation' on the 429 loops, that's the multiplier made visible and usually points at backoff tuning as the fix.khuyendev commentedon Oct 15, 2026
Hello OpenAI Support Team,
I'm a ChatGPT Pro subscriber ($200/month), and I'd like to report a significant regression in Codex performance and reliability that started around October 11, 2026.
I'm experiencing these issues while using the official Codex application, primarily with GPT-6.1 Sol.
Issues observed:
I've found numerous similar reports from other ChatGPT Pro subscribers on the official Codex GitHub repository:
Could you please investigate and clarify the following?
As a paying Pro subscriber, reliable performance and predictable concurrency limits are important for my development workflow.
The combination of frequent 429 errors and substantially slower response times is significantly affecting my productivity.
I would appreciate a technical investigation rather than a generic rate-limit explanation, especially given the number of similar reports from other subscribers.
Thank you for your assistance. I can provide diagnostic logs, request IDs, and timestamps if needed.
Best regards