feat(processor): add model fallback chain when retries are exhausted

[herjarsa]

Issue for this PR

Closes #10287

Type of change

• New feature

What does this PR do?

Adds automatic model fallback chain when the primary model fails after all retries are exhausted.

When a model encounters an error that retries cannot resolve, the processor now checks if a fallbackModels chain was configured (e.g. via fallback_model in agent config). If so, it resolves the next model in the chain and re-attempts the stream with that model.

Error classification for fallback:

• Fallback triggered: retryable APIError (rate limits, 5xx, transient errors)
• No fallback: AuthError (bad credentials), AbortedError (user cancelled), non-retryable APIError (permanent failures), ContextOverflowError (triggers compaction instead)

Implementation details:

• Added fallbackModels field to MessageV2.User schema
• Added resolveFallbackChain helper to Provider service (returns {model, remaining})
• Added outer while loop in SessionProcessor.process() to iterate through fallback models
• Modified halt() to classify errors and set ctx.shouldFallback flag when appropriate
• Reset error state when switching to a fallback model

How did you verify your code works?

• bun typecheck passes with zero errors in modified files
• Added integration tests in test/session/fallback.test.ts:
  • Auth error (401) → returns "stop" without fallback
  • Non-retryable error (400) → returns "stop" without fallback

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:

I found two potentially related PRs:

1. PR feat(session): add opt-in retry delegation for plugin-controlled fallbacks #17507 - feat(session): add opt-in retry delegation for plugin-controlled fallbacks

   • feat(session): add opt-in retry delegation for plugin-controlled fallbacks #17507
   • Related to fallback handling and retry logic in the session/processor context

2. PR feat: add model fallback support with TTFT-based timeout #13189 - feat: add model fallback support with TTFT-based timeout

   • feat: add model fallback support with TTFT-based timeout #13189
   • Directly addresses model fallback support, though with a different approach (TTFT-based timeout rather than retry exhaustion)

These PRs may have addressed similar or overlapping functionality regarding model fallback chains. You may want to check if PR #24369 duplicates work from these earlier PRs or if they complement each other.

[herjarsa]

Thanks for the automatic detection of related PRs! I'm aware of #13189 (by @keakon) which provides a more comprehensive implementation with TTFT timeout, SessionFallback module, state tracking, and toast notifications.

This PR (#24369) is intentionally a lightweight alternative:

• Simpler implementation: Only 5 files changed (vs multiple new modules in feat: add model fallback support with TTFT-based timeout #13189)
• Easier to review: Minimal surface area - just the outer fallback loop + error classification
• Faster to merge: Doesn'''t require config schema changes or new dependencies
• Core focus: Does one thing well - retry with next model when primary fails after exhausting retries

Tradeoffs:

• ❌ No TTFT timeout measurement
• ❌ No persistent model state tracking across sessions
• ❌ No toast notifications
• ❌ No irst_token_timeout config option
• ✅ Simpler codebase
• ✅ Easier to understand and maintain
• ✅ Faster review cycle

When to use each:

• Use feat: add model fallback support with TTFT-based timeout #13189 if you need the full feature set with performance monitoring
• Use feat(processor): add model fallback chain when retries are exhausted #24369 if you want basic fallback support that'''s easy to review and merge quickly

I'''m keeping this PR open as an option for the maintainers - if #13189 gets merged first, I'''m happy to close this one. If the team prefers a simpler approach first, this PR is ready to go.

[j3k0]

Sibling PR — heads up that #26292 implements a complete fallback chain with cooldown, stream error detection, and model attribution. Detailed comparison in the PR description. Would be great to align on approach so these don't diverge further.

[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.