Repository navigation
tui: auto-assigned "medium" variant crashes sessions for models with empty variants (e.g. mimo-v2.5-free) #42848
Description
Summary
opencode2 (V2) auto-assigns the medium variant when creating a session with a reasoning model whose catalog entry has variants: [] (empty). Runtime then fails with SessionRunnerModel.VariantUnavailableError and the session silently falls back to another model.
Environment
- opencode version: 0.0.0-next-17444 (next channel)
- OS: Linux 7.0.11-76070011-generic (linux x64)
- Terminal: xterm-256color / truecolor
- Shell: /bin/bash
- Install/channel: next (v2 binary
opencode2) - Active plugins: @warp-dot-dev/opencode-warp
Reproduction
- Open the opencode2 TUI (next channel).
- Select
opencode/mimo-v2.5-freefrom the model picker (/models); do not touch any variant setting. - Send any prompt.
Expected Behavior
The session runs mimo-v2.5-free with variant default (the catalog entry defines no variants), and the model responds normally.
Actual Behavior
The created session is pinned to variant: "medium" even though the model catalog entry has variants: []. The model resolver throws:
SessionRunnerModel.VariantUnavailableError: Variant unavailable for opencode/mimo-v2.5-free: medium
and the session falls back to opencode/big-pickle.
Root Cause
The TUI defaults the variant to medium for models with reasoning: true, but mimo-v2.5-free's catalog entry has an empty variants list (variants: []). The resolver does not tolerate a variant that does not exist and hard-fails instead of falling back to the default.
Verified via the HTTP API: creating a session with variant: "default" (or omitting the variant) resolves correctly and the model works. Log source: ~/.local/share/opencode/log/opencode.log (Failed to drain Session ... SessionRunnerModel.VariantUnavailableError).
Workaround
After selecting the model with /models, choose the default option in /variants, or switch via API:
opencode2 api post /api/session/<sessionID>/model --data '{"model":{"id":"mimo-v2.5-free","providerID":"opencode","variant":"default"}}'Additional Context
- opencode V1 (1.17.18) works fine with the same model: it does not use the variant mechanism.
- The models.dev cache entry for
mimo-v2.5-freehasreasoning: trueandreasoning_options: []. - Related: V2: Reconcile provider catalogs with /models endpoints #40524 (V2 catalog reconciliation), Merge Gateway reasoning effort variants are not selectable #41868 (variants not selectable for Merge Gateway).
Activity
github-actions commentedon Aug 16, 2026
This issue might be a duplicate of or closely related to existing issues. Please check:
--variantsilently ignored when the value is not in the model's reasoning_options #40182:--variantvalue not in model'sreasoning_optionsis silently dropped (same resolver path, different failure mode — silent vs. hard error)variants: []in catalog entry)mediumreasoning despitereasoningEffort: highbeing applied #25126: TUI showsmediumvariant as default regardless of actual configured reasoning effort (same TUI "medium" default behavior)If this is a distinct issue (V2-specific hard
VariantUnavailableErrorvs. silent failure in V1), feel free to clarify the distinction so maintainers can track them separately.AlexisCubilla commentedon Aug 19, 2026
Thanks for the triage. I checked the referenced issues and believe this one is a distinct failure mode worth tracking separately, even though it shares the same underlying family (catalog entries with
variants: []+ a "medium" default).Comparison:
--variantvalues outsidereasoning_optionsare silently ignored (no error). This issue is the opposite: the TUI persists amediumvariant into the session at creation and the resolver hard-fails withVariantUnavailableErrorat runtime.variants: []simply loses the/variantscommand; sessions run fine with the default. In our case the model does not run — the session crashes on every prompt until the variant is manually reset. This shows thevariants: []cases are not all equal: providers: MiniMax MiniMax-M3 has no variants and /variants command missing (V2 beta) #36888 degrades gracefully, ours fails hard.mediumin the badge. Ours is behavioral: themediumvariant is written into the session model and then crashes resolution.Additional severity detail: after the failure, opencode2 silently falls back to another model (
opencode/big-pickle) — the user is switched to a different model without any visible notice, which is easy to miss.Root cause summary: the TUI auto-pins a
mediumreasoning variant for models withreasoning: true, even when the catalog entry declaresvariants: [], and the resolver throws a hardVariantUnavailableErrorinstead of resolving to the default.Happy to consolidate this into any canonical issue if the maintainers prefer, but I'd suggest keeping this open as the V2 hard-error case.
github-actions commentedon Oct 19, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.