opencode-go: spurious low/medium/high reasoning variants for MiMo V2.5 / Hy3; inconsistent with Kimi/Grok #43543

Summary

OpenCode Go (opencode-go) models show an inconsistent and often inaccurate variant/thinking selector in /models. Several models offer effort levels their catalog says they don't support, several show sets that don't match their declared reasoning_options, and a couple show no selector at all. Which set appears depends on whether a model's catalog entry carries reasoning_options (and which generator resolves it), so the same model behaves differently across installs/snapshots.

Reproduced against the OpenCode TUI (/models → provider OpenCode Go):

Steps to reproduce:

1. Open the OpenCode TUI.
2. Run /models, start a session, and select OpenCode Go.
3. Pick e.g. deepseek-v4-pro or mimo-v2.5 → the model selector asks for a variant (low/medium/high/…).
4. Pick grok-4.5 or kimi-k3 → no variant selector at all.

Root cause

A model's variants come from two independent generators, and which one is used depends on the catalog's reasoning_options for that model:

packages/opencode/src/provider/provider.ts (fromModelsDevModel):

const variants = ProviderTransform.reasoningVariants(model, base) ?? ProviderTransform.variants(base)

• reasoningVariants(...) is catalog-driven. It returns undefined when model.reasoning_options is absent, {} when it is [], and effort/toggle/budget variants when declared.
• The ?? falls through to the generic transport heuristic variants(...) only when reasoning_options is absent/undefined. That heuristic emits its own effort sets by transport + model id (e.g. @ai-sdk/openai-compatible → WIDELY_SUPPORTED_EFFORTS + max for deepseek-v4, @ai-sdk/openai → openaiReasoningEfforts(...)), and hard-excludes some families (deepseek-chat/reasoner/r1/v3, minimax, GLM≠5.2, kimi, qwen, …) → {}. mimo-* and hy3 are not on that list.

packages/opencode/src/provider/provider.ts (registry loop):

if (model.variants === undefined) {
  model.variants = mapValues(ProviderTransform.variants(model), (v) => v)
}

Effect: whether a selector appears (and which options it has) depends on whether the catalog omits reasoning_options (undefined, → heuristic, → spurious/wrong sets) vs. explicitly sets [] (→ suppressed). Both mean "no declared effort control", but they resolve differently.

Why this is wrong

• Sets don't match declarations — e.g. deepseek-v4-pro declares [high, max] but the TUI offers low/medium/high/max; gpt-5.6-luna declares a max it never shows. These are the heuristic's sets, not the model's.
• mimo-v2.5 / mimo-v2.5-pro are always-on reasoning (interleaved: { field: "reasoning_content" }) with reasoning_options: []; offering low/medium/high sends a reasoningEffort the model doesn't honor — inert/misleading.
• Inconsistency: minimax-m3 (declared toggle) correctly gets a none/thinking toggle, while hy3 (declared [none,low,high]) shows low/medium/high, and kimi-k3 / grok-4.5 (declared effort sets) show nothing.
• Data-version dependent: the observed sets imply the running build resolved many models through the heuristic fallback (their reasoning_options was absent), while the current models.opencode.ai catalog would suppress some of them. The same model behaves differently across installs/snapshots.

Expected behavior

• A model should expose effort/toggle/budget variants only from what it declares in reasoning_options (the reasoningVariants path).
• The generic heuristic variants() should not inject low/medium/high for models that declare no effort control — absent reasoning_options should behave like [] (no selector) rather than triggering the fallback, or the fallback should consult declared capabilities so returned sets always match the model.

Environment

• OpenCode (opencode-go provider), model catalog sourced from https://models.opencode.ai/api.json
• TUI /models model + variant selection flow