fix(session): make retry cap and backoffDelay configurable per provider

[eyalatox]

Issue for this PR

Closes #21960

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Follow-up to #41939, which added the fixed RETRY_MAX_RETRIES = 5 cap. That default is right for most cases, but the retry budget users want differs per provider (an aggressive retry loop against a rate-limited Bedrock account makes things worse; a flaky self-hosted proxy may need more than 5). This PR makes the cap and the initial backoff configurable per provider:

{
  "provider": {
    "amazon-bedrock": {
      "options": { "retry": 3, "backoffDelay": 1000 }
    }
  }
}

• retry — max attempts (default 5 from fix(opencode): cap session retries with jitter #41939, 0 disables retries)
• backoffDelay — initial backoff in ms (default 2000); provider retry-after headers still take precedence, and the jitter from fix(opencode): cap session retries with jitter #41939 is preserved

Both options are stripped before SDK construction (like chunkTimeout) so they never reach the provider client.

How did you verify your code works?

• Rebased on current dev (keeps the fix(opencode): cap session retries with jitter #41939 jitter + cap behavior and its tests intact).
• New unit tests in test/session/retry.test.ts: retry raises/lowers the cap; retry: 0 never retries; backoffDelay changes the backoff progression; retry-after headers still win. bun test test/session/retry.test.ts → 59 pass.
• bun run typecheck clean in packages/core and packages/opencode.
• Regenerated SDK types via ./script/generate.ts.

Screenshots / recordings

N/A (no UI change)

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search results, I found one potentially related PR:

PR #38958: fix(session): cap retry attempts to prevent infinite thinking on API errors
#38958

This PR appears to address a similar issue of capping retry attempts to prevent infinite sessions on API errors. It may be worth reviewing to see if it's a prior attempt at fixing the same problem or if it's been superseded by PR #41699.

All other results in the search were either PR #41699 itself or unrelated retry handling fixes. No other duplicate PRs were identified.

[eyalatox]

Re the duplicate check: #38958 hardcodes a cap of 5 (single file, no tests). Since #41939 merged the fixed cap upstream, this PR is now rebased on it and adds the per-provider knobs: configurable retry (0 disables) and backoffDelay, with tests, docs, and schema/SDK updates.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[yangyaofei]

Hope this PR merged ASAP, fixed max_retry in #41939 broken everything.

[github-actions]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.