Skip to content

Implement exponential back-off when hitting rate limits #1712

Closed as not planned

Description

@BigMitchGit

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.

Activity

  1. daliusd commented on Aug 8, 2025

    @daliusd

    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}}
    
  2. AlexeyYar commented on Aug 9, 2025

    @AlexeyYar

    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}}

  3. self-assigned this
    on Aug 11, 2025
  4. WilliamAGH commented on Aug 11, 2025

    @WilliamAGH

    Yeah, Cerebras and Groq are currently unusable with Opencode right now still because of this.

    Constant errors like:

    AI_RetryError: Failed after 4 attempts. Last error: Too Many Requests

  5. JC1738 commented on Aug 14, 2025

    @JC1738

    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.

  6. jsugg-qventus commented on Sep 12, 2025

    @jsugg-qventus

    Same here. On each message.

  7. sra commented on Dec 9, 2025

    @sra

    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

  8. rekram1-node commented on Dec 9, 2025

    @rekram1-node
    Contributor

    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

  9. jcgottlieb commented on Jan 9, 2026

    @jcgottlieb

    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?

  10. tgrushka commented on Jan 15, 2026

    @tgrushka

    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.

  11. shaneqld commented on Jan 27, 2026

    @shaneqld

    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}}
  12. ownself commented on Feb 1, 2026

    @ownself

    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..

  13. alainivars commented on Feb 7, 2026

    @alainivars

    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"
    }
    }

  14. abda11ah commented on Apr 4, 2026

    @abda11ah

    Hi, Please add rate limiter configurable,

    e.g : seconds-between-requests : 5

  15. j3k0 commented on May 17, 2026

    @j3k0

    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.

  16. j3k0 commented on May 17, 2026

    @j3k0

    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.

  17. github-actions commented on Jul 17, 2026

    @github-actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions