feat: add MiniMax provider support via direct API

[octo-patch]

Summary

This PR adds direct MiniMax API support alongside the existing HF-router path.

What changes:

• agent/core/llm_params.py: adds minimax/<model> prefix routing that resolves to the MiniMax OpenAI-compatible endpoint (https://api.minimax.io/v1) using MINIMAX_API_KEY. Reasoning effort is silently ignored (MiniMax doesn't support thinking modes). The endpoint can be overridden via MINIMAX_BASE_URL (useful for the Chinese mirror api.minimaxi.com).
• agent/core/model_switcher.py: adds minimax/MiniMax-M2.7 and minimax/MiniMax-M2.7-highspeed to SUGGESTED_MODELS and updates the /model help text to mention the new prefix.
• backend/routes/agent.py: adds the two direct-API model entries to AVAILABLE_MODELS.
• README.md: documents MINIMAX_API_KEY and the --model minimax/MiniMax-M2.7 usage example.
• tests/unit/test_minimax_provider.py: 12 unit tests covering routing, env var handling, base URL override, and effort passthrough.

Why: The existing MiniMaxAI/MiniMax-M2.7 entry routes through the HF router. A direct minimax/ prefix lets users with a MINIMAX_API_KEY call api.minimax.io without HF intermediation — same pattern as anthropic/ and openai/ prefixes.

API reference

• Chat (OpenAI Compatible): https://platform.minimax.io/docs/api-reference/text-openai-api

Test plan

• 12 unit tests pass (pytest tests/unit/test_minimax_provider.py -v)
• Integration verified: MiniMax-M2.7 responds correctly at api.minimax.io/v1

[akseljoonas]

@claude please review this PR. Focus on correctness, security, LiteLLM/Bedrock routing impact, and whether it's safe to merge against current main. Keep it concise and prefer inline comments where it matters.

[claude]

Claude finished @akseljoonas's task in 1m 52s —— View job

---

PR Review: feat: add MiniMax provider support via direct API

Tasks

• Read CLAUDE.md for repo guidelines
• Read changed files
• Analyze correctness, security, routing impact
• Post review findings

---

Summary

Implementation is correct and well-structured. No existing routing (LiteLLM, Bedrock, HF router) is affected. One functional bug, one label inconsistency, and a minor test fragility worth fixing before merge.

---

Bug — minimax/ missing from _print_hf_routing_info early-return

agent/core/model_switcher.py:68

if model_id.startswith(("anthropic/", "openai/")):
    return True

minimax/ is not in this tuple. When a CLI user runs /model minimax/MiniMax-M2.7, the function falls through to the HF router catalog lookup, prints a misleading "Warning: 'minimax/MiniMax-M2.7' isn't in the HF router catalog" banner, and then continues. The probe succeeds, so it's not a hard failure — but the warning is confusing and looks like a broken config.

Fix: add "minimax/" (and "bedrock/") to the tuple. Fix this →

---

Minor — "tier": "free" is misleading for a model that requires a private API key

backend/routes/agent.py:56-67

{"id": "minimax/MiniMax-M2.7", ..., "tier": "free"},
{"id": "minimax/MiniMax-M2.7-highspeed", ..., "tier": "free"},

"free" here means "no HF org gate" (Bedrock/Anthropic models use "pro" to trigger the HF membership check). But MiniMax models still require a user-supplied MINIMAX_API_KEY — a credential distinct from HF tokens. If the frontend uses tier for "no credentials needed", this could quietly confuse users who select these models and get a bare 401 with no local hint. A "tier": "api_key" or a note in the label would be cleaner, but that requires a frontend change. At minimum, worth tracking the inconsistency.

---

Minor — api_key=None silently passed to LiteLLM

agent/core/llm_params.py:192-197

api_key = os.environ.get("MINIMAX_API_KEY")
return {
    "model": f"openai/{minimax_model}",
    "api_base": base_url,
    "api_key": api_key,   # None when key is unset
}

When MINIMAX_API_KEY is absent, api_key=None is forwarded. LiteLLM will attempt the call and MiniMax's API returns a 401. This is consistent with how HF_TOKEN can also be None in the HF path, so it's an intentional "let the provider reject it" pattern — no regression, just no friendly local pre-flight message. Acceptable.

---

Minor — test module pollution risk

tests/unit/test_minimax_provider.py:108-109

sys.modules.setdefault("agent.core.effort_probe", mock_module)
sys.modules.setdefault("agent.core", MagicMock())

setdefault means the mock is only injected if the key is absent — if another test has already imported the real agent.core, this is a no-op and the test may fail spuriously. Prefer unittest.mock.patch.dict(sys.modules, {...}) as a context manager so the stub is always applied and cleaned up after the test.

---

LiteLLM / Bedrock routing impact — no regressions

The new minimax/ branch in _resolve_llm_params sits after bedrock/ (line 165) and openai/ (line 173), so:

prefix	path	unchanged?
bedrock/	LiteLLM Converse adapter	✅
anthropic/	Native thinking config	✅
openai/	OpenAI adapter	✅
minimax/	New branch → OpenAI adapter + custom api_base	new
anything else	HF router fallthrough	✅

The openai/{minimax_model} forwarding pattern is exactly right — LiteLLM uses the OpenAI adapter with our overridden api_base, which is the correct approach for any OpenAI-compatible endpoint.

---

Verdict

Safe to merge with one fix: the missing minimax/ in _print_hf_routing_info. The rest are quality improvements. Core routing, Bedrock, and HF-router paths are unaffected.