feat(ask-code): add MiniMax-M3 to the inline code Q&A catalog while retaining M2.7

[octo-patch]

Reason: The inline code Q&A provider hard-coded a single MiniMax model and one global endpoint; this adds MiniMax-M3 while retaining M2.7 and represents each model and region accurately.

What changed

• Add electron/ipc/minimax-catalog.ts as the single source of truth for the inline "Ask about Code" MiniMax integration:
  • Models (newest first): MiniMax-M3 — 1,000,000-token context window, text / image / video input, adaptive / disabled thinking; and MiniMax-M2.7, retained as a 204,800-token, text-only, always-on-thinking model. M3 is no longer treated as another 204K text-only model.
  • Regional endpoints: the global (global_en) and China (cn_zh) regions, each exposing both of its protocol base URLs and its documentation root.
  • Helpers to resolve a model, an endpoint, a protocol base URL, and the chat completions URL for a region.
• electron/ipc/ask-code-minimax.ts now derives the request URL and the default model from the catalog (default model MiniMax-M3, default region global_en) instead of hard-coding them. The public MINIMAX_MODEL export is preserved.
• Update the Settings dialog copy and the README to describe M3 (1M context, image and video input) with M2.7 still supported.

Checks

• tsc --noEmit (root tsconfig.json and electron/tsconfig.json) — passed
• vitest run electron/ipc/minimax-catalog.test.ts electron/ipc/ask-code-minimax.test.ts — 25 passed
• prettier --check and eslint --max-warnings 0 on the changed files — passed

[johannesjo]

Review

The functional core is correct. I verified the model claims against MiniMax's docs: MiniMax-M3 is the right wire ID, released ~1 June 2026 with a 1M-token context window, native image/video input, and a thinking toggle. Both base URLs (https://api.minimax.io/v1, https://api.minimax.io/anthropic) are correct. No hallucinated endpoints — which is the main risk in a PR like this.

Two clusters of concerns: the catalog doesn't achieve its stated goal, and three of the new user-facing claims describe capabilities the app doesn't have.

---

The catalog is not yet wired to anything

The stated goal is that the provider is "no longer pinned to a single model or a single endpoint." It still is — just via a constant indirection. I grepped every export against the tree at 8b69a2b:

Reached from production code: DEFAULT_MINIMAX_MODEL_ID, DEFAULT_MINIMAX_REGION, minimaxChatCompletionsUrl (and, transitively inside the catalog, minimaxBaseUrl → getMinimaxEndpoint).

Zero consumers outside the catalog and its own test: every contextWindow / inputModalities / thinking field, MinimaxInputModality, MinimaxThinkingMode, anthropicBaseUrl, docsRoot, the whole cn_zh entry, minimaxModelIds(), getMinimaxModel(), and the 'anthropic' branch of minimaxBaseUrl().

askCodeProvider is typed 'claude' | 'minimax' (src/store/types.ts:364) with no model or region field anywhere in the store, settings UI, or persistence. There is no code path by which a user reaches M2.7, the China region, or the Anthropic protocol.

Changing the single literal in ask-code-minimax.ts from 'MiniMax-M2.7' to 'MiniMax-M3' delivers 100% of the user-visible behaviour in this PR. Suggest either adding the model dropdown here so the metadata earns its place, or trimming the catalog to the model ID and URL and reintroducing fields when something consumes them.

---

Important

• README.md:55 and src/components/SettingsDialog.tsx:628 — "M2.7 also supported" is not true. There is no UI to select it; the provider always sends DEFAULT_MINIMAX_MODEL_ID. Either add the dropdown or drop the claim.

• src/components/SettingsDialog.tsx:628 — "text, image and video input" advertises something the app cannot do. ask-code-minimax.ts:76 sends { role: 'user', content: prompt } as a plain string. There is no image/video path in the request body, in MinimaxAskCodeRequest ({requestId, channelId, prompt}), or in the UI. Same overclaim in README.md:55. M3 supports it; this integration doesn't.

