---
title: MiniMax provider (run sessions on MiniMax's API)
---

# MiniMax Provider

## 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 (off by default) 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](https://platform.minimax.io) (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](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](../../src/shared/providers/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](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](../../.claude/memory/contracts/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](model-vendors.md)). See [provider-spawn-model-availability-contract.md](../../.claude/memory/contracts/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](../../src/main/services/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](../../.claude/memory/contracts/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](../../src/main/process/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](../../src/shared/providers/registry.ts) — the `minimax` descriptor (`anthropic-compat` runtimeKind, capabilities, label, pickerOrder)
- [src/main/services/providers/main-registry.ts](../../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](../../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](../../src/main/services/minimax-credential-store.ts) — the encrypted `minimaxApiKey` store
- [src/main/process/spawn-cluster-manager.ts](../../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](../../src/shared/types/provider-readiness.ts) — `ProviderId` union
- [src/shared/types/settings/accounts-providers-settings.ts](../../src/shared/types/settings/accounts-providers-settings.ts) — `allowMinimaxSessionSpawn` setting
- [src/shared/types/settings/ai-features-settings.ts](../../src/shared/types/settings/ai-features-settings.ts) — `minimaxApiKey` setting
- [src/renderer/src/features/settings/sections/accounts/AccountSettings.tsx](../../src/renderer/src/features/settings/sections/accounts/AccountSettings.tsx) — MiniMax section under "Show alternative AI providers"

## Related

### Related

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