huge retry time
Description
when i use openai model in opencode and it reached ratelimit, shows 447.231667 hours wait to retry!
Plugins
No response
OpenCode version
1.1.13
Steps to reproduce
No response
Screenshot and/or share link
No response
Operating System
No response
Terminal
No response
This issue might be a duplicate of existing issues. Please check:
- #1712: Implement exponential back-off when hitting rate limits
- #2398: AI_RetryError: Failed after 4 attempts. Last error: Too Many Requests
- #3525: Quota Limit Exceeded Error is not handled properly
These issues all relate to rate limiting and retry mechanisms when using OpenAI and other model providers. The excessive wait time you're experiencing (447 hours) appears to be a calculation or display issue with how retry times are being communicated to the user.
Feel free to ignore if none of these address your specific case.
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. ... https://github.com/anomalyco/opencode/issues/1712#issuecomment-3752450455
Well in this case what is happening is your quota was exceeded and we are respecting the retry headers and reporting back to you when the quota will reset effectively, so not an exponetial issue in this example, instead it is the actual amount of time before the quota resets
Well in this case what is happening is your quota was exceeded and we are respecting the retry headers and reporting back to you when the quota will reset effectively, so not an exponetial issue in this example, instead it is the actual amount of time before the quota resets
yes because my GitHub copilot was exceeded, but opencode shouldn't count it as seconds should be days
I think is not a bug but it's an enhancement
Yeah good point
/oc update tui/component/prompt/index.tsx so that we show a slightly prettier message for retries?
Right now it is hardcoded to be seconds but when seconds is really large we should try more human readable times w/ best match (doesnt have to be exact if it is in # of days / weeks range
if it is in minutes try to have seconds there too if possible If it is in hours try to have minutes there too if possible