• src/components/SettingsDialog.tsx:628 — the "1M context" figure is unreachable. ASK_CODE_MAX_PROMPT_LENGTH = 50_000 characters (electron/ipc/request-registry.ts:1), enforced by assertPromptWithinLimit at ask-code-minimax.ts:46 before the fetch. That's a real ceiling of roughly 12–15k tokens, not 1M. This was already overstated for "204K", but quoting 1M widens the gap considerably. Either raise the cap or state the effective limit.

• electron/ipc/ask-code-minimax.ts:70 — the thinking-mode change isn't exercised. The catalog itself records M3 as ['adaptive', 'disabled'] against M2.7's ['always_on'], but the request sends no thinking parameter, so M3 runs adaptive. The SSE parser forwards only delta.content and ignores reasoning_content. MiniMax's OpenAI-compatible streaming has been reported to mix thinking tags (<mm:think>) into delta.content rather than isolating them, which would render reasoning text directly into the user's answer. Worth one manual smoke test against the live API before merge, and consider sending thinking explicitly rather than inheriting the adaptive default.

  Confidence ~60%. Verified: the parser reads only delta.content, no thinking param is sent, the catalog documents differing modes. Not verified: actual M3 OpenAI-compat wire behaviour — my sources here are third-party issue trackers, not MiniMax docs. Flagging to test, not asserting a bug.

• Existing users switch model silently. Anyone already on the MiniMax provider moves M2.7 → M3 on upgrade with no migration, setting, or notice — different pricing and output characteristics. Presumably intended, but worth a changelog line.

Minor

• electron/ipc/minimax-catalog.ts:98 — the ?? MINIMAX_ENDPOINTS[0] fallback is unreachable. region is typed MinimaxRegion, both variants are present in the array, and noUncheckedIndexedAccess is not enabled in either tsconfig. Relatedly, the test named "falls back to the global endpoint for the default region" (minimax-catalog.test.ts:82) passes 'global_en', which hits the direct match and never exercises a fallback. Rename the test or drop the branch.

• electron/ipc/minimax-catalog.test.ts — the tests are tautological. 85 lines asserting constants back at themselves (contextWindow is 1_000_000 because the line above declares it so). They can only fail when someone deliberately edits the value, which is the intended action. toHaveLength(2) (line 52) and toEqual(['MiniMax-M3', 'MiniMax-M2.7']) (line 16) will break on any future model addition. "does not clone the M2.7 profile onto M3" (line 40) asserts that the author didn't copy-paste, which isn't a behaviour.

• electron/ipc/ask-code-minimax.test.ts:183 — nothing pins the literal wire string. expect(body.model).toBe(MINIMAX_MODEL) compares the constant to itself, so a typo in the model ID passes this test and the catalog test, failing only at runtime against the live API. Pre-existing pattern, but worth fixing now that the ID has changed: assert expect(body.model).toBe('MiniMax-M3'). That single string is the one thing that breaks the feature outright if wrong.

• electron/ipc/minimax-catalog.ts:2 — "single source of truth" overclaims. MiniMax's docs also list MiniMax-M2.7-highspeed, MiniMax-M2.5, MiniMax-M2.1, MiniMax-M2, and M2-her. Cataloguing only two is a reasonable YAGNI call, but the doc comment shouldn't imply completeness.

---

Strengths

Correct model ID and base URLs. MINIMAX_MODEL is preserved so nothing downstream breaks. Thorough JSDoc, docs updated alongside the code, CI green.

Verdict

Needs changes — chiefly the three inaccurate copy claims in README.md:55 and SettingsDialog.tsx:628 (M2.7 selectable, image/video input, 1M usable context), since that copy is what users actually read. Separately, decide whether to wire the catalog to a real model picker or trim it to what's consumed.

_{Reviewed with Claude Code.}