Repository navigation
MiniMax M3.1 Flash exposes no reasoning effort variants on the minimax.io API and Token Plan providers #62264
Description
Description
minimax/MiniMax-M3.1-Flash and minimax-coding-plan/MiniMax-M3.1-Flash expose zero reasoning variants in OpenCode, even though the models.dev catalog declares a five-level effort ladder for them.
MiniMax's Anthropic-compatible API defaults output_config.effort to max when the field is omitted, so the model always reasons at maximum depth and there is no way to lower it from the TUI (ctrl+t variant cycle), the CLI, or the API.
The sibling model MiniMax-M3 does expose variants (none, thinking), so the reasoning control is present for one MiniMax model and missing for the other.
Affected providers and models
All four MiniMax hosts are affected, because they all serve this model through the same Anthropic-compatible Messages route:
| Provider | Model | Catalog reasoning |
|---|---|---|
minimax (MiniMax minimax.io API) |
MiniMax-M3.1-Flash |
{supported: true, default: {type: "effort", value: "max"}, effort: ["low", "medium", "high", "xhigh", "max"]} |
minimax-coding-plan (MiniMax Token Plan) |
MiniMax-M3.1-Flash |
same as above |
minimax-cn |
MiniMax-M3.1-Flash |
same as above |
minimax-cn-coding-plan |
MiniMax-M3.1-Flash |
same as above |
Steps to reproduce
No provider credentials are required — the catalog is observable directly:
- Run
opencode api get /api/model(oropencode api model.list) and locate the entry with"providerID": "minimax"and"id": "MiniMax-M3.1-Flash". - Observe that its
variantsarray is empty ([]). - For contrast, the same response shows
"id": "MiniMax-M3"with"variants": [{"id": "none", ...}, {"id": "thinking", ...}]. - Select
minimax/MiniMax-M3.1-Flashin the TUI and cycle variants (ctrl+t): there is nothing to cycle.
Actual behavior
packages/core/src/variant.ts maps a declared effort ladder to no variants at all on the MiniMax Messages route:
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" } } })
}Variant.supports() turns the catalog entry into [{ type: "effort", values: ["low", "medium", "high", "xhigh", "max"] }], so support.values !== undefined and the function returns []. The Messages route is the default API for these models, so the ladder is unreachable on every MiniMax host.
Expected behavior
The five effort levels declared by the catalog should be offered as model variants (low, medium, high, xhigh, max), and selecting one should send the matching output_config.effort to the provider.
Note that thinking must not be disabled for this model — MiniMax answers 400 model "MiniMax-M3.1-Flash" requires adaptive thinking — so the ladder must not gain a none step.
Workaround
Declaring the variants explicitly works:
{
"$schema": "https://opencode.ai/config.json",
"providers": {
"minimax": {
"models": {
"MiniMax-M3.1-Flash": {
"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" } }
]
}
}
}
}
}Related
- MiniMax M3.1 Flash Preview offers no thinking depth variants despite a catalog-declared effort ladder #54801 — same root cause on the MiniMax Messages route
- models: MiniMax-M3.1-Flash exposes zero reasoning variants, so thinking depth stays at max #61521 — same root cause for
MiniMax-M3.1-Flashon theminimaxprovider (closed as a duplicate of MiniMax M3.1 Flash Preview offers no thinking depth variants despite a catalog-declared effort ladder #54801) - fix(core): preserve declared MiniMax Messages effort levels #56510 — open PR that maps the declared ladder to
body.output_config.effort
Screenshots
N/A — the symptom is observable through the API response described above.
Plugins
None.
OpenCode version
2.2.5
Operating System
Linux
Terminal
Ghostty
Activity
opencodejr commentedon Nov 6, 2026
Thanks for the thorough write-up and the workaround. I think this is a duplicate of #54801. Both come from the same code path: in
packages/core/src/variant.ts,minimaxMessagesonly handles the on/off toggle case, so when the catalog declares an effort ladder (low…max) it returns no variants. That affectsMiniMax-M3.1-Flashand-Previewon all MiniMax Messages hosts. It's still unchanged ondev.Possible duplicates and related items, ordered by likelihood:
MiniMax-M3.1-Flash-Preview. You've already added theMiniMax-M3.1-Flashcase to that thread.minimax/MiniMax-M3.1-Flashon 2.2.5, already closed as a duplicate of MiniMax M3.1 Flash Preview offers no thinking depth variants despite a catalog-declared effort ladder #54801.output_config.effort, linked to MiniMax M3.1 Flash Preview offers no thinking depth variants despite a catalog-declared effort ladder #54801.effortoption.The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different. Until a fix lands, declaring the
variantsexplicitly in your config, as you showed, is the workaround.isHeSatoshi commentedon Nov 6, 2026
Same root cause as #54801, so this can be closed as a duplicate — my PR for it was closed for the same reason.
The missing piece here was the coverage: the shipping
MiniMax-M3.1-Flashis affected onminimax(the minimax.io API) andminimax-coding-plan(the Token Plan) as well — all four MiniMax hosts serve it through the same Messages route.Everything is on #56510 now:
settings: { effort }vsbody.output_config.effort) — the typed option keeps a per-requestproviderOptions.effortworking, the overlay is merged on top of the protocol body and overrides itMiniMax-M3.1-Flash, asserting the request body that goes outVerified locally on the fix: decoding the live catalog yields the five effort variants (
low,medium,high,xhigh,max) forMiniMax-M3.1-Flashon all four MiniMax providers,MiniMax-M3keeps itsnone/thinkingtoggle, and the M2.x models stay variant-free.opencodejr commentedon Nov 6, 2026
Thanks for confirming, and for moving the coverage notes and the provider test onto #56510. Having the shipping
MiniMax-M3.1-Flashonminimaxandminimax-coding-plancovered there, as well as-Preview, is useful.This issue will be closed as a duplicate of #54801 as planned. Please follow #54801 and #56510 for progress. Until a fix lands, the explicit
variantsconfig from your report is still the workaround.opencodejr commentedon Nov 7, 2026
Closing this as a duplicate of #54801, as you suggested. Both come from the same code: the MiniMax Messages variant mapping returns no variants when the catalog lists effort levels. Thanks for adding the shipping
MiniMax-M3.1-Flashcoverage onminimaxandminimax-coding-plan, and the provider test, to #56510. Please follow #54801 and #56510 for progress. Until then, declaring thevariantsexplicitly in your config is the workaround.