Implement backoff policy when 429 would have happened
Resolved 💬 5 comments Opened Feb 11, 2026 by anupammukherjee Closed Apr 3, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What variant of Codex are you using?
CLI
What feature would you like to see?
We get the 429 error when we exceed some number of requests per minute. When orchestrating multi-agent workflows, maybe we can set some parameter to artificially slow down requests till it meets the 20 req/min threshold rather than returning the error to facilitate hands-free workflows. Basically, I, as a human, don't want to have to wait for a while and re-issue the last command. Instead it would be much more useful to have it slow down the interval between requests and meet the rate limit without facing the 429 error.
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
Thanks for the suggestion.
Some context that might be useful... There are different reasons a 429 can be generated. The most common reasons are non-recoverable and therefore should not be retried. Also, 429 reasons differ across model hosters (OpenAI vs Azure, for example), which makes it challenging to distinguish between recoverable and non-recoverable variants. For those reasons, we currently treat all 429s as non-recoverable. We could look at adding more logic to attempt to distinguish.
Thanks, that would be helpful. Mainly I was looking at this to help reduce context bloat by spawning sub-agents to do some work. In this context, I want the work to mostly be automated and my prompt specifies this. Thus, it is OK for me if the task runs a little longer but not if it errors out espacially in cases where the error is not fatal.
@etraut-openai Can Codex have a config option where the user can decide on whether they want to use exponential backoff for their codex session? I get that 429 reasons differs by provider, however the user should have the option to decide on what to do there.
This feature request hasn't received enough upvotes, so closing.