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

[octo-patch]

Summary

Add MiniMax as a built-in LLM service provider for Magic, with MiniMax-M3 as the default model. MiniMax serves an OpenAI-compatible API at https://api.minimax.io/v1.

Available models

Model	Notes
MiniMax-M3 (default)	512K context, up to 128K output, image input
MiniMax-M2.7	Previous-gen flagship
MiniMax-M2.7-highspeed	Previous-gen low-latency variant

Older MiniMax-M2.5 is no longer surfaced in the provider description or tests.

Changes

Backend (PHP)

• ProviderCode.php: Register MiniMax enum case with OpenAIModel implementation
• ProviderTemplateId.php: Add MiniMaxLlm = '23' template ID for provider-category mapping
• ServiceProviderInitializer.php: Add MiniMax provider initialization data with bilingual (EN/CN) descriptions referencing M3 as default, M2.7 and M2.7-highspeed as alternatives
• LLMMiniMaxProvider.php: Connectivity test class that sends a minimal POST /chat/completions request using the configured modelVersion; MiniMax-specific temperature clamping to (0.0, 1.0]

Frontend (TypeScript)

• aiModel.ts: Add MiniMax to ServiceProvider enum with default API URL

Tests

• ProviderCodeMiniMaxTest.php: Unit tests for enum, implementation, sort order, template ID mapping
• LLMMiniMaxProviderTest.php: Unit tests for connectivity test with mock HTTP (success, auth error, network error) using MiniMax-M3 as the validated model
• ServiceProviderInitializerMiniMaxTest.php: Unit tests for provider data, translations (including M3 assertion), sort order uniqueness

Integration notes

• MiniMax uses the standard OpenAI-compatible API format, so it falls through to the default case in ProviderConfigFactory and getImplementationConfig() — no special adapter needed
• Temperature=0 is rejected by MiniMax; the connectivity test clamps to 0.01
• MiniMax-M3 supports image input on both the OpenAI-compatible and Anthropic-compatible endpoints

Test Plan

• Unit tests for ProviderCode enum (implementation, sort order, template mapping)
• Unit tests for LLMMiniMaxProvider connectivity test (mock HTTP)
• Unit tests for ServiceProviderInitializer data integrity (M3 + M2.7 surfaced)
• Manual: Configure MiniMax provider in admin UI with API key
• Manual: Verify chat completion through MiniMax-M3

[JiwaniZakir]

In LLMMiniMaxProvider::connectivityTestByModel, the $modelVersion parameter is accepted but never actually used — the method only calls fetchModels regardless of which model is being tested. This means a connectivity check won't catch model-specific access issues (e.g., a valid API key that lacks access to a specific model variant), which contradicts the intent implied by the method signature. Other providers that do a real completion probe with the given model version catch exactly this class of failure.

Additionally, $apiBase is hardcoded to https://api.minimax.io/v1 and is never read from $serviceProviderConfig. If ProviderConfigItem exposes a custom base URL (as it does for the generic OpenAI-compatible provider), MiniMax users have no way to point at a proxy or an alternative endpoint — worth either documenting as intentional or adding support via $serviceProviderConfig->getApiBase().

Finally, in ProviderCode::getImplementation(), the explicit self::MiniMax => OpenAIModel::class mapping is immediately followed by default => OpenAIModel::class, making it a no-op. Since the intent is to signal that MiniMax uses the OpenAI-compatible path, a short inline comment would make that clearer than a redundant match arm.

[octo-patch]

Addressed the review feedback in de247f6:

1. Duplicate code (@cursor[bot]): LLMMiniMaxProvider is now structurally distinct from LLMDeepSeekProvider. Instead of calling fetchModels() (a GET to /models), it now uses testChatCompletion() which sends a minimal POST to /chat/completions -- matching the LLMVolcengineProvider pattern. It also applies MiniMax-specific temperature clamping (0.01, since MiniMax requires temperature strictly in (0.0, 1.0]).

2. Unused $modelVersion (@JiwaniZakir): The parameter is now passed through to testChatCompletion() and used as the model field in the chat completion payload, so the test actually validates that the specific model is accessible.

Thanks for the thorough review!

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Tests mock nonexistent method, bypassing HTTP mocks entirely

High Severity

The test subclasses override a fetchModels method that does not exist on LLMMiniMaxProvider. The actual provider calls testChatCompletion, so the mock HTTP client is never used. All three tests (testConnectivityTestSucceedsWithValidApiKey, testConnectivityTestFailsWithInvalidApiKey, testConnectivityTestFailsOnNetworkError) will make real HTTP requests to api.minimax.io instead of using the mocked responses, making them flaky and not actually testing the intended behavior. The override needs to target testChatCompletion instead of fetchModels.

Additional Locations (2)

• backend/magic-service/test/Cases/Unit/Provider/LLMMiniMaxProviderTest.php#L112-L123
• backend/magic-service/test/Cases/Unit/Provider/LLMMiniMaxProviderTest.php#L153-L164

 

[cursor]

Tests call nonexistent getStatus() instead of isStatus()

Medium Severity

The tests call $response->getStatus() on a ConnectResponse object, but ConnectResponse only defines isStatus() for the boolean $status property. There is no getStatus() method and no __call magic method anywhere in the class hierarchy (BaseObject → AbstractObject → AbstractEntity → ConnectResponse), so every test assertion using getStatus() will fail at runtime with an undefined method error.

Additional Locations (2)

• backend/magic-service/test/Cases/Unit/Provider/LLMMiniMaxProviderTest.php#L82-L83
• backend/magic-service/test/Cases/Unit/Provider/LLMMiniMaxProviderTest.php#L129-L130

 

[JiwaniZakir]

The three issues flagged by Cursor are all valid and should be addressed before merging. The duplication between LLMMiniMaxProvider and LLMDeepSeekProvider suggests these should share a base class or be parameterized by $apiBase rather than copy-pasted. The test issues are more critical — mocking a non-existent fetchModels method means the connectivity test path is never actually exercised, and calling getStatus() instead of isStatus() means the tests would fail or silently pass for the wrong reasons; both need to be fixed to give the test suite any real coverage.