[FEATURE]: Configurable provider/model fallback on transient errors

[ESRE-dev]

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Add configurable provider/model fallback so OpenCode can recover from transient provider failures by retrying once on an alternative model.

When the primary provider returns transient errors (for example 429, 500, 502, 503, or transient 403 from some gateways), sessions currently retry only on the same provider and can still fail after retries are exhausted. If users have multiple providers configured, OpenCode should be able to fail over automatically.

Requested behavior:

1. Add a fallback config map (primary -> fallback), e.g.:
   • openai/gpt-4o -> anthropic/claude-sonnet-4-20250514
2. On fallback-worthy errors, retry once on the configured fallback model.
3. Keep non-fallback errors as-is (auth failures, explicit context overflow, clear invalid-request errors).
4. Provide clearer guidance for copilot-style transient 403s where reauthentication may be needed.

This is broader than #19394 (provider-specific retryability bug). #19394 focuses on Anthropic 5xx retry classification; this request adds general cross-provider fallback behavior.

Why this matters

• Improves reliability when one provider is degraded.
• Reduces user-facing session failures during transient outages/rate limits.
• Lets teams configure resilient multi-provider operation without manual intervention.

Related

• Anthropic 5xx errors incorrectly marked non-retryable, stopping agent loop #19394 (Anthropic 5xx retryability)

[github-actions]

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

• [FEATURE]: Configurable provider/model fallback on transient errors #20098: Identical feature request (same title and description) by the same author, now closed.

[ChristianPerez34]

I was just thinking about creating an issue for this as well. As I like to use subagents quite a bit, would be great to be able to have subagents have fallback models in case current model has reached quota limits, is unavailable, or any other error that means model cannot move forward to have it fallback to one or more models for it to continue work. This use case is especially viable with something like https://github.com/code-yeongyu/oh-my-openagent where agents hang if model unreachable or rate limited.