exceeded retry limit, last status: 429 Too Many Requests

Resolved 💬 10 comments Opened Feb 24, 2026 by nbreton Closed Feb 24, 2026

💡 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)?

Version 26.217.1959 (669)

What subscription do you have?

Pro

What platform is your computer?

Mac OS

What issue are you seeing?

exceeded retry limit, last status: 429 Too Many Requests, request id: b48b3c09-ab0a-421f-87e4-e5263e39fe54

What steps can reproduce the bug?

Start any prompt

What is the expected behavior?

Should work as designed

Additional information

_No response_

View original on GitHub ↗

10 Comments

github-actions[bot] contributor · 4 months ago

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

#12674

Powered by Codex Action

adauvalter · 4 months ago

I have the same behavior right now in the codex app on macos, Version 26.217.1959 (669)
exceeded retry limit, last status: 429 Too Many Requests, request id: 37c563e3-93c5-4161-9081-8871265a7180

YoanBLGR · 4 months ago

same

roqu1 · 4 months ago

Same error i am getting in the codex cli itself. request id: 97cec234-d094-4976-a6a8-85359c87a712
Thread ID:019c8f5e-9438-7ec2-9600-45ab9fda34ab

etraut-openai contributor · 4 months ago

This appears to have been a short-lived server-side issue. It appears to be mitigated.

rachaelsingleton · 4 months ago

I just started experiencing this issue this morning.

prrao87 · 4 months ago

Same here. My rate limits in the Codex app show 97% daily and 90% weekly limits remaining, but I still get a 429 too many requests error.

mysportsbetnow24 · 4 months ago

Getting the same issue myself will plenty of daily and weekly limits remaining.

gabepsilva · 4 months ago

This appears to have been a short-lived server-side issue. It appears to be mitigated.

Yesterday it was working fine! Today I started getting it.
It is confirmed it is a server side issue? (apparently it is but, is it confirmed?)

SirBrenton · 4 months ago

This looks like a classic case where a 429 (rate limit) is being surfaced as “retry exhausted,” while the UI still shows quota remaining.

Important distinction:
Quota remaining ≠ not rate-limited.
429 can be triggered by burst / per-minute / per-route / per-model / per-org throttles even when daily/weekly quota is high.

If helpful, I’ve been standardizing a small execution contract around:

retry budget (max attempts, max elapsed)
respecting Retry-After
classification (429 vs quota exhaustion vs auth)
cooldown scope (model vs provider vs credential)

Tiny ask (no secrets needed):
Could someone paste ~10–20 lines of redacted logs for one failed attempt including:

HTTP status
whether a Retry-After header was present (and value, if so)
total attempts before failure
elapsed time across retries

No tokens/URLs required — just status + retry timing.

That’s enough to determine whether this is:

burst throttling not reflected in UI,
Retry-After not being honored,
retry envelope too small,
or a broader server-side throttle.

Happy to map it into a normalized receipt and summarize the likely limiter dimension.