feat: add MiniMax provider support

[octo-patch]

Summary

• Add MiniMax as a new AI provider using the OpenAI-compatible API
• Add MiniMax-M2.7 and MiniMax-M2.7-highspeed models to the provider's model list
• Register the new provider in AiProviderEnum and PROVIDER_MAP
• Add unit tests for the new provider

Implementation Details

MiniMax exposes an OpenAI-compatible chat API at https://api.minimax.io/v1. This PR implements a dedicated MiniMax provider using @ai-sdk/openai-compatible (already a project dependency), following the same pattern as other providers in this codebase.

Users can configure MiniMax by setting:

• Provider: MiniMax
• API Key: MINIMAX_API_KEY
• Model: MiniMax-M2.7 (flagship) or MiniMax-M2.7-highspeed (faster variant)

API Reference

• Chat (OpenAI Compatible): https://platform.minimax.io/docs/api-reference/text-openai-api

Test plan

• Unit tests updated and passing (packages/openops/test/ai/providers.test.ts)
• Integration test verified — real API call to api.minimax.io returns valid response
• Provider registered in AiProviderEnum and PROVIDER_MAP
• Models list includes MiniMax-M2.7 and MiniMax-M2.7-highspeed

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[alexandrudanpop]

Thanks for the contribution, @octo-patch !

I can see this issue when testing it in the main chat, you can try a prompt like:
What are my available tables?

Looks related to generating JSON output from our query router. Could you please check?

 AI SDK Warning (minimax.chat / MiniMax-M2.7): The feature "responseFormat" is not supported. JSON response format schema is only supported with structuredOutputs
[API]
[API] [07:43:23 UTC] ERROR: Failed to generate chat name
[API]     errorStack: "AI_NoObjectGeneratedError: No object generated: could not parse the response.\n    at parseAndValidateObjectResult (/openops/node_modules/ai/src/generate-object/parse-and-validate-object-result.ts:33:11)\n    at processTicksAndRejections (node:internal/process/task_queues:95:5)\n    at parseAndValidateObjectResultWithRepair (/openops/node_modules/ai/src/generate-object/parse-and-validate-object-result.ts:88:12)\n    at fn (/openops/node_modules/ai/src/generate-object/generate-object.ts:432:24)\n    at /openops/node_modules/ai/src/telemetry/record-span.ts:32:24\n    at generateObject (/openops/node_modules/ai/src/generate-object/generate-object.ts:264:12)"
[API]     errorMessage: "No object generated: could not parse the response."
[API]     errorName: "AI_NoObjectGeneratedError"
[API]     errorContext: "{\"cause\":{\"name\":\"AI_JSONParseError\",\"cause\":{},\"text\":\"<think>\nThe user is asking me to generate a chat name based on the conversation. Let me analyze what the conversation was about:\n\n1. User said \\"hi\\" - just a greeting\n2. User asked \\"what are my available tables?\\" - asking about OpenOps tables\n3. I responded asking for clarification\n4. User clarified \\"openops tables\\"\n5. I explained I don't have direct access to query OpenOps internal tables\n6. User asked \\"what tools can you access\\"\n7. I had an error (billing related)\n8. Now user wants me to generate a chat name\n\nThe main topic seems to be about:\n- Exploring OpenOps capabilities\n- Understanding available tables and tools in OpenOps\n- User trying to learn what they can do/access in OpenOps\n\nA good name should be specific and capture the essence of this conversation. Something like:\n- \\"OpenOps capabilities inquiry\\"\n- \\"OpenOps tables and tools\\"\n- \\"Exploring OpenOps access\\"\n- \\"OpenOps features question\\"\n- \\"Available OpenOps tools\\"\n\nI think \\"OpenOps features and tables\\" or \\"OpenOps capabilities inquiry\\" would work well. Let me keep it under 5 words.\n\n\\"OpenOps features and tools\\" - 4 words\n\\"OpenOps tables and tools\\" - 4 words\n\\"OpenOps capabilities question\\" - 3 words\n\\"Exploring OpenOps access\\" - 3 words\n\nI think \\"OpenOps tables and tools\\" captures the specific questions asked well.\n</think>\n\n{\n  \\"isGenerated\\": true,\n  \\"name\\": \\"OpenOps tables and tools\\"\n}\"},\"text\":\"<think>\nThe user is asking me to generate a chat name based on the conversation. Let me analyze what the conversation was about:\n\n1. User said \\"hi\\" - just a greeting\n2. User asked \\"what are my available tables?\\" - asking about OpenOps tables\n3. I responded asking for clarification\n4. User clarified \\"openops tables\\"\n5. I explained I don't have direct access to query OpenOps internal tables\n6. User asked \\"what tools can you access\\"\n7. I had an error (billing related)\n8. Now user wants me to generate a chat name\n\n

