[Feature Request] Configurable Retry Mechanism via opencode.json

[H0llyW00dzZ]

This is a request to add a retry mechanism that can be configured through opencode.json.

For example, we should be able to define retry settings per provider—such as allowing up to 3 retries within a customizable time window (e.g., 5 seconds). This would improve reliability, especially since the current implementation lacks configurable retries.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• handle LLM overload errors (e.g. {"type": "overloaded_error", "message": "Overloaded"}) #833: Already requests automatic retry handling for LLM overload errors with configurable retry limits and delays
• Needs improved handling and reporting for errors/LLM inference failed #2455: Requests improved error handling with retry counters and timeout displays (mentions "Retrying 1 or 10" with countdown)
• Feature Request: Request delay setting #1592: Requests configurable request delay settings between API calls
• [Bug] Timeout not working for Local LLM with MLX Models #2974: Related timeout configuration issues that aren't being respected in opencode.json

Feel free to ignore if none of these address your specific case.

[H0llyW00dzZ]

Also This retry mechanism should also handle provider-specific API errors.

[rekram1-node]

Yeah we do already have retries setup but making it configurable makes sense. This is probably a lower priotiery currently tho

[H0llyW00dzZ]

Yeah we do already have retries setup but making it configurable makes sense. This is probably a lower priotiery currently tho

@rekram1-node, regarding the configurable retry mechanism for handling API errors, I think it would be better to use a fixed interval. For example, we could set 4 retries over 10 seconds—so each retry happens every 2.5 seconds—or simply retry every 10 seconds. This would be simpler than increasing the delay between retries (i.e., exponential backoff).

[kierr]

Yeah we do already have retries setup but making it configurable makes sense. This is probably a lower priotiery currently tho

What's the default for retries at the moment? It might be low priority for those using stable internet, reliable providers, and perfectly compatible models... but for those who aren't so lucky... it's an easy way to recover from errors and hiccups without having to habitually say "Continue".

Claude Code has the ENV var CLAUDE_CODE_MAX_RETRIES which I have set to 100. That works for API errors as well as API timeouts. Opencode seems to give up after a single timeout?

[kierr]

There is also this! #2116

[rekram1-node]

yeah it looks like itd be pretty simple to add a config setting or an env var, I will take a look at pr later

[adamal]

Using OpenCode with gpt-5.2-codex from Azure, I frequently get ratelimit errors and timeouts. In Codex, setting max retries to 100 mostly solves the problem. In OpenCode, I frequently have to say "continue".
Very annoying for unsupervised sessions.