MiniMax provider (run sessions on MiniMax's API)

What it is

Omniscio supports spawning Claude-Code-style sessions backed by MiniMax's Anthropic-compatible API (hosted at api.minimax.io) as an additional provider, alongside claude (the default), codex, gemini, antigravity, deepseek, kimi, and glm.

Where to find it

Settings → Accounts — the MiniMax section stays hidden until you flip Show alternative AI providers. Once revealed, MiniMax appears as a provider in the normal session-creation pickers.

How it behaves

What the user sees

A MiniMax session looks identical in the sidebar and main pane to a Claude session — same status dots, same streaming bubbles, same Ctrl+Enter to send, same Plan / Auto-Accept / Bypass Permissions modes, same tool-call approval UI. The provider is invisible in normal chat. The only user-visible difference is the MiniMax icon (a non-Claude provider mark, no text label) in the session header.

Tool-call behavior is identical to Claude because the same claude CLI binary is doing the talking — only the model and the upstream endpoint differ. There is no yolo / auto-approve mode like Gemini or Anti-Gravity; the standard Claude approval flow applies.

How to enable

Master toggle required first. MiniMax is an alternative provider — by default Omniscio ships as a Claude-only product, and the entire MiniMax setup section below is hidden in Settings → Accounts. Flip Settings → Accounts → Show alternative AI providers to ON and the MiniMax panel appears alongside Gemini, Codex, Anti-Gravity, DeepSeek, Kimi, and GLM. With the master off, the per-project "Default provider" radio collapses to a single Claude row and the session header's provider switcher (ChangeProviderButton) hides MiniMax — MiniMax effectively does not exist in the UI even if every gate below is configured. Your saved API key and "Allow MiniMax sessions" toggle are preserved across master-toggle flips.

You need two of these in place (note: no binary check — same claude binary as Claude). The opt-in toggle leads and gates the key field — the API key input appears only once MiniMax is turned on, so a key can't be entered into a disabled provider (when off, a hint keeps the minimax-api-key Settings-search anchor landable and a saved key is preserved):

1. Settings → Account → Allow MiniMax sessions in any project — opt-in toggle, off by default; same security stance as the Codex/Gemini/DeepSeek/Kimi/GLM spawn guards. Turning it on reveals the key field below.
2. Settings → Account → MiniMax → API key — paste a MiniMax API key from the MiniMax platform console (encrypted at rest via Electron safeStorage).

A key is one way to pay, not the only one. Who pays for a MiniMax session, and which company serves it, is MiniMax's supply list in Settings → Accounts → Who pays & who serves. It holds your own MiniMax key and Omniscio credits (signed-in, drawn from your prepaid balance) — so with no key saved, a MiniMax session can still run on credits — and it can hold a DeepInfra row for MiniMax M3 and M2.5. A session connects through the first row that can serve. See model-vendors.md.

Once both are green, you can launch a MiniMax session in three ways:

• Per-launch override — on a fresh (zero-message) session, the ChangeProviderButton in the new session's main panel (the launch-config pickers on a fresh session) lets you pick a one-off provider before sending the first message. Non-ready providers appear aria-disabled with an "Add key…" / "Enable in Settings…" suffix and deep-link to the right Settings panel.
• Per-project default — Edit Project dialog (three-dot menu → Edit) has a "Default provider" section listing every enabled provider. Pick MiniMax and the project's sidebar "+ New Session" button spawns MiniMax automatically.
• Programmatically — anything that creates a session with provider: 'minimax' (recipes, agent-driven sessions, the CLI control HTTP API). Same readiness gates apply on the backend.

Choosing the model

A fresh MiniMax session lets you pick the model in the launch-config pickers (next to the provider chooser). The list is registry-driven (MODELS_BY_PROVIDER.minimax in provider-models.ts) and offers a switchable set: MiniMax M3 (MiniMax-M3, the default — MiniMax's latest flagship for agentic reasoning, tool use, coding, and long context), MiniMax M2.7 (MiniMax-M2.7, an enhanced agentic coding model that sits between M2.5 and M3), MiniMax M2.5 (MiniMax-M2.5), and MiniMax M2 (MiniMax-M2, the proven coding id). Use default spawns MiniMax-M3 rather than omitting the model flag — MiniMax requires a real MiniMax model id (the shared claude binary's built-in default is a Claude id that MiniMax 404s as "model not found"), so the registry pins one via getProviderDefaultModel. MiniMax has no separate "reasoning effort" knob. The model list is MiniMax's own — a MiniMax session never inherits your Claude default model (those are Claude ids its endpoint would reject). See start-a-new-session.md.

Per-project default

Each project remembers a default provider in the projectDefaultProviders setting (a Record<projectId, ProviderId>). Empty by default — every project falls back to Claude. Change it from the project's three-dot menu → Edit → Default provider radios; the change persists immediately.

When you set a project's default to MiniMax but MiniMax isn't ready (toggle off or key missing), an amber "!" badge appears on that project's sidebar row. Hover the badge for a tooltip explaining the gap; click it to deep-link straight to the right Settings panel. The badge re-checks on every render, so fixing the gap clears it without a refresh. Claude defaults never show the badge — Claude is always considered ready.

Error states and fixes

Two gap codes — fewer than Gemini/Codex because there is no separate binary to check:

Gap	What it means	Click-to-fix lands you at…
toggle-off	"Allow MiniMax sessions" is OFF in Settings	Settings → Account → Allow MiniMax sessions toggle
key-missing	No row of MiniMax's supply list can serve (no MiniMax key, and no other row ready)	Settings → Account → MiniMax API key field, or Who pays & who serves

Test your key. The MiniMax API-key field has a "Test key" button that pings MiniMax's real endpoint with your key and the default model, returning one plain-language verdict (works / invalid key / out of balance / model not available) — so a misconfigured key surfaces before you spawn a session rather than as a confusing mid-turn failure. (A save-time check against MiniMax's models list also rejects an obviously bad key before it is stored.)

