You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Implement exponential back-off when hitting rate limits #1712
OpenAI has some brutal RPM rate limits on tier 1, which will often abruptly stop opencode and requires me to manually resume by sending 'continue' message.
An exponential back-off with auto-retry would keep the agent loop running, it'd just take a bit longer to complete when rate limits are hit.
If that helps here is error you get when you hit rate limit:
{"type":"error","sequence_number":2,"error":{"type":"tokens","code":"rate_limit_exceeded","message":"Rate limit reached
for gpt-5-mini in organization org-XXXXXXXXXXXXXX on tokens per min (TPM): Limit 200000, Used 124035,
Requested 79017. Please try again in 915ms. Visit https://platform.openai.com/account/rate-limits to learn
more.","param":null}}
Same here:
{"type":"error","sequence_number":2,"error":{"type":"tokens","code":"rate_limit_exceeded","message":"Rate limit
reached for gpt-5 in organization org-************* on tokens per min (TPM): Limit 30000, Used 14582,
Requested 21045. Please try again in 11.254s. Visit https://platform.openai.com/account/rate-limits to learn
more.","param":null}}
After these rate limit stops, what do you type to make it continue? I've not had great luck.. Cerebras is awesome until the brick wall per minute limit
My experience as of today with opencode latest /connected to the OpenAI API @ Tier 1 with model 5.1-codex-mini (200K TPM rate limit), even VERY SIMPLE requests are rate limited and fail every time, making the OpenAI API unusable without throwing money at a higher tier. Anyone solved this without $++ yet?
To state the obvious: exponential backoff means OpenCode waits TWICE THE LENGTH OF TIME it waited the last time on every retry.
This means, after only 7 retries, you wait over a minute.
On the 8th retry, you wait 2 minutes.
I think it should be linear, such as retry after 1 second, then 2 seconds, then 3 seconds, ... up to some kind of user configurable maximum such as 10 or 15 seconds.
"Exponential backoff" seems to be the go-to solution for everything nowadays. Even AI suggests it strongly to me for anything and everything network-related, indiscriminately. I don't know where that came from ... perhaps the 1980s, when networks were really unreliable, and retrying a network backup or something made sense to eventually take hours to make a retry attempt. But nowadays? In 2026? Exponential? Maybe in some low priority cloud services such as backups (even then, why exponential and not linear?), but it really hits the user hard in terms of experience in user-facing apps.
We have backoff for ratelimits, and we respect the retry-after type headers so once it is ready to retry it should automatically go through
Is it possible that this behaviour isn't consistent across providers? I've run into rate limits errors fairly frequently (multiple times per day) using OpenAI models and the agent loop completely stops (ie no retries).
In my case, it happens primarily using gpt-5.2-codex, either directly via OpenAI or via OpenCode Zen.
Example error when using OpenAI provider:
{"type":"error","sequence_number":2,"error":{"type":"tokens","code":"rate_limit_exceeded","message":"Rate limit reached for gpt-5.2-codex in organization org-xyz on tokens per min (TPM): Limit 500000, Used 404104, Requested 107839. Please try again in 1.433s. Visit https://platform.openai.com/account/rate-limits to learn more.","param":null}}
Example error when using OpenCode Zen provider:
{"type":"error","sequence_number":2,"error":{"type":"server_error","code":"rate_limit_exceeded","message":"The model was unable to complete inference due to an internal error.","param":null}}
Is there a way to explicitly configurate RPM limit for certain model in OpenCode.json? Our API Provider lower the some Open sourced models that I want to use.
But right now it keeps hitting Request limit, sign..
Is there a way to explicitly configure RPM limit for certain model in OpenCode.json? Our API Provider lower the some Open sourced models that I want to use. But right now it keeps hitting Request limit, sign..
Yes, I totally agree, we should be able to set by model, in the opencode.json something like
"model_name" :
...
"rateLimit": {
"maxRequests": 20,
"timeWindow": "1m"
}
}
Reacted by technout, 慕雪寒箫, Daniel Marques and pppwaw
Exponential backoff is partially addressed by #26292 which implements cooldown-based fallback (failed providers are skipped for a configurable duration). The header from providers is respected. Full exponential backoff retry on the same provider is a separate concern.
Exponential backoff is partially addressed by #26292 which implements cooldown-based fallback (failed providers are skipped for a configurable duration). The retry-after header from providers is respected. Full exponential backoff retry on the same provider is a separate concern.
Activity
daliusd commentedon Aug 8, 2025
If that helps here is error you get when you hit rate limit:
AlexeyYar commentedon Aug 9, 2025
Same here:
{"type":"error","sequence_number":2,"error":{"type":"tokens","code":"rate_limit_exceeded","message":"Rate limit
reached for gpt-5 in organization org-************* on tokens per min (TPM): Limit 30000, Used 14582,
Requested 21045. Please try again in 11.254s. Visit https://platform.openai.com/account/rate-limits to learn
more.","param":null}}
WilliamAGH commentedon Aug 11, 2025
Yeah, Cerebras and Groq are currently unusable with Opencode right now still because of this.
Constant errors like:
JC1738 commentedon Aug 14, 2025
Same, AI_RetryError: Failed after 4 attempts. Last error: Requests per second limit exceeded - too many requests sent.
cerebras with Qwen 3 Coder 480B
I can't get through the /init without the being blocked by this error, and unfortunately you can't resume the init.
jsugg-qventus commentedon Sep 12, 2025
Same here. On each message.
sra commentedon Dec 9, 2025
After these rate limit stops, what do you type to make it continue? I've not had great luck.. Cerebras is awesome until the brick wall per minute limit
rekram1-node commentedon Dec 9, 2025
We have backoff for ratelimits, and we respect the retry-after type headers so once it is ready to retry it should automatically go through
jcgottlieb commentedon Jan 9, 2026
My experience as of today with opencode latest /connected to the OpenAI API @ Tier 1 with model 5.1-codex-mini (200K TPM rate limit), even
VERY SIMPLErequests are rate limited and fail every time, making the OpenAI API unusable without throwing money at a higher tier. Anyone solved this without $++ yet?tgrushka commentedon Jan 15, 2026
Exponential backoff seems way overkill.
To state the obvious: exponential backoff means OpenCode waits TWICE THE LENGTH OF TIME it waited the last time on every retry.
This means, after only 7 retries, you wait over a minute.
On the 8th retry, you wait 2 minutes.
I think it should be linear, such as retry after 1 second, then 2 seconds, then 3 seconds, ... up to some kind of user configurable maximum such as 10 or 15 seconds.
"Exponential backoff" seems to be the go-to solution for everything nowadays. Even AI suggests it strongly to me for anything and everything network-related, indiscriminately. I don't know where that came from ... perhaps the 1980s, when networks were really unreliable, and retrying a network backup or something made sense to eventually take hours to make a retry attempt. But nowadays? In 2026? Exponential? Maybe in some low priority cloud services such as backups (even then, why exponential and not linear?), but it really hits the user hard in terms of experience in user-facing apps.
shaneqld commentedon Jan 27, 2026
Is it possible that this behaviour isn't consistent across providers? I've run into rate limits errors fairly frequently (multiple times per day) using OpenAI models and the agent loop completely stops (ie no retries).
In my case, it happens primarily using
gpt-5.2-codex, either directly via OpenAI or via OpenCode Zen.Example error when using OpenAI provider:
{"type":"error","sequence_number":2,"error":{"type":"tokens","code":"rate_limit_exceeded","message":"Rate limit reached for gpt-5.2-codex in organization org-xyz on tokens per min (TPM): Limit 500000, Used 404104, Requested 107839. Please try again in 1.433s. Visit https://platform.openai.com/account/rate-limits to learn more.","param":null}}Example error when using OpenCode Zen provider:
{"type":"error","sequence_number":2,"error":{"type":"server_error","code":"rate_limit_exceeded","message":"The model was unable to complete inference due to an internal error.","param":null}}ownself commentedon Feb 1, 2026
Is there a way to explicitly configurate RPM limit for certain model in OpenCode.json? Our API Provider lower the some Open sourced models that I want to use.
But right now it keeps hitting Request limit, sign..
alainivars commentedon Feb 7, 2026
Yes, I totally agree, we should be able to set by model, in the opencode.json something like
"model_name" :
...
"rateLimit": {
"maxRequests": 20,
"timeWindow": "1m"
}
}
abda11ah commentedon Apr 4, 2026
Hi, Please add rate limiter configurable,
e.g : seconds-between-requests : 5
feat(app): add drag and drop reorder to workspace list (anomalyco#1712)
j3k0 commentedon May 17, 2026
Exponential backoff is partially addressed by #26292 which implements cooldown-based fallback (failed providers are skipped for a configurable duration). The header from providers is respected. Full exponential backoff retry on the same provider is a separate concern.
j3k0 commentedon May 17, 2026
Exponential backoff is partially addressed by #26292 which implements cooldown-based fallback (failed providers are skipped for a configurable duration). The retry-after header from providers is respected. Full exponential backoff retry on the same provider is a separate concern.
github-actions commentedon Jul 17, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.