MiniMax-M3.1-Flash: Max effort sent as xhigh, stale minimax capabilities, empty agent vision #366

MiniMax-M3.1-Flash goes live through the API on 2026-10-19 at noon EDT. Registry entry: AtomicBot-ai/atomic-chat-conf#29. The model works on current clients through the registry alone. The items below are app-side gaps that make it work worse than it could. They also affect MiniMax-M3. Traced on origin/main @ 5651cdc.

MiniMax API facts (https://platform.minimax.io/docs/api-reference/text-openai-api):

• Thinking cannot be switched off. reasoning_effort takes low|medium|high|xhigh|max (documented for M3.1-Flash only) and defaults to max. none, or thinking: {type: "disabled"}, returns 400.
• Reasoning comes back separately. It arrives in reasoning_content and must be sent back unchanged in history, tool-call turns included.
• Inputs. Images go in as image_url, video as video_url. temperature takes values in [0, 2].

Already fine:

• The app never sends none/disabled to minimax: canDisableReasoning is false.
• The SDK parses reasoning_content and @ai-sdk/openai-compatible sends it back on assistant messages.
• Chat sends no temperature to cloud providers.

Worth fixing

1. UI "Max" is sent as reasoning_effort: "xhigh". CLOUD_EFFORT_VALUE.max = 'xhigh' lives in web-app/src/lib/reasoning-effort.ts:303-310, and only moonshot passes the level through (cloudReasoningEffortValue, :324). As a result, MiniMax's own default max cannot be reached from the app. Suggested fix: pass the level through for minimax as for moonshot, and add a case to web-app/src/lib/__tests__/reasoning-effort.test.ts next to the moonshot max case (~:333). Before applying it to M2.x/M3, check item 5 of the smoke check in the registry PR, which tests whether those models accept max. Today they get low…xhigh with no per-model gating.

2. Hard-coded minimax capabilities know only M2.x. The list is in web-app/src/constants/models.ts:1050. Three paths go through getModelCapabilities, and each creates an M3 or M3.1-Flash entry with only ['completion']:

   • Refresh (lib/refresh-provider-models.ts:98-106; minimax has no supports_model_listing: false);
   • Add Model (containers/dialogs/AddModel.tsx:54);
   • loopback auto-load (routes/settings/providers/$providerName.tsx:742).

   That entry has no tools, no image button and no agent vision. Registry capabilities never overwrite a saved entry (hooks/useModelProvider.ts:140-149), so it stays broken. Suggested fix: add MiniMax-M3 and MiniMax-M3.1-Flash to models, supportsStreaming, supportsToolCalls and supportsImages there.

3. Agent image description will likely come back empty. vision_payload in src-tauri/src/core/agent/openai_client.rs:766-810 sends max_tokens: VISION_MAX_TOKENS = 1024 and no reasoning_effort. MiniMax then thinks at max, which can use up the whole budget, so the call fails with "vision response did not contain message content". Suggested fix: for catalogue cloud reasoning providers, send the lowest effort with the vision call and/or a larger budget.

Minor, not blocking

• Effort defaults differ between chat and agent. With default settings (disableReasoning: true), chat sends low while the agent sends medium: buildAgentReasoningRequest maps only level === 'off' to low (reasoning-effort.ts:429).
• Video can't be sent. Non-image file parts are dropped in custom-chat-transport.ts:186-217, so video input, which the model supports, is unreachable.
• Latent stream crash. The SDK's reasoning_content stream and extractReasoningMiddleware (model-factory.ts:1470) both use the id reasoning-0. A response that mixed reasoning_content with <think> in content would break the stream. M3.1-Flash is documented not to do this.