[octo-patch]

Reason: The Pi backend had no built-in MiniMax provider or current MiniMax-M3.1-Flash/MiniMax-M3 presets. This update refreshes the existing provider PR to the authorized Flash-first rollout while preserving the generic provider and saved/custom route surfaces.

What changed

The Pi backend now registers minimax/MiniMax-M3.1-Flash first and minimax/MiniMax-M3 second, with explicit 1M-token contexts, current direct OpenAI-compatible pricing metadata, and adaptive reasoning metadata. It adds global and CN endpoint presets, MINIMAX_REGION selection, MINIMAX_BASE_URL and --ai-base-url precedence, and runtime MINIMAX_API_KEY wiring.

Flash maps Pi xhigh to MiniMax max; M3 keeps its adaptive OpenAI default and does not advertise effort mapping. The Pi type surface supports text/image labels; MiniMax video capability remains outside this ordinary text-agent integration. Existing non-MiniMax providers, gateway routes, saved/custom/legacy routes, and media integrations are untouched.

Why

Deepsec could not resolve a first-class minimax/... model route offline or select the current Flash-first model by default. Registering a static provider catalog keeps Pi model discovery credential-free and avoids remote catalog fetches while retaining the existing custom provider controls.

Verification

• Source invariants passed for Flash-first ordering, model IDs, 1M contexts, direct prices, regional URLs, auth wiring, and single Flash effort mapping.
• Focused source assertions passed for offline model resolution coverage, CN/global/custom endpoint precedence coverage, saved custom route/key/header coverage, and a fetch guard in the added tests.
• git diff --check passed for all four owned provider files.
• A credential-free pnpm install --offline --ignore-scripts --frozen-lockfile was attempted under the light-install lock and stopped because @biomejs/biome@2.4.13 is absent from the local pnpm store. The added Vitest cases therefore were not executed locally; no network install, paid inference, or model request was performed.
• GitHub CI after push: Socket Security checks passed; Vercel deployment checks remain blocked by the repository's existing Team authorization requirement.

Notes for reviewer

The existing open PR #133 was updated on its original fork head branch after merging current main. The rollout commits are 528052d154d0aa5ad15ea2b74d83532fe6c4611c and 363e94591949ec7e785241a079bde12036eaa8f6; the latter also isolates generic custom-provider overrides from the MiniMax preset.

[vercel]

@octo-patch is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[auto-maintain]

🤖 auto-maintain review

Automated, advisory triage for @octo-patch's PR. Facts below are read from the GitHub API.

Check	Result
Author's merged PRs (this repo)	0 — ⚠️ first-time contributor
Account established	✅ (age 225d · 213 followers · 1595 public repos)
Commits signed/verified	⚠️ 0/2

Review panel: 🔴 high highest severity

deepsec maintainer code review: 🔴 high

The preset is not usable through the documented CLI or sandbox paths and can break persisted custom MiniMax models.

• docs/models.md:181 — The documented MINIMAX_API_KEY-only command is rejected before Pi starts: assertAgentCredential() does not recognize MINIMAX_API_KEY unless users redundantly pass --ai-api-key-env.
• docs/models.md:203 — Sandbox MiniMax is nonfunctional as documented. MINIMAX_* variables are neither forwarded nor brokered; allowedHosts only permits egress and does not inject the real credential, so workers fail preflight or send a placeholder token and receive 401.
• packages/processor/src/agents/pi-sdk.ts:156 — Registering a fixed models array replaces the existing minimax provider model set, dropping custom MiniMax entries loaded from models.json. The custom-route test uses an empty registry and never resolves custom-saved, so it misses this persisted-data regression.

General code review: 🟡 medium

The preset works only after bypassing missing credential integration and introduces a compatibility break for custom MiniMax catalogs.

• docs/models.md:182 — The documented MINIMAX_API_KEY-only command fails preflight: Pi credential validation does not recognize MINIMAX_API_KEY unless --ai-api-key-env or an unrelated credential is present.
• docs/models.md:201 — Sandbox mode does not broker MINIMAX_API_KEY or propagate MINIMAX_REGION/MINIMAX_BASE_URL; allowedHosts alone cannot authenticate requests, so the preset is unusable there without explicit custom-route flags.
• packages/processor/src/agents/pi-sdk.ts:152 — Registering a fixed models array replaces persisted models.json entries for the existing `minimax` provider, breaking users' custom MiniMax model IDs despite preserving their route configuration.

Scanner and matcher quality: 🟡 medium

The MiniMax preset is registered, but its credential path is not integrated with local preflight or sandbox brokering.

• packages/processor/src/agents/pi-sdk.ts:154 — MINIMAX_API_KEY is consumed only after CLI preflight; Pi credential validation ignores it, so the documented command fails unless another credential exists or --ai-api-key-env is supplied.
• docs/models.md:201 — The sandbox preset is incomplete: MINIMAX_* variables are not forwarded or brokered, and merely adding the endpoint to allowedHosts sends the placeholder credential unchanged, causing authentication failure.

Sandbox and credential boundaries: 🟡 medium

Preset registration is functional locally but bypasses the sandbox credential-brokering/egress path and leaks unrelated provider overrides into the built-in minimax entry; fix the sandbox auth story and provider scoping before merge.

• docs/models.md:202 — Sandbox runs cannot actually use the new preset: MINIMAX_API_KEY is not in SANDBOX_ENV_KEYS and resolveBrokeredCredentials/buildWorkerNetworkPolicy only broker AI_GATEWAY_API_KEY or an explicit --ai-api-key-env paired with --ai-base-url (DEEPSEC_PI_AI_BASE_URL). Inside the VM the minimax provider therefore has no key, hasConfiguredAuth is false, and resolvePiModelWithDynamicGateway falls back to registering 'minimax/MiniMax-M3…' as a vercel-ai-gateway pass-through — so a sandboxed `--model minimax/...` silently runs against ai-gateway.vercel.sh with the brokered gateway token instead of MiniMax. The only guidance given (add the host to allowedHosts) opens egress to api.minimax.io without delivering any credential there.
• packages/processor/src/agents/pi-sdk.ts:154 — registerMiniMaxProvider is called unconditionally for every pi session and consumes the generic provider overrides without checking which provider the user selected. configureProviderOverrides deliberately scopes --ai-base-url/--ai-api-key-env/--ai-header to `cfg.aiProvider ?? modelProviderFromName(cfg.model)`; here a Martian/ACME route's key (cfg.aiApiKeyEnv) and headers are attached to a provider entry whose baseUrl defaults to api.minimax.io, and conversely a persisted custom route's baseUrl silently replaces the MiniMax region preset. It also makes hasConfiguredAuth true for the MiniMax models on runs that never intended to reach MiniMax.
• packages/processor/src/agents/pi-sdk.ts:104 — MINIMAX_FLASH_MAX_TOKENS is 524288, which contradicts its own comment ("matches the generic pass-through default" — createGatewayPassThroughModel and MINIMAX_DEEPSEC_MAX_TOKENS both use 32000) and the sibling M3 preset. If pi forwards this as max_tokens, Flash requests can be rejected outright for exceeding the provider's output cap, while M3 is capped at 32000 with no stated reason for the asymmetry.

Durability and distributed state: 🟢 low

No durability or distributed-state defects found in the MiniMax provider changes.

_{Posted by auto-maintain. This automated code review is advisory; a human maintainer makes the call.}