Feature hasn't been suggested before.
Describe the enhancement you want to request
Problem
Current configuration appears centered on a single model per global/agent setting.
That makes it hard to express practical policies like:
- use a cheap/fast model first, then fall back to a stronger one
- use provider A first, but switch to provider B on rate limit or outage
- give lightweight agents one pool and coding agents another pool
Proposed solution
Please consider allowing agent-level model pools and fallback policies.
Possible shapes:
primary + fallbacks- or ordered
models[]
Possible policy fields:
fallback_on: [rate_limit, timeout, provider_unavailable, token_limit]strategy: sequential- optionally later:
round_robin, cost_first, quality_first
Example behavior
For an agent:
- primary:
google/gemini-2.5-flash
- fallback 1:
anthropic/claude-haiku-4.5
- fallback 2:
openai/gpt-5-mini
If the primary model fails with a configured runtime condition, OpenCode tries the next model in order.
Why this fits OpenCode
This seems like a natural extension of the project’s provider-agnostic design. It would make cost/speed/reliability tradeoffs easier to express without manual switching.
Backward compatibility
Single-model config should continue to work exactly as it does today.
Additional context
This would become even more useful if combined with:
- multiple auth profiles per provider
- cooldown-aware runtime failover
Feature hasn't been suggested before.
Describe the enhancement you want to request
Problem
Current configuration appears centered on a single model per global/agent setting.
That makes it hard to express practical policies like:
Proposed solution
Please consider allowing agent-level model pools and fallback policies.
Possible shapes:
primary+fallbacksmodels[]Possible policy fields:
fallback_on: [rate_limit, timeout, provider_unavailable, token_limit]strategy: sequentialround_robin,cost_first,quality_firstExample behavior
For an agent:
google/gemini-2.5-flashanthropic/claude-haiku-4.5openai/gpt-5-miniIf the primary model fails with a configured runtime condition, OpenCode tries the next model in order.
Why this fits OpenCode
This seems like a natural extension of the project’s provider-agnostic design. It would make cost/speed/reliability tradeoffs easier to express without manual switching.
Backward compatibility
Single-model config should continue to work exactly as it does today.
Additional context
This would become even more useful if combined with: