MiniMax M3.1 Flash Preview offers no thinking depth variants despite a catalog-declared effort ladder #54801

Description

Summary

The models.dev catalog declares a five-level reasoning-effort ladder for MiniMax-M3.1-Flash-Preview, but OpenCode resolves zero variants for it, so no thinking depth is selectable in the TUI. Users have to hand-write the entire variants array in opencode.json to get depth control that the catalog says should exist by default.

Per MiniMax's own docs the model supports five depths, so this is an OpenCode gap rather than a catalog error.

Environment

• opencode version: 2.0.27
• opencode commit: bcf23b6 (branch dev)
• OS: Linux (x86_64)
• Terminal: TERM=xterm-256color, COLORTERM=truecolor, TERM_PROGRAM unset
• Shell: fish
• Install/channel: release (~/.opencode/bin/opencode)
• Active plugins: none found in config

All source references below are line numbers at the commit above.

Reproduction

1. Configure a provider that exposes MiniMax-M3.1-Flash-Preview (for example minimax-coding-plan).
2. Select the model.
3. Press the variant_cycle keybind (default ctrl+t) to cycle thinking depth.

Expected Behavior

The catalog entry declares:

"reasoning_options": [{ "type": "effort", "values": ["low","medium","high","xhigh","max"] }]

so cycling should step through low / medium / high / xhigh / max without any configuration.

Actual Behavior

There are no variants at all, so ctrl+t does nothing:

$ opencode api model.list | jq '.data[] | select(.id=="MiniMax-M3.1-Flash-Preview") | .variants'
[]

The only way to get depth control is to declare the whole ladder manually:

{
  "providers": {
    "minimax-coding-plan": {
      "models": {
        "MiniMax-M3.1-Flash-Preview": {
          "variants": [
            { "id": "low",    "body": { "output_config": { "effort": "low" } } },
            { "id": "medium", "body": { "output_config": { "effort": "medium" } } },
            { "id": "high",   "body": { "output_config": { "effort": "high" } } },
            { "id": "xhigh",  "body": { "output_config": { "effort": "xhigh" } } },
            { "id": "max",    "body": { "output_config": { "effort": "max" } } }
          ]
        }
      }
    }
  }
}

Additional Context

Where the ladder comes from

This is catalog data, not source in this repo. Two copies, which I verified agree:

• Bundled — packages/core/src/models-dev/snapshot.txt, a 5.3 MB minified JSON blob committed at this commit. Imported at packages/core/src/models-dev.ts:16, regenerated by packages/core/script/update-models-snapshot.ts.
• Live — https://models.opencode.ai/api.json, fetched at runtime by packages/core/src/models-dev.ts:345 and cached in KV for 5 minutes, with the bundled snapshot as the offline floor.

Upstream source of truth: https://github.com/anomalyco/models.dev (see CONTRIBUTING.md:21 — "New providers should rarely require OpenCode changes. Add the provider to models.dev first.").

Exactly two entries declare this ladder, both the same model on the two coding-plan hosts:

Both carry npm: "@ai-sdk/anthropic" at the provider level, which is what routes them to minimax/messages.

Why the variants list is empty

The declared ladder survives every stage of the pipeline and is discarded in the last one:

1. The catalog entry declares the reasoning_options shown above.
2. packages/core/src/models-dev.ts:196 (supports()) maps it into Variant.Support[].
3. packages/core/src/models-dev.ts:115 calls Variant.resolve(...).
4. packages/ai routes the provider to @opencode/ai/providers/minimax/messages, mapped via packages/core/src/aisdk-native.ts:113.
5. packages/core/src/variant.ts:337 returns [].

Two independent gaps in that last step:

No ladder path exists. minimaxMessages has exactly one return that produces variants, and it is a binary toggle:

// packages/core/src/variant.ts:337
const minimaxMessages: Protocol = (model, support) => {
  if (/minimax[-.]?m2(?:[.-]|$)/i.test(modelID(model))) return []
  const configurable = support.type === "toggle" || (support.type === "effort" && support.values === undefined)
  if (!configurable) return []
  return toggle({ settings: { thinking: { type: "disabled" } } }, { settings: { thinking: { type: "adaptive" } } })
}

toggle(...) yields [none, thinking]. There is no efforts(...) call in this function, so a multi-level ladder is unreachable.

The guard suppresses the working toggle too. support.values === undefined means an explicitly specified ladder is discarded before line 341 is reached, so M3.1 loses even the none/thinking pair that M3 gets. The guard appears intended as a fallback for catalogs that mark a model reasoning-capable without enumerating depths, but it suppresses the specified case rather than the unspecified one.

Contrast with other MiniMax M3 entries

Every other MiniMax M3 entry in the catalog declares something other than a ladder:

MiniMax-M3 takes the toggle branch and resolves correctly:

[{"id":"none","settings":{"thinking":{"type":"disabled"}}},
 {"id":"thinking","settings":{"thinking":{"type":"adaptive"}}}]

So the difference is not the model family, it is whether the catalog enumerated depth values.

Only the Messages protocol drops ladders

For scale, ~4000 entries in the current catalog declare an explicit effort ladder, so the mechanism is routine — variant.ts handles it for other protocols, just not this one.

Note that only the two coding-plan hosts declare a ladder at all, so it is not possible to tell from the repo alone whether minimaxMessages was written for the toggle-only models and never revisited, or whether coding-plan was deliberately excluded. The verification below suggests the former.

Verification

Per the MiniMax docs (https://platform.minimax.io/docs/guides/text-generation#tunable-thinking-depth-effort), MiniMax-M3.1-Flash-Preview accepts low, medium, high, xhigh, and max for thinking depth, defaulting to max when omitted. On the Anthropic-compatible endpoint the field is output_config.effort.

The catalog's five values match the documented set exactly, in the same order, and correctly omit none.

I confirmed the API behavior against the live endpoint:

• output_config.effort with each declared level returns HTTP 200 and a normal completion.
• An invalid level is rejected:

400 invalid reasoning_effort: "bananas" (allowed: low, medium, high, xhigh, max)

• Thinking cannot be disabled. thinking: {"type":"disabled"} and effort: "none" both return:

400 model "MiniMax-M3.1-Flash-Preview" requires adaptive thinking; thinking.type="disabled" (including reasoning.effort=none) is not allowed

Thinking is on by default and none must not be offered as a variant.

• Omitting effort defaults to max.

So the ladder is exactly the five declared levels, with no off state.

Suggested fix

Add an efforts(...) branch to minimaxMessages mirroring anthropicMessages (packages/core/src/variant.ts:314), mapping each declared effort to { body: { output_config: { effort } } } — and no none variant, since thinking cannot be disabled on this model.

There is existing precedent for output_config.effort in this file: bedrockConverse already emits { output_config: { effort } } at packages/core/src/variant.ts:429.

One subtlety worth calling out: Variant.resolve at packages/core/src/variant.ts:19 prepends the toggle branch's none variant whenever a protocol has one. For M3.1 that would emit a none variant the API rejects, so the ladder branch must take precedence over the toggle branch rather than being merged with it.

Separately, the guard on line 339 should not suppress the working toggle when a ladder is declared.

For reference, packages/ai/src/providers/minimax.ts:17 documents the Messages thinking type as only { type: "adaptive" | "disabled" }, which may need widening for an output_config overlay. packages/ai/src/providers/minimax.ts:30 notes the Responses route's other values "enable thinking without changing its depth" — that does not apply here, since the Anthropic-compatible route does vary with effort.

Plugins

No response

OpenCode version

No response

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response