feat: MiniMax provider implementation in @getpaseo/server so chat-page context button surfaces MiniMax quota (matches what #1662 did for the Settings card)

[jonocodes]

The user need

When I open a Claude chat in Paseo, the context-window button in the chat header shows the active quota windows (5-hour + weekly) for Anthropic. When I open Codex, the same — OpenAI's windows. The same panel for MiniMax shows nothing today, even though #1662 just shipped a MiniMaxQuotaProvider and the Settings → Host Usage card shows the data.

Two users in one: I have the data in Settings, but the chat header is silent. That's the gap.

What I traced

The chat-page context button looks up "what's the active provider's quota fetcher?" against the same quota-fetcher manifest that the Settings card iterates. So far so good — minimax is in the manifest since #1662.

The lookup is keyed on the provider ID of the currently running agent. Today, no Paseo agent ever registers provider ID minimax, because there's no minimax provider implementation in packages/server/src/server/agent/providers/. The directory has claude/, codex/, opencode/, copilot-acp-agent, cursor-acp-agent, kiro-acp-agent, trae-acp-agent, pi/, omp/, acp-agent/, generic-acp-agent/ — no minimax.

Consequence:

• MiniMax doesn't appear in the agent dropdown, so users can't open MiniMax sessions in Paseo at all.
• Even if they could, the chat-page context lookup would resolve minimax against the manifest and should light up — but since no session has provider minimax today, no one has seen that path work yet.

Settings is fine because Settings iterates the manifest. Chat is broken because no session has the right provider ID.

What's needed

A MiniMax provider implementation in @getpaseo/server that registers provider ID minimax and can open sessions. The simplest viable version:

1. MiniMaxProviderDescriptor in the protocol package — like ClaudeProviderDescriptor. Just registers provider ID + display name + icon (icon already exists from feat: add MiniMax quota fetcher and brand icon #1662).

2. minimax-acp-agent provider in packages/server/src/server/agent/providers/, modelled on the existing kiro-acp-agent / copilot-acp-agent providers. Spawns the official mmx-cli (github.com/MiniMax-AI/cli, currently v1.0.19) as an ACP subprocess and forwards prompts via the ACP protocol. If mmx-cli doesn't natively speak ACP (it currently doesn't, to my knowledge — it has its own RPC), this is the only nontrivial bit of the change.

3. terminalProfiles entry in config.json so users can run MiniMax sessions from the agent dropdown, analogous to the existing "command": "claude", "opencode", "codex" entries.

That's roughly three small PRs' worth of work, not a giant rewrite. The hardest unknown is the ACP adapter — mmx-cli is text/image/video/etc. capable but its IPC story is its own JSON-RPC dialect today, so either:

• (a) extend mmx-cli to speak ACP natively (changes to mmx-cli, not just Paseo), or
• (b) write a small ACP↔mmx-RPC shim in @getpaseo/server (Paseo-only change).

Either way, the chat-page context button lights up the moment providerID === "minimax" is reachable, because the quota fetcher is already wired.

What this is NOT asking for

• Per-turn token metering in the chat timeline (cost chart, prompt cache stats, etc.). That's a separate, larger piece and would need usage events on each turn.
• Billing-history graphs in the menu (the CodexBar-style MiniMax menu). Separate feature.
• Removing the existing ~/.mmx/credentials.json resolver from feat: add MiniMax quota fetcher and brand icon #1662 — already noted separately as a bug in feat: source provider credentials from ~/.local/share/opencode/auth.json as a fallback (unblocks MiniMax quota for opencode users) #3296.

What I've already done locally

I bumped to Paseo 0.2.5 (first 0.2.x with the MiniMax quota fetcher) and added a small NixOS module option services.paseo.opencodeAuthBridge that pulls API keys out of ~/.local/share/opencode/auth.json and exposes them as $MINIMAX_API_KEY (default) / $ZAI_API_KEY / etc. to the daemon, so users who configure providers through opencode don't need to maintain a second credential store for the Settings quota panel. The fix is local — it short-circuits the credential lookup the Settings card needs. It does not address the chat-page gap; that's exactly what this proposal is about. Filed upstream at #3296.

Happy to send a PR for the descriptor + ACP shim if there's interest — wanted to scope-check the approach first since adding a new provider is a more substantial commitment than a quota-fetcher addition.

[jonocodes]

Update after research: there is a related, separate bug at #1390 (handleUsageUpdate is a no-op in acp-agent.ts) that breaks the chat-page context-window meter (per-session tokens-used vs max) for all ACP providers. That is a different surface from the quota meter (5-hour/weekly windows) discussed here. So a MiniMax-via-ACP provider per this proposal still would not show the context-window meter until #1390 is fixed. Tracking both as layered requirements for the chat-page experience to be complete for MiniMax.