Retired / unavailable model. If a session's selected model is no longer accepted by MiniMax — either Omniscio has removed it from the picker or the vendor killed a still-listed id server-side — Omniscio surfaces a clear "this MiniMax model is no longer available — open the model picker and choose another" and parks the session as needs_you / recovery_failed, instead of silently retrying the rejected request into the generic placeholder-stuck give-up loop. Two guards back this: a pre-spawn refusal (the model isn't in the current picker list) and a placeholder-stuck config-error guard (an anthropic-compat session that produced no output and hit the rejected-request signature). See provider-spawn-model-availability-contract.md.

The real reason, not a blanket "model unavailable." A MiniMax rejection arrives the same way regardless of cause — a synthetic placeholder with zero output — so when the rejection is not about the model (the account ran out of balance, the conversation outgrew the context window, the key became invalid, or you hit a rate limit), Omniscio reads MiniMax's actual error off that placeholder and surfaces the specific cause + fix instead of the generic "model unavailable": out of balance → recharge the account, then resend; conversation too long → start a fresh session or pick a larger-context model; bad/expired key → check the MiniMax key in Settings; rate-limited → wait a moment, then resend. This shares the exact classifyAnthropicCompatPlaceholderError path the DeepSeek/Kimi/GLM siblings use. Out of balance is the exception when another row can pay: if MiniMax's supply list has another row that can serve, the session moves to it and resends your message instead of stopping (see model-vendors.md). See provider-spawn-model-availability-contract.md vendor-error-is-classified-and-named.

Cost tracking

Spend hits the standard api_cost_log table because the claude CLI emits per-turn cost events in its stream-json output and the spawn layer already plumbs those into the cost tracker. The source field on the cost row carries the provider ID (minimax), so the Stats → Spend dashboard breaks down MiniMax spend separately from Claude/Codex/Gemini.

Cost is re-priced, not taken verbatim. The claude binary computes its total_cost_usd from its OWN (Claude) price table, which has no MiniMax row — so it bills MiniMax at Claude rates (live-confirmed 2026-06-26: MiniMax-M3 logged ~$5/M vs its real $0.30/M, a ~17× overcharge). MiniMax is therefore costReporting: 'estimated', and Omniscio recomputes each turn's cost from the token counts × MiniMax's real per-M rate (api-cost-tracker.ts MODEL_PRICING) via applyAnthropicCompatReprice — the same token-pricing path Codex uses. Shared by all four anthropic-compat vendors (DeepSeek/Kimi/GLM/MiniMax). See central-ai-spend-contract.md anthropic-compat-cost-is-repriced.

