models: MiniMax-M3.1-Flash exposes zero reasoning variants, so thinking depth stays at max #61521

Summary

minimax/MiniMax-M3.1-Flash exposes zero reasoning variants in OpenCode, even though its models.dev entry declares a five-level reasoning effort list. Because MiniMax defaults output_config.effort to max when the field is omitted, the model always reasons at maximum effort and the user has no way to lower it from the TUI (/models, Ctrl+T variant cycle) or the CLI.

The sibling model minimax/MiniMax-M3 does expose variants (none, thinking), so the reasoning control is present for one MiniMax model and missing for the other.

Environment

• opencode version: 2.2.5 (npm global, @opencode-ai/cli)
• OS: Windows_NT 10.0.19044 (win32 x64)
• Terminal: TERM=xterm-256color, WT_SESSION present (Windows Terminal); TERM_PROGRAM/COLORTERM unset
• Shell: ComSpec=C:\Windows\system32\cmd.exe, PowerShell (Desktop edition) for commands
• Install/channel: npm global install (C:\Users\Admin\AppData\Roaming\npm\opencode.ps1), release channel
• Active plugins: open-suite, quipu-graph (both local, from ~/.config/opencode/plugins/)

Reproduction

No provider credentials are required — the catalog is observable directly:

1. Run opencode api get /api/model and locate the entry with "providerID": "minimax" and "id": "MiniMax-M3.1-Flash".
2. Observe that its variants array is empty ([]), while capabilities contains no reasoning information either.
3. For contrast, the same response shows "id": "MiniMax-M3" with "variants": [{"id": "none", ...}, {"id": "thinking", ...}].
4. Select minimax/MiniMax-M3.1-Flash in the TUI and cycle variants (Ctrl+T): there is nothing to cycle.

Expected Behavior

The five effort levels declared by the catalog for MiniMax-M3.1-Flash should be offered as model variants (low, medium, high, xhigh, max), and selecting one should send the corresponding effort to the provider.

Actual Behavior

The model exposes no variants, so no reasoning control is rendered or selectable, and requests omit the effort field entirely — which makes MiniMax fall back to its own default of max.

Measured on the same prompt with opencode run --format json (reasoning tokens reported by the provider):

Additional Context

Catalog payload as cached by OpenCode

OpenCode stores the models.dev v2 catalog in its database (kv table, key models-dev:v2:catalog, refreshed the same day). The relevant entries are:

// provider "minimax", model "MiniMax-M3.1-Flash"
"capabilities": {
  "reasoning": {
    "supported": true,
    "default": { "type": "effort", "value": "max" },
    "effort": ["low", "medium", "high", "xhigh", "max"]
  }
}

// provider "minimax", model "MiniMax-M3"
"capabilities": {
  "reasoning": {
    "supported": true,
    "default": { "type": "toggle", "value": false },
    "toggle": true
  }
}

The effort list is present in the catalog, and the catalog also records that the default effort is max — but neither is surfaced as a variant for MiniMax-M3.1-Flash. The toggle case (MiniMax-M3) does surface variants, which suggests the effort-to-variant mapping is the part that is not being applied.

Provider API semantics (MiniMax)

Per MiniMax's Anthropic-compatible API documentation, thinking depth for MiniMax-M3.1-Flash is controlled by a top-level output_config.effort in the request body:

• allowed values: low, medium, high, xhigh, max
• when omitted, output_config.effort defaults to max
• none is not supported and returns HTTP 400 (thinking is always enabled)

So omitting the field is not a neutral choice — it silently selects the most expensive and slowest setting.

capabilities.reasoning in user config only narrows existing variants

The V2 models guide documents that capabilities.reasoning in providers.<id>.models.<id> replaces a model's reasoning variants and that "OpenCode builds the variants for the model's package from them". Observed behavior in 2.2.5:

• it does narrow an effort list the catalog already exposes — e.g. opencode/crouton-alpha-free normally has minimal, low, medium, high, xhigh, max; with capabilities.reasoning.effort: ["low"] it exposes only low;
• it does not create variants for a model whose catalog entry exposes none — with the same block applied to minimax/MiniMax-M3.1-Flash, the model still exposes variants: [].

Working around it today

Declaring the variants explicitly does work, and the provider package accepts effort with the enum low | medium | high | xhigh | max:

{
  "$schema": "https://opencode.ai/config.json",
  "providers": {
    "minimax": {
      "models": {
        "MiniMax-M3.1-Flash": {
          "settings": { "effort": "low" },
          "variants": [
            { "id": "low", "settings": { "effort": "low" } },
            { "id": "medium", "settings": { "effort": "medium" } },
            { "id": "high", "settings": { "effort": "high" } },
            { "id": "xhigh", "settings": { "effort": "xhigh" } },
            { "id": "max", "settings": { "effort": "max" } }
          ]
        }
      }
    }
  }
}

With this in place the model exposes all five variants, the request carries the requested effort, and the reasoning token counts in the table above become reachable (#low → 70 reasoning tokens vs #max → 246).

Related

• Free Zen models with reasoning=true show zero thinking variants (reasoning_options=[] blocks fallback) #49013 — models with reasoning = true and empty reasoning_options show zero variants
• reasoning_options=[toggle] yields zero variants for @ai-sdk/openai-compatible providers (485 models, e.g. all Xiaomi MiMo) #51541 — reasoning_options = [{ type: "toggle" }] yields zero variants on @ai-sdk/openai-compatible

Both discuss the legacy reasoning_options array from models.dev's api.json. The payload cached here is the models.dev v2 catalog, where the same information lives under capabilities.reasoning (effort / toggle / default), so this may be a separate layer of the same problem — reporting it separately in case it is.