[github-actions]

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 5 days if no further activity occurs. Please feel free to give a status update by leaving a comment. Thank you for your contributions!

[octo-patch]

Sorry for the delay here, @alexandrudanpop! Sharing what I found and where I think this should land.

Root cause. MiniMax-M2.7 is a thinking model — every reply starts with a <think>...</think> block before the actual content. MiniMax's OpenAI-compatible /v1/chat/completions endpoint also does not honor response_format (per MiniMax-AI/MiniMax-M2.5#4, which still applies to M2.7), so the AI SDK warns "responseFormat" is not supported and falls back to manual JSON parsing — which then trips on the leading <think> block. The chat-name generateObject call you're hitting is exactly that path.

Why I do not want to flip supportsStructuredOutputs: true. That flag tells the SDK "this model returns conformant JSON," but the underlying endpoint will still ignore response_format and still leak <think> content. It would silence the warning without fixing the parse error.

What I think the right fix is, in order of preference:

1. Strip the <think> block before JSON parsing for minimax models. The SDK's transformRequestBody doesn't help here (it's request-side); we'd need to wrap the model with a custom extractReasoningMiddleware (built into ai v6) tagged with <think>, which moves the reasoning out of the text channel so generateObject only sees the JSON tail.
2. For object-generation paths specifically, prefer MiniMax-M2.7-highspeed — it does not emit <think> and produces clean JSON-friendly output.

Approach 1 is the more robust fix and keeps both models usable for both generateText and generateObject. Happy to roll that into this PR (small wrapLanguageModel(... extractReasoningMiddleware({ tagName: 'think' })) in minimax.ts plus a unit test), or split it into a follow-up if you'd rather keep this PR focused on "add provider, ship, iterate." Let me know which you prefer and I'll push within a day.

[alexandrudanpop]

Sorry for the delay here, @alexandrudanpop! Sharing what I found and where I think this should land.

Root cause. MiniMax-M2.7 is a thinking model — every reply starts with a <think>...</think> block before the actual content. MiniMax's OpenAI-compatible /v1/chat/completions endpoint also does not honor response_format (per MiniMax-AI/MiniMax-M2.5#4, which still applies to M2.7), so the AI SDK warns "responseFormat" is not supported and falls back to manual JSON parsing — which then trips on the leading <think> block. The chat-name generateObject call you're hitting is exactly that path.

Why I do not want to flip supportsStructuredOutputs: true. That flag tells the SDK "this model returns conformant JSON," but the underlying endpoint will still ignore response_format and still leak <think> content. It would silence the warning without fixing the parse error.

What I think the right fix is, in order of preference:

1. Strip the <think> block before JSON parsing for minimax models. The SDK's transformRequestBody doesn't help here (it's request-side); we'd need to wrap the model with a custom extractReasoningMiddleware (built into ai v6) tagged with <think>, which moves the reasoning out of the text channel so generateObject only sees the JSON tail.
2. For object-generation paths specifically, prefer MiniMax-M2.7-highspeed — it does not emit <think> and produces clean JSON-friendly output.

Approach 1 is the more robust fix and keeps both models usable for both generateText and generateObject. Happy to roll that into this PR (small wrapLanguageModel(... extractReasoningMiddleware({ tagName: 'think' })) in minimax.ts plus a unit test), or split it into a follow-up if you'd rather keep this PR focused on "add provider, ship, iterate." Let me know which you prefer and I'll push within a day.

The plan sounds ok for me, but we would need to make it in a generic way (both 1 and 2). For point 2 for example currently we don't have a special setting, so the generateObject call happens with the same model. Not sure if it's a good idea to hardcode the secondary model, as it will get stale as we have new model releases. So I would propose to have it in the AI settings configuration something like secondary model with short explanation what it does (generate chat name, used for code generation block, etc.).

@octo-patch happy to assist if you need more information how to adapt the PR