Repository navigation
feat: add MiniMax as LLM provider with M3 (default), M2.7 and M2.7-highspeed - #1937
octo-patch wants to merge 8 commits into
Conversation
Add MiniMax M2.5 models as a first-class provider using the OpenAI-compatible adapter (@ai-sdk/openai-compatible), following the same pattern as the existing Z.AI integration. Changes: - Register 'minimax' in SupportedProvider enum and BuiltinProvider type - Add createOpenAICompatible cases in both factory.ts and registry.ts - Add 'MiniMax-' prefix to MODEL_PROVIDER_MAP for auto-detection - Add MiniMax-M2.5 and MiniMax-M2.5-highspeed to model catalog - Add provider presets (auto/balanced/quick) and model equivalences - Add PROVIDER_REGISTRY entry for settings UI - Add MiniMax detection test in factory.test.ts MiniMax API: https://api.minimax.io/v1 (OpenAI-compatible) Models: MiniMax-M2.5 (204K context), MiniMax-M2.5-highspeed (204K) Env var: MINIMAX_API_KEY
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request integrates MiniMax as a new first-class Large Language Model (LLM) provider into the application. This enhancement allows users to leverage MiniMax M2.5 models, expanding the range of available AI capabilities within the multi-provider architecture. The changes ensure seamless detection, configuration, and utilization of MiniMax models alongside existing providers. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds MiniMax provider support: model definitions/presets/equivalences, a provider registry entry, and a unit test verifying ChangesMiniMax provider integration
Sequence Diagram(s)sequenceDiagram
participant Client
participant Registry
participant Factory
participant SDK as "OpenAI-compatible SDK"
participant MinimaxAPI as "minimax API"
Client->>Registry: request provider for modelId "minimax-m2.7"
Registry->>Factory: determine provider "minimax" and request instance
Factory->>SDK: createOpenAICompatible(name: "minimax", apiKey, baseURL)
SDK->>MinimaxAPI: send requests to https://api.minimax.io/v1
MinimaxAPI-->>SDK: responses
SDK-->>Factory: return provider client instance
Factory-->>Registry: provider instance
Registry-->>Client: provider ready
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
🎉 Thanks for your first PR!
A maintainer will review it soon. Please make sure:
- Your branch is synced with
develop - CI checks pass
- You've followed our contribution guide
Welcome to the Auto Claude community!
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request successfully adds MiniMax as a new LLM provider, integrating it across the application from provider registration to model configuration. The changes are well-structured and follow existing patterns. My feedback focuses on improving consistency and maintainability, specifically regarding naming conventions and code duplication.
| 'llama-': 'groq', | ||
| 'grok-': 'xai', | ||
| 'glm-': 'zai', | ||
| 'MiniMax-': 'minimax', |
There was a problem hiding this comment.
For consistency with other provider prefixes in MODEL_PROVIDER_MAP (e.g., 'claude-', 'gpt-', 'llama-'), which are all lowercase, it's recommended to use a lowercase prefix for MiniMax. This improves maintainability and predictability.
This change will require corresponding updates to model names in apps/desktop/src/shared/constants/models.ts and tests in apps/desktop/src/main/ai/providers/__tests__/factory.test.ts.
| 'MiniMax-': 'minimax', | |
| 'minimax-': 'minimax', |
| it('detects MiniMax from MiniMax- prefix', () => { | ||
| expect(detectProviderFromModel('MiniMax-M2.5')).toBe('minimax'); | ||
| }); |
There was a problem hiding this comment.
To align with the suggested change of using a lowercase prefix for MiniMax models for consistency, this test should be updated to use a lowercase model name and test description.
| it('detects MiniMax from MiniMax- prefix', () => { | |
| expect(detectProviderFromModel('MiniMax-M2.5')).toBe('minimax'); | |
| }); | |
| it('detects MiniMax from minimax- prefix', () => { | |
| expect(detectProviderFromModel('minimax-m2.5')).toBe('minimax'); | |
| }); |
| case SupportedProvider.MiniMax: | ||
| return createOpenAICompatible({ | ||
| name: 'minimax', | ||
| apiKey, | ||
| baseURL: baseURL ?? 'https://api.minimax.io/v1', | ||
| headers, | ||
| }); |
There was a problem hiding this comment.
This logic for creating the MiniMax provider is duplicated in apps/desktop/src/main/ai/providers/registry.ts. To improve maintainability and avoid future inconsistencies, consider extracting this logic into a shared helper function. This pattern of duplication also exists for other createOpenAICompatible providers like ZAI.
| { value: 'MiniMax-M2.5', label: 'MiniMax M2.5', provider: 'minimax', description: 'Peak performance', capabilities: { thinking: false, tools: true, vision: false, contextWindow: 204800 } }, | ||
| { value: 'MiniMax-M2.5-highspeed', label: 'MiniMax M2.5 High Speed', provider: 'minimax', description: 'Fast and agile', capabilities: { thinking: false, tools: true, vision: false, contextWindow: 204800 } }, |
There was a problem hiding this comment.
To maintain consistency with other model identifiers in the project, which are typically lowercase, the value for these new MiniMax models should be in lowercase. This change should be propagated to all usages of these model IDs within this file.
| { value: 'MiniMax-M2.5', label: 'MiniMax M2.5', provider: 'minimax', description: 'Peak performance', capabilities: { thinking: false, tools: true, vision: false, contextWindow: 204800 } }, | |
| { value: 'MiniMax-M2.5-highspeed', label: 'MiniMax M2.5 High Speed', provider: 'minimax', description: 'Fast and agile', capabilities: { thinking: false, tools: true, vision: false, contextWindow: 204800 } }, | |
| { value: 'minimax-m2.5', label: 'MiniMax M2.5', provider: 'minimax', description: 'Peak performance', capabilities: { thinking: false, tools: true, vision: false, contextWindow: 204800 } }, | |
| { value: 'minimax-m2.5-highspeed', label: 'MiniMax M2.5 High Speed', provider: 'minimax', description: 'Fast and agile', capabilities: { thinking: false, tools: true, vision: false, contextWindow: 204800 } }, |
| auto: { primaryModel: 'MiniMax-M2.5', primaryThinking: 'low', phaseModels: { spec: 'MiniMax-M2.5', planning: 'MiniMax-M2.5', coding: 'MiniMax-M2.5', qa: 'MiniMax-M2.5' }, phaseThinking: { spec: 'low', planning: 'low', coding: 'low', qa: 'low' } }, | ||
| balanced: { primaryModel: 'MiniMax-M2.5', primaryThinking: 'low', phaseModels: { spec: 'MiniMax-M2.5', planning: 'MiniMax-M2.5', coding: 'MiniMax-M2.5', qa: 'MiniMax-M2.5' }, phaseThinking: { spec: 'low', planning: 'low', coding: 'low', qa: 'low' } }, |
There was a problem hiding this comment.
The auto and balanced presets are identical. While this pattern exists for the mistral provider, it introduces code duplication. To improve maintainability, you could define this preset configuration in a constant and reference it for both auto and balanced.
| auto: { primaryModel: 'MiniMax-M2.5', primaryThinking: 'low', phaseModels: { spec: 'MiniMax-M2.5', planning: 'MiniMax-M2.5', coding: 'MiniMax-M2.5', qa: 'MiniMax-M2.5' }, phaseThinking: { spec: 'low', planning: 'low', coding: 'low', qa: 'low' } }, | ||
| balanced: { primaryModel: 'MiniMax-M2.5', primaryThinking: 'low', phaseModels: { spec: 'MiniMax-M2.5', planning: 'MiniMax-M2.5', coding: 'MiniMax-M2.5', qa: 'MiniMax-M2.5' }, phaseThinking: { spec: 'low', planning: 'low', coding: 'low', qa: 'low' } }, | ||
| quick: { primaryModel: 'MiniMax-M2.5-highspeed', primaryThinking: 'low', phaseModels: { spec: 'MiniMax-M2.5-highspeed', planning: 'MiniMax-M2.5-highspeed', coding: 'MiniMax-M2.5-highspeed', qa: 'MiniMax-M2.5-highspeed' }, phaseThinking: { spec: 'low', planning: 'low', coding: 'low', qa: 'low' } }, |
There was a problem hiding this comment.
To align with the suggested change to lowercase model identifiers, the primaryModel and phaseModels in these presets should be updated.
| auto: { primaryModel: 'MiniMax-M2.5', primaryThinking: 'low', phaseModels: { spec: 'MiniMax-M2.5', planning: 'MiniMax-M2.5', coding: 'MiniMax-M2.5', qa: 'MiniMax-M2.5' }, phaseThinking: { spec: 'low', planning: 'low', coding: 'low', qa: 'low' } }, | |
| balanced: { primaryModel: 'MiniMax-M2.5', primaryThinking: 'low', phaseModels: { spec: 'MiniMax-M2.5', planning: 'MiniMax-M2.5', coding: 'MiniMax-M2.5', qa: 'MiniMax-M2.5' }, phaseThinking: { spec: 'low', planning: 'low', coding: 'low', qa: 'low' } }, | |
| quick: { primaryModel: 'MiniMax-M2.5-highspeed', primaryThinking: 'low', phaseModels: { spec: 'MiniMax-M2.5-highspeed', planning: 'MiniMax-M2.5-highspeed', coding: 'MiniMax-M2.5-highspeed', qa: 'MiniMax-M2.5-highspeed' }, phaseThinking: { spec: 'low', planning: 'low', coding: 'low', qa: 'low' } }, | |
| auto: { primaryModel: 'minimax-m2.5', primaryThinking: 'low', phaseModels: { spec: 'minimax-m2.5', planning: 'minimax-m2.5', coding: 'minimax-m2.5', qa: 'minimax-m2.5' }, phaseThinking: { spec: 'low', planning: 'low', coding: 'low', qa: 'low' } }, | |
| balanced: { primaryModel: 'minimax-m2.5', primaryThinking: 'low', phaseModels: { spec: 'minimax-m2.5', planning: 'minimax-m2.5', coding: 'minimax-m2.5', qa: 'minimax-m2.5' }, phaseThinking: { spec: 'low', planning: 'low', coding: 'low', qa: 'low' } }, | |
| quick: { primaryModel: 'minimax-m2.5-highspeed', primaryThinking: 'low', phaseModels: { spec: 'minimax-m2.5-highspeed', planning: 'minimax-m2.5-highspeed', coding: 'minimax-m2.5-highspeed', qa: 'minimax-m2.5-highspeed' }, phaseThinking: { spec: 'low', planning: 'low', coding: 'low', qa: 'low' } }, |
| minimax: { modelId: 'MiniMax-M2.5', reasoning: { type: 'none' } }, | ||
| }, | ||
| 'MiniMax-M2.5': { | ||
| minimax: { modelId: 'MiniMax-M2.5', reasoning: { type: 'none' } }, | ||
| anthropic: { modelId: 'claude-sonnet-4-6', reasoning: { type: 'thinking_tokens', level: 'medium' } }, | ||
| openai: { modelId: 'gpt-5.2', reasoning: { type: 'reasoning_effort', level: 'medium' } }, | ||
| }, | ||
| 'MiniMax-M2.5-highspeed': { | ||
| minimax: { modelId: 'MiniMax-M2.5-highspeed', reasoning: { type: 'none' } }, | ||
| anthropic: { modelId: 'claude-haiku-4-5-20251001', reasoning: { type: 'none' } }, | ||
| openai: { modelId: 'gpt-5.1-codex-mini', reasoning: { type: 'reasoning_effort', level: 'low' } }, | ||
| }, |
There was a problem hiding this comment.
To align with the suggested change to lowercase model identifiers, the keys and modelId values in this equivalence mapping should be updated to use lowercase.
| minimax: { modelId: 'MiniMax-M2.5', reasoning: { type: 'none' } }, | |
| }, | |
| 'MiniMax-M2.5': { | |
| minimax: { modelId: 'MiniMax-M2.5', reasoning: { type: 'none' } }, | |
| anthropic: { modelId: 'claude-sonnet-4-6', reasoning: { type: 'thinking_tokens', level: 'medium' } }, | |
| openai: { modelId: 'gpt-5.2', reasoning: { type: 'reasoning_effort', level: 'medium' } }, | |
| }, | |
| 'MiniMax-M2.5-highspeed': { | |
| minimax: { modelId: 'MiniMax-M2.5-highspeed', reasoning: { type: 'none' } }, | |
| anthropic: { modelId: 'claude-haiku-4-5-20251001', reasoning: { type: 'none' } }, | |
| openai: { modelId: 'gpt-5.1-codex-mini', reasoning: { type: 'reasoning_effort', level: 'low' } }, | |
| }, | |
| minimax: { modelId: 'minimax-m2.5', reasoning: { type: 'none' } }, | |
| }, | |
| 'minimax-m2.5': { | |
| minimax: { modelId: 'minimax-m2.5', reasoning: { type: 'none' } }, | |
| anthropic: { modelId: 'claude-sonnet-4-6', reasoning: { type: 'thinking_tokens', level: 'medium' } }, | |
| openai: { modelId: 'gpt-5.2', reasoning: { type: 'reasoning_effort', level: 'medium' } }, | |
| }, | |
| 'minimax-m2.5-highspeed': { | |
| minimax: { modelId: 'minimax-m2.5-highspeed', reasoning: { type: 'none' } }, | |
| anthropic: { modelId: 'claude-haiku-4-5-20251001', reasoning: { type: 'none' } }, | |
| openai: { modelId: 'gpt-5.1-codex-mini', reasoning: { type: 'reasoning_effort', level: 'low' } }, | |
| }, |
| groq: { modelId: 'llama-3.3-70b-versatile', reasoning: { type: 'none' } }, | ||
| xai: { modelId: 'grok-3-mini', reasoning: { type: 'reasoning_effort', level: 'medium' } }, | ||
| zai: { modelId: 'glm-4.7', reasoning: { type: 'none' } }, | ||
| minimax: { modelId: 'MiniMax-M2.5', reasoning: { type: 'none' } }, |
There was a problem hiding this comment.
To align with the suggested change to lowercase model identifiers, this model ID should be updated to use lowercase.
| minimax: { modelId: 'MiniMax-M2.5', reasoning: { type: 'none' } }, | |
| minimax: { modelId: 'minimax-m2.5', reasoning: { type: 'none' } }, |
| mistral: { modelId: 'mistral-small-latest', reasoning: { type: 'none' } }, | ||
| groq: { modelId: 'llama-3.3-70b-versatile', reasoning: { type: 'none' } }, | ||
| zai: { modelId: 'glm-4.5-flash', reasoning: { type: 'none' } }, | ||
| minimax: { modelId: 'MiniMax-M2.5-highspeed', reasoning: { type: 'none' } }, |
There was a problem hiding this comment.
To align with the suggested change to lowercase model identifiers, this model ID should be updated to use lowercase.
| minimax: { modelId: 'MiniMax-M2.5-highspeed', reasoning: { type: 'none' } }, | |
| minimax: { modelId: 'minimax-m2.5-highspeed', reasoning: { type: 'none' } }, |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/desktop/src/main/ai/providers/__tests__/factory.test.ts`:
- Around line 166-168: The test only verifies
detectProviderFromModel('MiniMax-M2.5') yields 'minimax' but doesn't validate
the provider factory output; update the test to create the provider instance
using the same factory used elsewhere in this test file (i.e., call the module's
provider factory with the provider id returned by
detectProviderFromModel('MiniMax-M2.5')) and assert the resulting factory
produces the expected MiniMax-specific properties (e.g., provider.name ===
'minimax' and the default baseURL/value expected for MiniMax); ensure you import
and use the exact factory function from the file under test and add these
assertions so the branch behavior (name and baseURL) is validated despite the
openai-compatible mock.
In `@apps/desktop/src/main/ai/providers/types.ts`:
- Around line 23-24: SupportedProvider was extended with 'MiniMax' but the auth
lookup maps were not updated; add a minimax entry to the PROVIDER_ENV_VARS and
PROVIDER_SETTINGS_KEY records so TypeScript strict checks pass and stored
MiniMax keys resolve. Locate the constants PROVIDER_ENV_VARS and
PROVIDER_SETTINGS_KEY and add the corresponding minimax key/value entries
(matching the pattern used for other providers) and ensure the string keys align
with the new SupportedProvider 'MiniMax' value.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: ba0ee00d-9e6f-4124-bd14-9f809c161952
📒 Files selected for processing (8)
apps/desktop/src/main/ai/config/types.tsapps/desktop/src/main/ai/providers/__tests__/factory.test.tsapps/desktop/src/main/ai/providers/factory.tsapps/desktop/src/main/ai/providers/registry.tsapps/desktop/src/main/ai/providers/types.tsapps/desktop/src/shared/constants/models.tsapps/desktop/src/shared/constants/providers.tsapps/desktop/src/shared/types/provider-account.ts
| it('detects MiniMax from MiniMax- prefix', () => { | ||
| expect(detectProviderFromModel('MiniMax-M2.5')).toBe('minimax'); | ||
| }); |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Add a MiniMax factory assertion here, not just prefix detection.
This only proves MODEL_PROVIDER_MAP contains MiniMax-. Because the @ai-sdk/openai-compatible mock returns the same stub for Z.AI, MiniMax, and Ollama, the suite would still pass if the MiniMax branch used the wrong name or default baseURL.
🧪 Suggested test hardening
+import { createOpenAICompatible } from '@ai-sdk/openai-compatible';
import { createAnthropic } from '@ai-sdk/anthropic';
import { createProvider, detectProviderFromModel, createProviderFromModelId } from '../factory';
import { SupportedProvider } from '../types'; it('detects MiniMax from MiniMax- prefix', () => {
expect(detectProviderFromModel('MiniMax-M2.5')).toBe('minimax');
});
+
+ it('wires MiniMax through the OpenAI-compatible adapter', () => {
+ createProvider({
+ config: { provider: SupportedProvider.MiniMax, apiKey: 'test-key' },
+ modelId: 'MiniMax-M2.5',
+ });
+
+ expect(createOpenAICompatible).toHaveBeenCalledWith(
+ expect.objectContaining({
+ name: 'minimax',
+ apiKey: 'test-key',
+ baseURL: 'https://api.minimax.io/v1',
+ }),
+ );
+ });As per coding guidelines, apps/desktop/**/*.test.{ts,tsx}: Ensure tests are comprehensive and follow Vitest conventions. Check for proper mocking and test isolation.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/desktop/src/main/ai/providers/__tests__/factory.test.ts` around lines
166 - 168, The test only verifies detectProviderFromModel('MiniMax-M2.5') yields
'minimax' but doesn't validate the provider factory output; update the test to
create the provider instance using the same factory used elsewhere in this test
file (i.e., call the module's provider factory with the provider id returned by
detectProviderFromModel('MiniMax-M2.5')) and assert the resulting factory
produces the expected MiniMax-specific properties (e.g., provider.name ===
'minimax' and the default baseURL/value expected for MiniMax); ensure you import
and use the exact factory function from the file under test and add these
assertions so the branch behavior (name and baseURL) is validated despite the
openai-compatible mock.
Address PR review feedback:
- Change all MiniMax model IDs from PascalCase to lowercase
('MiniMax-M2.5' → 'minimax-m2.5', 'MiniMax-M2.5-highspeed' →
'minimax-m2.5-highspeed') for consistency with other providers
- Update MODEL_PROVIDER_MAP prefix from 'MiniMax-' to 'minimax-'
- Add missing 'minimax' entries to PROVIDER_ENV_VARS and
PROVIDER_SETTINGS_KEY in auth/types.ts (critical for API key
resolution)
- Update all preset definitions and equivalence mappings
- Update factory detection test to use lowercase model name
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
PR Bot seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
|
Thanks for the thorough review! I've pushed a fix commit (c4057c0) addressing the feedback: Changes madeLowercase model IDs (gemini-code-assist items 1, 2, 4, 6):
Auth entries (coderabbitai critical item 8):
Acknowledged but not changedFactory duplication (gemini-code-assist item 3): The MiniMax provider creation in Identical auto/balanced presets (gemini-code-assist item 5): The Factory test assertion (coderabbitai nitpick item 7): The current prefix-detection test pattern is consistent with all other provider tests in the same describe block. A more thorough factory integration test could be a good follow-up but is out of scope for this PR. |
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
| export type BuiltinProvider = | ||
| | 'anthropic' | 'openai' | 'google' | 'amazon-bedrock' | 'azure' | ||
| | 'mistral' | 'groq' | 'xai' | 'openrouter' | 'zai' | ||
| | 'ollama' | 'openai-compatible'; | ||
| | 'minimax' | 'ollama' | 'openai-compatible'; | ||
|
|
||
| export type BillingModel = 'subscription' | 'pay-per-use'; | ||
|
|
There was a problem hiding this comment.
Bug: The BUILTIN_TO_SUPPORTED map in resolver.ts is missing an entry for 'minimax', causing MiniMax accounts to be silently skipped during queue-based provider routing.
Severity: CRITICAL
Suggested Fix
Add the missing 'minimax': 'minimax' entry to the BUILTIN_TO_SUPPORTED map located in apps/desktop/src/main/ai/auth/resolver.ts to ensure the provider is correctly resolved during queue-based routing.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: apps/desktop/src/shared/types/provider-account.ts#L7-L13
Potential issue: The new 'minimax' provider is added to the `BuiltinProvider` type, but
the `BUILTIN_TO_SUPPORTED` map in `resolver.ts` was not updated. The
`resolveAuthFromQueue()` function uses this map to route requests. When it encounters a
'minimax' account, the lookup `BUILTIN_TO_SUPPORTED['minimax']` returns `undefined`,
causing the function to silently `continue` and skip the account. This effectively
disables the MiniMax provider for any multi-provider queue-based routing, which is the
primary routing mechanism in the application, rendering the integration non-functional
for its main use case.
Did we get this right? 👍 / 👎 to inform future reviews.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/desktop/src/main/ai/auth/types.ts`:
- Line 100: The minimax -> 'globalMiniMaxApiKey' setting referenced in the
mapping is missing from the settings schema, causing resolveFromProfileApiKey()
(which reads PROVIDER_SETTINGS_KEY) to never find MiniMax keys; add the
corresponding field (globalMiniMaxApiKey) to the AppSettings definition in
apps/desktop/src/shared/types/settings.ts and/or type the settings map as keyof
AppSettings so the compiler prevents this drift, ensuring
resolveFromProfileApiKey() can read MiniMax keys via PROVIDER_SETTINGS_KEY.
In `@apps/desktop/src/shared/constants/models.ts`:
- Around line 425-430: The canonical equivalence for the full MiniMax ID
'minimax-m2.5' is ambiguous: update the 'minimax-m2.5' entry in the models map
so it exhaustively includes equivalent shorthand mappings for all providers
(e.g., add mappings for 'opus' and 'sonnet' like the other full-ID rows) OR
change the reverse lookup behavior in resolveModelEquivalent() to stop
reverse-fallback when a direct full-ID entry exists; specifically modify the
'minimax-m2.5' object in models.ts to include the same provider keys
(anthropic/opus/sonnet/openai/etc.) with their intended modelIds and reasoning,
or alter resolveModelEquivalent() to prefer direct full-ID matches and avoid
selecting the first shorthand by object order.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: b9cb27e4-374a-443f-97a8-1a1e61e2a962
📒 Files selected for processing (4)
apps/desktop/src/main/ai/auth/types.tsapps/desktop/src/main/ai/config/types.tsapps/desktop/src/main/ai/providers/__tests__/factory.test.tsapps/desktop/src/shared/constants/models.ts
- Add missing 'minimax' entry to BUILTIN_TO_SUPPORTED map in resolver.ts, fixing silent skip of MiniMax accounts during queue-based provider routing - Add globalMiniMaxApiKey (and globalZAIApiKey) to AppSettings interface, fixing auth settings lookup for profile-specific API keys - Differentiate model equivalence tiers: 'sonnet' tier now maps to minimax-m2.5-highspeed instead of minimax-m2.5 (which is reserved for 'opus' tier), matching the pattern used by other multi-model providers Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Pushed commit CRITICAL fixes
MAJOR fix
MEDIUM items
|
| minimax: { | ||
| auto: { primaryModel: 'minimax-m2.5', primaryThinking: 'low', phaseModels: { spec: 'minimax-m2.5', planning: 'minimax-m2.5', coding: 'minimax-m2.5', qa: 'minimax-m2.5' }, phaseThinking: { spec: 'low', planning: 'low', coding: 'low', qa: 'low' } }, | ||
| balanced: { primaryModel: 'minimax-m2.5', primaryThinking: 'low', phaseModels: { spec: 'minimax-m2.5', planning: 'minimax-m2.5', coding: 'minimax-m2.5', qa: 'minimax-m2.5' }, phaseThinking: { spec: 'low', planning: 'low', coding: 'low', qa: 'low' } }, | ||
| quick: { primaryModel: 'minimax-m2.5-highspeed', primaryThinking: 'low', phaseModels: { spec: 'minimax-m2.5-highspeed', planning: 'minimax-m2.5-highspeed', coding: 'minimax-m2.5-highspeed', qa: 'minimax-m2.5-highspeed' }, phaseThinking: { spec: 'low', planning: 'low', coding: 'low', qa: 'low' } }, | ||
| }, |
There was a problem hiding this comment.
Bug: The MiniMax provider is missing the complex preset, causing the 'Complex Tasks' profile to silently fall back to the 'Auto' profile's settings.
Severity: MEDIUM
Suggested Fix
Add a complex preset to the minimax provider object within PROVIDER_PRESET_DEFINITIONS. This new preset should likely use the same model as the auto preset, such as minimax-m2.5, to align with the pattern used by other providers with limited model variety.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: apps/desktop/src/shared/constants/models.ts#L322-L326
Potential issue: The MiniMax provider definition in `PROVIDER_PRESET_DEFINITIONS` is
missing a `complex` preset. When a user selects the 'Complex Tasks' profile, which has
an ID of 'complex', the `getProviderPresetOrFallback` function fails to find an exact
match for `minimax.complex`. The function then silently falls back to the `minimax.auto`
preset. This results in the 'Complex Tasks' profile behaving identically to the 'Auto'
profile for the MiniMax provider, ignoring the user's selection without any warning or
indication.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/desktop/src/shared/types/settings.ts`:
- Around line 287-288: DEFAULT_APP_SETTINGS is missing initializers for the
newly added optional fields globalZAIApiKey and globalMiniMaxApiKey; update the
DEFAULT_APP_SETTINGS object (same area that currently sets globalOpenAIApiKey)
to include explicit initializers for these two keys (set them to undefined with
the same typed form used elsewhere, e.g., as string | undefined) so they are
consistently present during resets and first-run initialization.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 4fc29a66-d743-4299-8dcb-070280d8a267
📒 Files selected for processing (3)
apps/desktop/src/main/ai/auth/resolver.tsapps/desktop/src/shared/constants/models.tsapps/desktop/src/shared/types/settings.ts
| globalZAIApiKey?: string; | ||
| globalMiniMaxApiKey?: string; |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Add new API key fields to DEFAULT_APP_SETTINGS for consistency.
The new globalZAIApiKey and globalMiniMaxApiKey fields are correctly added as optional. However, DEFAULT_APP_SETTINGS in apps/desktop/src/shared/constants/config.ts (around line 51) initializes globalOpenAIApiKey but not these new keys. For consistency with other global API key fields, add explicit undefined initializers:
// In apps/desktop/src/shared/constants/config.ts DEFAULT_APP_SETTINGS:
globalZAIApiKey: undefined as string | undefined,
globalMiniMaxApiKey: undefined as string | undefined,This ensures consistent initialization across settings resets and first-launch scenarios.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/desktop/src/shared/types/settings.ts` around lines 287 - 288,
DEFAULT_APP_SETTINGS is missing initializers for the newly added optional fields
globalZAIApiKey and globalMiniMaxApiKey; update the DEFAULT_APP_SETTINGS object
(same area that currently sets globalOpenAIApiKey) to include explicit
initializers for these two keys (set them to undefined with the same typed form
used elsewhere, e.g., as string | undefined) so they are consistently present
during resets and first-run initialization.
- Add MiniMax-M2.7-highspeed to model catalog for low-latency scenarios - Upgrade quick preset from M2.5-highspeed to M2.7-highspeed - Add M2.7-highspeed model equivalence entry - Update haiku tier to map to M2.7-highspeed - Update provider detection test for M2.7-highspeed
octo-patch
changed the title
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
apps/desktop/src/main/ai/providers/__tests__/factory.test.ts (1)
166-170: 🧹 Nitpick | 🔵 TrivialHarden MiniMax coverage with a factory-path assertion.
Line 166-Line 170 verifies prefix detection only. With the shared
@ai-sdk/openai-compatiblemock, the suite can still pass even if MiniMax is wired with an incorrectnameor defaultbaseURL.🧪 Suggested test hardening
+import { createOpenAICompatible } from '@ai-sdk/openai-compatible'; import { createAnthropic } from '@ai-sdk/anthropic'; import { createProvider, detectProviderFromModel, createProviderFromModelId } from '../factory'; import { SupportedProvider } from '../types';it('detects MiniMax from minimax- prefix', () => { expect(detectProviderFromModel('minimax-m2.7')).toBe('minimax'); expect(detectProviderFromModel('minimax-m2.7-highspeed')).toBe('minimax'); expect(detectProviderFromModel('minimax-m2.5')).toBe('minimax'); }); + + it('wires MiniMax through the OpenAI-compatible adapter', () => { + createProvider({ + config: { provider: SupportedProvider.MiniMax, apiKey: 'test-key' }, + modelId: 'minimax-m2.7', + }); + + expect(createOpenAICompatible).toHaveBeenCalledWith( + expect.objectContaining({ + name: 'minimax', + apiKey: 'test-key', + baseURL: 'https://api.minimax.io/v1', + }), + ); + });As per coding guidelines,
apps/desktop/**/*.test.{ts,tsx}: Ensure tests are comprehensive and follow Vitest conventions.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/desktop/src/main/ai/providers/__tests__/factory.test.ts` around lines 166 - 170, The test only checks prefix detection via detectProviderFromModel('minimax-...') but must also assert the actual provider factory wiring; update the test to call the provider factory resolver (e.g., createProviderFromModel or getProviderByModel) for 'minimax-m2.7' and assert the returned provider metadata contains the expected factory/name/baseURL values for MiniMax (for example provider.name === 'minimax' and provider.baseURL matches the MiniMax factory URL or provider.factoryPath matches the MiniMax factory module) so the test fails if MiniMax is wired with the wrong implementation.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/desktop/src/shared/constants/providers.ts`:
- Around line 65-69: Update the provider entry with id 'minimax' by editing its
description field to include the missing "minimax-m2.5-highspeed" model name so
the text lists "MiniMax M2.7, M2.7-highspeed, minimax-m2.5-highspeed and M2.5"
(or otherwise include that model) to match the model catalog; locate the object
with id: 'minimax' and adjust the description string accordingly.
---
Duplicate comments:
In `@apps/desktop/src/main/ai/providers/__tests__/factory.test.ts`:
- Around line 166-170: The test only checks prefix detection via
detectProviderFromModel('minimax-...') but must also assert the actual provider
factory wiring; update the test to call the provider factory resolver (e.g.,
createProviderFromModel or getProviderByModel) for 'minimax-m2.7' and assert the
returned provider metadata contains the expected factory/name/baseURL values for
MiniMax (for example provider.name === 'minimax' and provider.baseURL matches
the MiniMax factory URL or provider.factoryPath matches the MiniMax factory
module) so the test fails if MiniMax is wired with the wrong implementation.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 67b698a7-9d5c-4a88-903c-20851ea39a0e
📒 Files selected for processing (3)
apps/desktop/src/main/ai/providers/__tests__/factory.test.tsapps/desktop/src/shared/constants/models.tsapps/desktop/src/shared/constants/providers.ts
| id: 'minimax', name: 'MiniMax', description: 'MiniMax M2.7, M2.7-highspeed and M2.5 models', | ||
| category: 'popular', | ||
| authMethods: ['api-key'], envVars: ['MINIMAX_API_KEY'], | ||
| configFields: ['baseUrl'], website: 'https://platform.minimax.io', | ||
| }, |
There was a problem hiding this comment.
Provider description omits minimax-m2.5-highspeed.
Line 65 is missing one currently supported MiniMax model, which makes the UI description inconsistent with the model catalog.
✏️ Suggested text fix
- id: 'minimax', name: 'MiniMax', description: 'MiniMax M2.7, M2.7-highspeed and M2.5 models',
+ id: 'minimax', name: 'MiniMax', description: 'MiniMax M2.7, M2.7-highspeed, M2.5, and M2.5-highspeed models',📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| id: 'minimax', name: 'MiniMax', description: 'MiniMax M2.7, M2.7-highspeed and M2.5 models', | |
| category: 'popular', | |
| authMethods: ['api-key'], envVars: ['MINIMAX_API_KEY'], | |
| configFields: ['baseUrl'], website: 'https://platform.minimax.io', | |
| }, | |
| id: 'minimax', name: 'MiniMax', description: 'MiniMax M2.7, M2.7-highspeed, M2.5, and M2.5-highspeed models', | |
| category: 'popular', | |
| authMethods: ['api-key'], envVars: ['MINIMAX_API_KEY'], | |
| configFields: ['baseUrl'], website: 'https://platform.minimax.io', | |
| }, |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/desktop/src/shared/constants/providers.ts` around lines 65 - 69, Update
the provider entry with id 'minimax' by editing its description field to include
the missing "minimax-m2.5-highspeed" model name so the text lists "MiniMax M2.7,
M2.7-highspeed, minimax-m2.5-highspeed and M2.5" (or otherwise include that
model) to match the model catalog; locate the object with id: 'minimax' and
adjust the description string accordingly.
- Add MiniMax-M3 to model list and set as default (512K context, 128K output, image input support) - Keep MiniMax-M2.7 and MiniMax-M2.7-highspeed as alternatives - Remove older models (M2.5/M2.5-highspeed) - Update detectProviderFromModel test to assert M3 detection - Update provider preset (auto/balanced) and DEFAULT_MODEL_EQUIVALENCES to point at M3
octo-patch
changed the title
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/desktop/src/shared/constants/models.ts (1)
433-437:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winUpdate
minimax-m2.7equivalence mappings if sonnet tier is changed.If the
sonnetshorthand is changed to map tominimax-m2.7(per the previous comment), this equivalence block should be updated to map back to sonnet-tier models rather than opus-tier models for symmetry.Current:
minimax-m2.7→claude-opus-4-6(opus tier)
Expected (if sonnet mapping changes):minimax-m2.7→claude-sonnet-4-6(sonnet tier)This ensures bi-directional equivalence consistency:
sonnet→minimax-m2.7→sonnet.🔧 Conditional fix (depends on sonnet mapping change)
'minimax-m2.7': { minimax: { modelId: 'minimax-m2.7', reasoning: { type: 'none' } }, - anthropic: { modelId: 'claude-opus-4-6', reasoning: { type: 'adaptive_effort', level: 'high' } }, - openai: { modelId: 'gpt-5.3-codex', reasoning: { type: 'reasoning_effort', level: 'high' } }, + anthropic: { modelId: 'claude-sonnet-4-6', reasoning: { type: 'thinking_tokens', level: 'medium' } }, + openai: { modelId: 'gpt-5.2-codex', reasoning: { type: 'reasoning_effort', level: 'medium' } }, },🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/desktop/src/shared/constants/models.ts` around lines 433 - 437, Update the equivalence mapping for the 'minimax-m2.7' entry so its Anthrop ic mapping uses the sonnet-tier Claude model instead of the opus tier: change the anthropic.modelId value currently set to 'claude-opus-4-6' to 'claude-sonnet-4-6' in the 'minimax-m2.7' object to restore bidirectional symmetry with the sonnet shorthand mapping (look for the 'minimax-m2.7' key and the nested anthropic.modelId).
♻️ Duplicate comments (1)
apps/desktop/src/main/ai/providers/__tests__/factory.test.ts (1)
166-170: 🧹 Nitpick | 🔵 Trivial | ⚡ Quick winExtend test to verify factory configuration, not just prefix detection.
The test validates that
detectProviderFromModelresolvesminimax-*prefixes correctly but doesn't verify thatcreateProviderinstantiates the MiniMax provider with correct OpenAI-compatible adapter configuration (name: 'minimax', defaultbaseURL). If the factory branch is misconfigured, this test won't catch it.As per coding guidelines: "Ensure tests are comprehensive and follow Vitest conventions."
🧪 Recommended test addition
+import { createOpenAICompatible } from '`@ai-sdk/openai-compatible`'; + import { createAnthropic } from '`@ai-sdk/anthropic`'; import { createProvider, detectProviderFromModel, createProviderFromModelId } from '../factory'; import { SupportedProvider } from '../types';it('detects MiniMax from minimax- prefix', () => { expect(detectProviderFromModel('minimax-m3')).toBe('minimax'); expect(detectProviderFromModel('minimax-m2.7')).toBe('minimax'); expect(detectProviderFromModel('minimax-m2.7-highspeed')).toBe('minimax'); }); + + it('creates MiniMax provider via OpenAI-compatible adapter', () => { + createProvider({ + config: { provider: SupportedProvider.MiniMax, apiKey: 'test-minimax-key' }, + modelId: 'minimax-m3', + }); + + expect(createOpenAICompatible).toHaveBeenCalledWith( + expect.objectContaining({ + name: 'minimax', + apiKey: 'test-minimax-key', + baseURL: expect.stringContaining('minimax'), + }), + ); + }); });🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/desktop/src/main/ai/providers/__tests__/factory.test.ts` around lines 166 - 170, Update the test to not only assert detectProviderFromModel('minimax-*') returns 'minimax' but also call createProvider with a minimax model string (e.g., createProvider('minimax-m3')) and assert the returned provider uses the OpenAI-compatible adapter configuration: check provider.adapter.name === 'minimax' and that provider.adapter.baseURL is present and equals the expected default base URL (or at least is the default non-empty URL used by the factory); use Vitest expect assertions and proper async handling if createProvider is async.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/desktop/src/shared/constants/models.ts`:
- Around line 323-327: The minimax presets lack a 'complex' entry causing
inconsistency; add a 'complex' preset to the minimax object alongside auto,
balanced, and quick using the same shape (primaryModel, primaryThinking,
phaseModels, phaseThinking) and pick an appropriate model (e.g., 'minimax-m3' or
a higher-capability variant) and thinking level (e.g., 'high') so the presets
mirror other providers and work smoothly with getProviderPresetOrFallback;
update the minimax object where auto/balanced/quick are defined to include this
new 'complex' key.
- Line 471: Update the mapping for the "sonnet" (balanced) tier in
apps/desktop/src/shared/constants/models.ts so it resolves to minimax-m2.7
instead of minimax-m3: find the entry that currently maps sonnet → minimax-m3
(referencing the modelId 'minimax-m3') and change its modelId to 'minimax-m2.7'
to restore correct tiering (keep opus → minimax-m3 and haiku →
minimax-m2.7-highspeed as-is).
---
Outside diff comments:
In `@apps/desktop/src/shared/constants/models.ts`:
- Around line 433-437: Update the equivalence mapping for the 'minimax-m2.7'
entry so its Anthrop ic mapping uses the sonnet-tier Claude model instead of the
opus tier: change the anthropic.modelId value currently set to 'claude-opus-4-6'
to 'claude-sonnet-4-6' in the 'minimax-m2.7' object to restore bidirectional
symmetry with the sonnet shorthand mapping (look for the 'minimax-m2.7' key and
the nested anthropic.modelId).
---
Duplicate comments:
In `@apps/desktop/src/main/ai/providers/__tests__/factory.test.ts`:
- Around line 166-170: Update the test to not only assert
detectProviderFromModel('minimax-*') returns 'minimax' but also call
createProvider with a minimax model string (e.g., createProvider('minimax-m3'))
and assert the returned provider uses the OpenAI-compatible adapter
configuration: check provider.adapter.name === 'minimax' and that
provider.adapter.baseURL is present and equals the expected default base URL (or
at least is the default non-empty URL used by the factory); use Vitest expect
assertions and proper async handling if createProvider is async.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: dbb892cd-ee25-4498-a25e-d4179ae237ee
📒 Files selected for processing (3)
apps/desktop/src/main/ai/providers/__tests__/factory.test.tsapps/desktop/src/shared/constants/models.tsapps/desktop/src/shared/constants/providers.ts
- Add `complex` preset entry to the minimax provider so the catalog is consistent with anthropic / openai / google / xai / zai. - Map the `sonnet` (balanced) tier to `minimax-m2.7` rather than `minimax-m3` so opus/sonnet/haiku resolve to flagship / previous-gen / fast, matching the minimax-m3 equivalence block (which only maps back to anthropic `opus`).
| 'minimax-m2.7': { | ||
| minimax: { modelId: 'minimax-m2.7', reasoning: { type: 'none' } }, | ||
| anthropic: { modelId: 'claude-opus-4-6', reasoning: { type: 'adaptive_effort', level: 'high' } }, | ||
| openai: { modelId: 'gpt-5.3-codex', reasoning: { type: 'reasoning_effort', level: 'high' } }, | ||
| }, |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
There was a problem hiding this comment.
Good catch — fixed in 4d3e4261d0d63da3ee1e9b2a01ce4c81 (the new commit). minimax-m2.7 is the sonnet-tier (Balanced) model, so I switched its anthropic/openai equivalences from claude-opus-4-6/gpt-5.3-codex (opus-tier) to claude-sonnet-4-6/gpt-5.2-codex (sonnet-tier) — matching what the 'sonnet' row already maps to. minimax-m2.7-highspeed already had haiku-tier fallbacks, so it's left alone.
Sentry caught that DEFAULT_MODEL_EQUIVALENCES['minimax-m2.7'] mapped to opus/high-reasoning fallbacks even though m2.7 is defined as the sonnet-tier (Balanced) model elsewhere in this file. That caused unexpected cost/behavior during provider failover when a user picked m2.7. Switch the anthropic/openai entries to match what 'sonnet' maps to: - anthropic: claude-sonnet-4-6, thinking_tokens medium - openai: gpt-5.2-codex, reasoning_effort medium The 'minimax' self-entry and m2.7-highspeed (haiku-tier) already line up correctly, so no other rows change. Co-Authored-By: Octopus <liyuan851277048@icloud.com>
| minimax: { | ||
| auto: { primaryModel: 'minimax-m3', primaryThinking: 'low', phaseModels: { spec: 'minimax-m3', planning: 'minimax-m3', coding: 'minimax-m3', qa: 'minimax-m3' }, phaseThinking: { spec: 'low', planning: 'low', coding: 'low', qa: 'low' } }, | ||
| complex: { primaryModel: 'minimax-m3', primaryThinking: 'low', phaseModels: { spec: 'minimax-m3', planning: 'minimax-m3', coding: 'minimax-m3', qa: 'minimax-m3' }, phaseThinking: { spec: 'low', planning: 'low', coding: 'low', qa: 'low' } }, | ||
| balanced: { primaryModel: 'minimax-m3', primaryThinking: 'low', phaseModels: { spec: 'minimax-m3', planning: 'minimax-m3', coding: 'minimax-m3', qa: 'minimax-m3' }, phaseThinking: { spec: 'low', planning: 'low', coding: 'low', qa: 'low' } }, |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
The minimax balanced preset was using minimax-m3 (flagship), making it identical to auto and complex. This breaks the consistent tiering pattern used by every other provider in PROVIDER_PRESET_DEFINITIONS, where balanced selects a mid-tier model: - anthropic balanced -> sonnet (vs opus for auto/complex) - openai balanced -> gpt-5.2-codex (vs gpt-5.3-codex) - google balanced -> gemini-2.5-flash (vs pro) - xai balanced -> grok-3-mini (vs grok-4) - zai balanced -> glm-4.7 (vs glm-5) Switching to minimax-m2.7 aligns with that pattern and matches the existing 'sonnet' equivalence row, which already maps the sonnet shorthand to minimax-m2.7 for cross-provider failover. Auto and complex continue to use minimax-m3 (flagship), and quick keeps minimax-m2.7-highspeed. Co-Authored-By: Octopus <liyuan851277048@icloud.com>
|
Good catch — fixed in 0e194a4. The
This also matches the existing |
|
👋 Thanks so much for your interest in contributing to Aperant! Pull requests are currently paused. We're rebuilding the entire app from the ground up for Aperant 3.0 (including new cloud features). Most of that work is happening in a separate development repo right now and will be merged here once it's ready — so although this repo looks quiet, the project is very much alive. 🚀 Because the current codebase is being fully replaced, we're closing existing PRs so contributors aren't left waiting on changes that unfortunately can't be merged. This is not a reflection on your work, and we're sorry for any wasted effort. 🙏 We'd genuinely love your help shaping 3.0 instead:
Contributions will reopen once the 3.0 foundation lands. Thank you for understanding! |
Summary
quickpreset to M2.7-highspeed;autoandbalanceduse M3Changes
SupportedProviderenum, factory, registry, auth resolver, and auth/config mapsALL_AVAILABLE_MODELS: M3 (vision-capable, 512K window), M2.7 and M2.7-highspeedDEFAULT_MODEL_EQUIVALENCESentries for M3, M2.7 and M2.7-highspeed (drop M2.5/M2.5-highspeed)detectProviderFromModeltest to assert M3 detectionPROVIDER_REGISTRYentry for settings UI describing the M3 / M2.7 / M2.7-highspeed lineupWhy
MiniMax-M3 is the latest flagship model with:
M2.7 / M2.7-highspeed are retained for users who still want the previous generation. Older M2.5 / M2.5-highspeed entries are removed.
Testing
detectProviderFromModelcovers M3, M2.7, M2.7-highspeed)Summary by CodeRabbit
New Features
Tests