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!

[greptile-apps]

Greptile Summary

This PR adds MiniMaxCallable and AsyncMiniMaxCallable to the provider list, routing model names starting with \"MiniMax\" through the OpenAI-compatible api.minimax.io/v1 endpoint.

• The API key guard (if resolved_api_key is None) does not catch an empty-string key — api_key or os.environ.get(\"MINIMAX_API_KEY\") evaluates to \"\" when the env var is set to an empty string, bypassing the check and producing an opaque downstream error instead of the intended message. The fix is if not resolved_api_key:. The same issue exists in AsyncMiniMaxCallable.
• The corresponding test relies on this broken guard and passes only because PromptCallableBase.__call__ wraps all exceptions — it is not testing the intentional validation path.

Confidence Score: 4/5

Safe to merge after fixing the API key validation (is None to not) in both callable classes and aligning the test.

Two P1 findings: the empty-string API key bypasses the explicit guard in both MiniMaxCallable and AsyncMiniMaxCallable, and the test that is supposed to cover this case is silently relying on downstream exception wrapping rather than the intended validation. These are quick one-line fixes but should be addressed before merge.

guardrails/llm_providers.py (lines 303-307 and 886-890) and tests/unit_tests/test_llm_providers.py (lines 415-426)

Important Files Changed

Filename	Overview
guardrails/llm_providers.py	Adds MiniMaxCallable and AsyncMiniMaxCallable; routing logic in get_llm_ask / get_async_llm_ask looks correct, but API key validation uses is None instead of not resolved_api_key, silently passing empty-string keys to OpenAI client.
tests/unit_tests/test_llm_providers.py	Adds tests for MiniMaxCallable sync path; the no-API-key test passes for the wrong reason (empty-string vs. None check mismatch), and AsyncMiniMaxCallable routing via get_async_llm_ask is not covered.

Comments Outside Diff (4)

1. guardrails/llm_providers.py, line 302-307 (link)

   API key validation misses empty-string keys

   is None only catches a missing key; an empty string (MINIMAX_API_KEY="") evaluates None or "" → "", which is not None, so the guard never fires. The code then calls openai.Client(api_key=""), which eventually fails with an opaque OpenAI auth error instead of the intended clear message. The same bug is in AsyncMiniMaxCallable at line 886–890.

2. guardrails/llm_providers.py, line 313-315 (link)

   Silent temperature override may surprise callers

   The condition kwargs.get("temperature", 0) == 0 is intentionally true when no temperature is provided (default 0), but it is also true when a caller explicitly passes temperature=0. Since MiniMax forbids temperature=0, overriding it to 1.0 is necessary, but doing so silently discards the user's explicit choice. Adding a warnings.warn when the passed value is exactly 0 would surface this constraint rather than silently change it. The same pattern is repeated in AsyncMiniMaxCallable at line 898–899.

3. tests/unit_tests/test_llm_providers.py, line 415-426 (link)

   Test passes for the wrong reason

   mocker.patch.dict("os.environ", {"MINIMAX_API_KEY": ""}) sets the key to an empty string, not removes it. With the current is None check in _invoke_llm, resolved_api_key evaluates to "" (not None), so the guard never fires. The test passes only because PromptCallableBase.__call__ wraps all downstream exceptions as PromptCallableException. If the validation check is fixed to if not resolved_api_key:, the test would immediately test the right code path. In the meantime this is masking the empty-string bug described above.

4. guardrails/llm_providers.py, line 309 (link)

   New OpenAI client created on every invocation

   openai.Client(...) is instantiated inside _invoke_llm, so every call to the callable creates a new HTTP client with its own connection pool. The same applies to AsyncMiniMaxCallable at line 893. Caching the client as an instance attribute set during __init__ would reuse the underlying connection pool across calls, consistent with how most SDK clients are intended to be used.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: guardrails/llm_providers.py
Line: 302-307

Comment:
**API key validation misses empty-string keys**

`is None` only catches a missing key; an empty string (`MINIMAX_API_KEY=""`) evaluates `None or ""` → `""`, which is not `None`, so the guard never fires. The code then calls `openai.Client(api_key="")`, which eventually fails with an opaque OpenAI auth error instead of the intended clear message. The same bug is in `AsyncMiniMaxCallable` at line 886–890.

```suggestion
        resolved_api_key = api_key or os.environ.get("MINIMAX_API_KEY")
        if not resolved_api_key:
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: guardrails/llm_providers.py
Line: 313-315

Comment:
**Silent temperature override may surprise callers**

The condition `kwargs.get("temperature", 0) == 0` is intentionally true when no temperature is provided (default 0), but it is also true when a caller explicitly passes `temperature=0`. Since MiniMax forbids `temperature=0`, overriding it to `1.0` is necessary, but doing so silently discards the user's explicit choice. Adding a `warnings.warn` when the passed value is exactly `0` would surface this constraint rather than silently change it. The same pattern is repeated in `AsyncMiniMaxCallable` at line 898–899.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: tests/unit_tests/test_llm_providers.py
Line: 415-426

Comment:
**Test passes for the wrong reason**

`mocker.patch.dict("os.environ", {"MINIMAX_API_KEY": ""})` sets the key to an empty string, not removes it. With the current `is None` check in `_invoke_llm`, `resolved_api_key` evaluates to `""` (not `None`), so the guard never fires. The test passes only because `PromptCallableBase.__call__` wraps all downstream exceptions as `PromptCallableException`. If the validation check is fixed to `if not resolved_api_key:`, the test would immediately test the right code path. In the meantime this is masking the empty-string bug described above.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: guardrails/llm_providers.py
Line: 309

Comment:
**New OpenAI client created on every invocation**

`openai.Client(...)` is instantiated inside `_invoke_llm`, so every call to the callable creates a new HTTP client with its own connection pool. The same applies to `AsyncMiniMaxCallable` at line 893. Caching the client as an instance attribute set during `__init__` would reuse the underlying connection pool across calls, consistent with how most SDK clients are intended to be used.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "feat: add MiniMax provider support via O..." | Re-trigger Greptile}