[FEATURE]: Allow agent-level model pools and fallback policies #16868

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

• I have searched existing issues and could not find the same request.
• This is a feature request, not a bug report.
• I am opening this issue first for design discussion before any PR.

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