Prompt-cache reads bill at the real cache-hit rate. MiniMax's Anthropic-compat API returns cache_read_input_tokens, and its official "Prompt caching Read" rate is ~0.2× input, not the 0.1×-input default: MiniMax-M3 / MiniMax-M2.7 read at $0.06/M and MiniMax-M2.5 / MiniMax-M2 at $0.03/M (platform.minimax.io/docs/guides/pricing-paygo, confirmed 2026-08-22), carried as cacheRead overrides on those MODEL_PRICING rows.

Telemetry: every successful MiniMax spawn fires the spawn_non_claude_session feature event, recording { provider: 'minimax' } only — no session ID, project ID, or prompt content.

For agents

How it works under the hood

Spawn-env redirect, no alternate manager. MiniMax publishes an Anthropic-compatible API — same request/response shape as Anthropic's Messages API, just at a different base URL. So Omniscio reuses the existing claude CLI binary (the same one Claude sessions use) and redirects every HTTP call at spawn time by setting two environment variables on the child process:

• ANTHROPIC_BASE_URL=https://api.minimax.io/anthropic — sends every HTTP request to MiniMax's compat endpoint instead of api.anthropic.com (the CLI appends /v1/messages).
• ANTHROPIC_AUTH_TOKEN=<your MiniMax API key> — supersedes the Claude OAuth/API-key for this child only.

The child process never knows it isn't talking to Anthropic. Streaming, tool calls, --resume for multi-turn, --output-format stream-json parsing all "just work" because they're handled by the standard claude binary against an upstream that speaks the same protocol.

No alternate session manager exists for MiniMax — readiness gates, the spawn_non_claude_session feature event fires, then it falls through to the same createSessionWithPrompt() path Claude sessions use. The provider: 'minimax' value is stored on the session row in the database; spawn-cluster-manager.ts reads that column and injects the right spawn-env on every CLI invocation (initial spawn, resume, aside-runner).

Because MiniMax runs the claude binary, it is eligible for the same crash/restart/suspended/re-arm recovery as native Claude (claude --resume re-applies the MiniMax env overlay from the session row) — distinct from Anthropic account machinery (rate-limit recovery, load-balancing), which it stays out of since it authenticates with your MiniMax key, not an Anthropic login.

Compared to:

• DeepSeek / Kimi / GLM — same shape exactly (Anthropic-compat, no binary, spawn-env redirect). The only differences are the vendor base URL and the credential field. MiniMax is the fourth member of this anthropic-compat family and shares every code path with them.
• Codex / Anti-Gravity — separate CLI binaries with their own protocols; need dedicated *-session-manager.ts files. MiniMax does not.
• Gemini — a long-lived gemini --acp ACP child per session (its own JSON-RPC protocol). MiniMax keeps the long-lived claude child process; resume via claude --resume <uuid>.
• OpenClaw — remote WebSocket gateway. MiniMax is plain HTTP to a vendor-hosted compat endpoint.

Files

• src/shared/providers/registry.ts — the minimax descriptor (anthropic-compat runtimeKind, capabilities, label, pickerOrder)
• src/main/services/providers/main-registry.ts — the MiniMax readiness wiring (toggle + API-key gates, no binary gate)
• src/main/services/anthropic-compat-provider.ts — the api.minimax.io base URL + credential accessors (ANTHROPIC_COMPAT_PROVIDERS membership)
• src/main/services/minimax-credential-store.ts — the encrypted minimaxApiKey store
• src/main/process/spawn-cluster-manager.ts — injects ANTHROPIC_BASE_URL + ANTHROPIC_AUTH_TOKEN per session row's provider column
• src/shared/types/provider-readiness.ts — ProviderId union
• src/shared/types/settings/accounts-providers-settings.ts — allowMinimaxSessionSpawn setting
• src/shared/types/settings/ai-features-settings.ts — minimaxApiKey setting
• src/renderer/src/features/settings/sections/accounts/AccountSettings.tsx — MiniMax section under "Show alternative AI providers"

Related

Related

• glm-provider.md — same shape (Anthropic-compat, no binary, spawn-env redirect), different vendor + key
• model-vendors.md — who pays for a MiniMax session and which company serves it (the supply list)
• kimi-provider.md — another anthropic-compat sibling
• deepseek-provider.md — the other anthropic-compat sibling
• ai-providers.md — landing page for the full provider matrix
• provider-registry-contract.md — the DeepSeek + Kimi + GLM + MiniMax (anthropic-compat) invariants