Add MiniMax as a first-class LLM provider

[octo-patch]

Summary

Add MiniMax as a first-class LLM provider in NeMo Guardrails, enabling users to configure MiniMax models (M2.7, M2.5, M2.5-highspeed) via the standard config.yml with engine: minimax.

MiniMax provides an OpenAI-compatible API, so the integration uses ChatOpenAI from langchain-openai under the hood with MiniMax's API endpoint (https://api.minimax.io/v1). This follows the same pattern used by the existing NIM provider initializer.

Changes

• nemoguardrails/llm/models/langchain_initializer.py: Add _init_minimax_model() function and register "minimax" in _PROVIDER_INITIALIZERS
  • Uses ChatOpenAI with MiniMax's base URL
  • Supports MINIMAX_API_KEY env var and api_key parameter
  • Temperature clamping to [0, 1] range (MiniMax constraint)
  • Custom base_url override support
• examples/configs/llm/minimax/config.yml: Configuration example
• examples/configs/llm/minimax/README.md: Documentation with available models and usage
• tests/llm/models/test_minimax_provider.py: 16 tests (unit + integration)
  • Provider registry verification
  • Model initialization with various parameters
  • Temperature clamping validation
  • API key from env var and kwargs
  • Multiple model variants (M2.7, M2.5, M2.5-highspeed)
  • Import error handling
  • End-to-end initialization via _handle_model_special_cases

Usage

models:
  - type: main
    engine: minimax
    model: MiniMax-M2.5
    parameters:
      temperature: 0.7

Set the API key via environment variable:

export MINIMAX_API_KEY="your-api-key-here"

Test Plan

• All 16 new tests pass (pytest tests/llm/models/test_minimax_provider.py)
• Existing provider tests unaffected (pytest tests/llm/models/test_langchain_special_cases.py — 6 passed, 4 skipped)
• No changes to existing provider behavior
• Manual verification with live MiniMax API key (test included, runs when MINIMAX_API_KEY is set)

[Pouyanpi]

Thank you @octo-patch for the PR.

Is there any reason that you are avoiding following config:

models:
  - type: main
    engine: openai 
    model: MiniMax-M2.7
    parameters:
      api_key: ${MINIMAX_API_KEY}
      base_url: https://api.minimax.io/v1
      temperature: 0.5

[octo-patch]

Great point @Pouyanpi! You're right — since MiniMax's API is OpenAI-compatible, using the openai engine with a custom base_url is a perfectly valid approach and avoids introducing a separate engine.

The main reason for the dedicated engine was to handle MiniMax-specific behavior like temperature clamping (MiniMax requires temperature > 0) and think-tag stripping from reasoning model responses. But these could also be handled as pre/post-processing within the openai engine config.

If you'd prefer the simpler openai engine approach with base_url override, I'm happy to refactor the PR to use that pattern instead. Just let me know which direction you'd like!