-
Notifications
You must be signed in to change notification settings - Fork 1.9k
feat(config): add fallback_models for model availability fallback #1237
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: dev
Are you sure you want to change the base?
feat(config): add fallback_models for model availability fallback #1237
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b57fa36811
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const parsedModel = parseModelString(actualModel) | ||
| const variantToUse = userCategories?.[args.category]?.variant ?? resolvedVariant | ||
| categoryModel = parsedModel | ||
| ? (variantToUse ? { ...parsedModel, variant: variantToUse } : parsedModel) | ||
| : undefined | ||
| } | ||
| const variantToUse = resolved.config.variant ?? resolvedVariant | ||
| categoryModel = parsedModel |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Preserve fallback-chain variant over category defaults
When a category has a default variant (e.g., ultrabrain → xhigh) and the fallback chain selects a different model with its own variant (e.g., Claude → max), this line now forces the default variant because resolved.config.variant is always populated from the category defaults. That overrides resolvedVariant and can send an invalid variant to the fallback provider, causing the delegated task to fail whenever the primary model is unavailable. The previous behavior only prioritized an explicit user override; consider reverting to user-only precedence or using resolvedVariant when the model came from the fallback chain.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No issues found across 15 files
Confidence score: 5/5
- Automated review surfaced no issues in the provided summaries.
- No files require special attention.
Allow agents and categories to specify fallback models when the preferred model is unavailable, and surface the option in schema/docs/tests.
8d2aff9 to
31107ce
Compare
What
Adds a
fallback_modelsconfig option (string | string[]) so agents/categories can select the first available model at initialization time when the preferred model is unavailable.Why
Provider connectivity and model availability vary across environments. This reduces brittle startup behavior when a single configured model cannot be used.
Changes
fallback_modelsto agent overrides and category config schema.fallback_models(viaavailableModelsor connected-providers cache) before built-in fallback chain and system default.resolvedModelis not overwritten byoverride.model.override.category.Notes
Verification
bun run typecheckbun test src/shared/model-resolver.test.ts src/agents/utils.test.ts