feat: add MiniMax as first-class LLM provider (default M3)

[octo-patch]

Summary

• Add MiniMax as a built-in model provider alongside OpenAI and Gemini
• Default model is now MiniMax-M3 (512K context, up to 128K output, image input support); MiniMax-M2.7 and MiniMax-M2.7-highspeed remain available as alternatives
• Provider extends OpenAIProvider with MiniMax-specific behavior: temperature clamping to (0.0, 1.0], <think> tag stripping for reasoning-model output, MINIMAX_API_KEY auto-detection, and forced Chat Completions protocol

Changes

File	Description
runtime/node/agent/providers/minimax_provider.py	New MiniMaxProvider class extending OpenAIProvider; docstring lists M3 (default) / M2.7 / M2.7-highspeed
runtime/node/agent/providers/builtin_providers.py	Register minimax in ProviderRegistry with M3 in the summary
tests/test_minimax_provider.py	35 unit tests + 3 integration tests; default model fixture and assertions use MiniMax-M3
README.md	Supported-providers table lists M3 (default), M2.7, M2.7-highspeed

Usage

Set MINIMAX_API_KEY in .env and configure agent nodes:

model:
  provider: minimax
  name: MiniMax-M3
  api_key: ${MINIMAX_API_KEY}

Why M3 as default

MiniMax-M3 is the latest MiniMax model and offers significant upgrades over the previous generation: 512K context window (vs 192K for M2.7), up to 128K max output, and image input via the OpenAI-compatible API. Older M2.5/M2.5-highspeed models are no longer listed since they are superseded by the kept M2.7 line plus the new M3 default.

Test plan

• 35 unit tests covering init defaults (including M3 default check), temperature clamping, think-tag stripping, response deserialization, token tracking, payload construction, provider registration, regex patterns, and client creation
• 3 integration tests (skipped without MINIMAX_API_KEY) verifying real API calls with M3 and M2.7-highspeed models
• All tests pass

[NA-Wen]

Thanks a lot for the contribution! This is a very solid addition and we really appreciate the effort in making MiniMax a first-class provider in the system!

One thing we’d like to further discuss is the necessity of introducing a dedicated provider for each model vendor. Since many providers (including MiniMax) expose OpenAI-compatible APIs, it might be possible to reuse a more unified abstraction with minimal adaptation, rather than maintaining separate provider implementations 🤔.

It would be helpful to better understand the design trade-offs here—for example, whether the provider-specific logic (e.g., parameter constraints, output post-processing like think-tag stripping, etc.) justifies a separate provider, or if these differences could be handled in a more generic layer.

Looking forward to your thoughts!