Add MiniMax provider support

[octo-patch]

Reason: add target provider/model to existing provider registry

Summary

• Add MiniMax provider aliases for global and CN OpenAI-compatible and Anthropic-compatible endpoints.
• Register MiniMax-M3 and MiniMax-M2.7 with context windows, input modalities, protocol-specific thinking defaults, and complete standard, priority, and long-context pricing tiers.
• Reuse the existing chat adapters with provider-specific request options and Anthropic base URL handling, and account for cache creation and service tiers.
• Add focused coverage for provider registration, model metadata, endpoint formatting, and pricing tier boundaries.

Checks

• dotnet build src/Plugins/BotSharp.Plugin.MiniMaxAI/BotSharp.Plugin.MiniMaxAI.csproj --configuration Release --nologo
• dotnet test tests/BotSharp.LLM.Tests/BotSharp.LLM.Tests.csproj --configuration Release --filter FullyQualifiedName~MiniMaxProviderTests --nologo
• SDK request captures verified /v1/chat/completions for OpenAI-compatible base URLs and /anthropic/v1/messages for Anthropic-compatible base URLs.
• git diff --check

[qodo-code-review]

PR Summary by Qodo

Add MiniMax provider plugin and register MiniMax-M3 model

✨ Enhancement ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Add MiniMax provider plugin reusing OpenAI-compatible completion providers.
• Register MiniMax-M3 model with MiniMax endpoint and token pricing in WebStarter settings.
• Wire MiniMax plugin into solution and WebStarter project references.

Diagram

graph TD
  A["WebStarter"] --> B["Plugin loader"] --> C["MiniMax plugin"] --> D["OpenAI providers"] --> E{{"MiniMax API"}}
  A --> F["appsettings.json"] --> D

  subgraph Legend
    direction LR
    _app["App"] ~~~ _svc["Service"] ~~~ _ext{{"External"}}
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Configurable OpenAI-compatible alias providers (no new plugin)

• ➕ Avoids creating one plugin per OpenAI-compatible vendor
• ➕ Centralizes provider-key-to-endpoint mapping in configuration
• ➕ Reduces solution/project churn
• ➖ Requires changes in the provider registry/selection logic to support aliases
• ➖ Less explicit discoverability vs dedicated plugin assemblies
• ➖ Harder to attach vendor-specific defaults/metadata later

2. Extend BotSharp.Plugin.OpenAI to support multiple provider keys

• ➕ Keeps all OpenAI-compatible logic in one place
• ➕ Potentially simplest dependency graph (one plugin)
• ➖ Increases coupling between OpenAI plugin and third-party vendor support
• ➖ Risk of vendor-specific configuration leaking into a generic plugin
• ➖ Harder to version/enable/disable vendors independently

Recommendation: The PR’s approach (a thin MiniMax plugin that reuses existing OpenAI-compatible providers) is a good tradeoff: minimal new code, clean separation, and consistent provider registration via a dedicated provider key. Consider the alias/multi-provider-key approaches only if many more OpenAI-compatible vendors are expected and plugin-per-vendor becomes operationally noisy.

Files changed (8) +112 / -0

Enhancement (4) +63 / -0

BotSharp.Plugin.MiniMaxAI.csprojCreate MiniMaxAI plugin project referencing OpenAI plugin +17/-0

Create MiniMaxAI plugin project referencing OpenAI plugin

• Introduces a new SDK-style project for the MiniMax plugin and references BotSharp.Plugin.OpenAI to reuse OpenAI-compatible provider implementations.

src/Plugins/BotSharp.Plugin.MiniMaxAI/BotSharp.Plugin.MiniMaxAI.csproj

MiniMaxAiPlugin.csRegister MiniMax plugin metadata and DI bindings +18/-0

Register MiniMax plugin metadata and DI bindings

• Adds the IBotSharpPlugin implementation with MiniMax metadata and registers chat/text completion services into DI for provider key routing.

src/Plugins/BotSharp.Plugin.MiniMaxAI/MiniMaxAiPlugin.cs

ChatCompletionProvider.csAdd MiniMax chat provider wrapper over OpenAI-compatible chat +15/-0

Add MiniMax chat provider wrapper over OpenAI-compatible chat

• Implements a thin subclass of the OpenAI chat completion provider, overriding the Provider identifier to 'minimax' while delegating behavior to the base implementation.

src/Plugins/BotSharp.Plugin.MiniMaxAI/Providers/Chat/ChatCompletionProvider.cs

TextCompletionProvider.csAdd MiniMax text provider wrapper over OpenAI-compatible text +13/-0

Add MiniMax text provider wrapper over OpenAI-compatible text

• Implements a thin subclass of the OpenAI text completion provider, overriding the Provider identifier to 'minimax' and reusing the base logic.

src/Plugins/BotSharp.Plugin.MiniMaxAI/Providers/Text/TextCompletionProvider.cs

Refactor (1) +8 / -0

Using.csAdd global usings for MiniMax plugin compilation +8/-0

Add global usings for MiniMax plugin compilation

• Defines global using directives for configuration, DI, logging, and BotSharp abstractions used by the MiniMax plugin classes.

src/Plugins/BotSharp.Plugin.MiniMaxAI/Using.cs

Other (3) +41 / -0

BotSharp.slnAdd MiniMax plugin project to the solution +15/-0

Add MiniMax plugin project to the solution

• Registers the new BotSharp.Plugin.MiniMaxAI project in the solution and adds build configurations and solution-folder mapping so it participates in Debug/Release builds.

BotSharp.sln

WebStarter.csprojReference MiniMax plugin from WebStarter +1/-0

Reference MiniMax plugin from WebStarter

• Adds a project reference so WebStarter builds and can load the MiniMax plugin assembly.

src/WebStarter/WebStarter.csproj

appsettings.jsonRegister MiniMax provider/model and enable plugin loading +25/-0

Register MiniMax provider/model and enable plugin loading

• Adds a 'minimax' provider entry with the MiniMax-M3 chat model, endpoint, and cost settings, and includes BotSharp.Plugin.MiniMaxAI in the plugin assembly list for runtime loading.

src/WebStarter/appsettings.json

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Undeclared OpenAI dependency ✓ Resolved 🐞 Bug ☼ Reliability

Description

MiniMax providers require OpenAiSettings via DI, but MiniMaxAiPlugin.RegisterDI doesn’t
register/bind OpenAiSettings, so MiniMax fails to resolve if BotSharp.Plugin.OpenAI isn’t also
loaded as a plugin. Because PluginLoader only initializes plugins from explicitly listed
assemblies, a project reference to the OpenAI plugin does not guarantee OpenAiPlugin.RegisterDI
ran.

Code

src/Plugins/BotSharp.Plugin.MiniMaxAI/MiniMaxAiPlugin.cs[R13-17]

+    public void RegisterDI(IServiceCollection services, IConfiguration config)
+    {
+        services.AddScoped<ITextCompletion, TextCompletionProvider>();
+        services.AddScoped<IChatCompletion, ChatCompletionProvider>();
+    }

Evidence

MiniMax registers only completion providers, but both providers require OpenAiSettings in their
constructors; OpenAiSettings is registered by OpenAiPlugin, and the plugin loader only
initializes DI registrations for assemblies listed in PluginLoader:Assemblies, so MiniMax has an
implicit dependency that can break at runtime if OpenAI plugin isn’t loaded as a plugin.

src/Plugins/BotSharp.Plugin.MiniMaxAI/MiniMaxAiPlugin.cs[13-17]
src/Plugins/BotSharp.Plugin.MiniMaxAI/Providers/Chat/ChatCompletionProvider.cs[7-13]
src/Plugins/BotSharp.Plugin.MiniMaxAI/Providers/Text/TextCompletionProvider.cs[7-10]
src/Plugins/BotSharp.Plugin.OpenAI/OpenAiPlugin.cs[23-33]
src/Infrastructure/BotSharp.Core/Plugins/PluginLoader.cs[19-38]
src/WebStarter/appsettings.json[1066-1084]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
MiniMax provider implementations inject `OpenAiSettings`, but the MiniMax plugin does not register/bind `OpenAiSettings` itself and does not declare a plugin dependency on `BotSharp.Plugin.OpenAI`. This makes the plugin fragile: if the host forgets to include/load the OpenAI plugin assembly as a plugin, MiniMax provider activation will fail at runtime.
## Issue Context
- `PluginLoader` only discovers and initializes `IBotSharpPlugin` types from `PluginLoader:Assemblies`.
- MiniMax inherits OpenAI providers and therefore depends on `OpenAiPlugin`’s DI registrations.
## Fix Focus Areas
- Add an explicit plugin dependency attribute on the MiniMax plugin class.
- Ensure `OpenAiSettings` is registered when missing (use `TryAdd` to avoid overriding the OpenAI plugin’s registration when it is present).
### Suggested changes
1) Add `[PluginDependency("BotSharp.Plugin.OpenAI")]` to `MiniMaxAiPlugin`.
2) In `MiniMaxAiPlugin.RegisterDI`, add a `services.TryAddScoped(...)` registration for `OpenAiSettings` that binds the `OpenAi` section (mirroring `OpenAiPlugin`), so MiniMax can still run when OpenAI plugin isn’t initialized.
## Fix Focus Areas (by file/lines)
- src/Plugins/BotSharp.Plugin.MiniMaxAI/MiniMaxAiPlugin.cs[6-17]
- src/Plugins/BotSharp.Plugin.MiniMaxAI/Providers/Chat/ChatCompletionProvider.cs[3-13]
- src/Plugins/BotSharp.Plugin.MiniMaxAI/Providers/Text/TextCompletionProvider.cs[3-10]
- src/Plugins/BotSharp.Plugin.OpenAI/OpenAiPlugin.cs[23-33]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Global response API coupling ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

MiniMax inherits BotSharp.Plugin.OpenAI’s ChatCompletionProvider, so it is forced to follow the
global OpenAiSettings.UseResponseApi behavior with no per-provider override. With WebStarter
setting OpenAi:UseResponseApi to true, MiniMax is locked into the Responses codepath, making it
impossible to run OpenAI in Responses mode while keeping MiniMax on legacy chat-completions mode.

Code

src/Plugins/BotSharp.Plugin.MiniMaxAI/Providers/Chat/ChatCompletionProvider.cs[R3-6]

+public class ChatCompletionProvider : global::BotSharp.Plugin.OpenAI.Providers.Chat.ChatCompletionProvider
+{
+    public override string Provider => "minimax";
+

Evidence

MiniMax’s chat provider subclasses the OpenAI chat provider, which branches on
OpenAiSettings.UseResponseApi; WebStarter sets that flag to true, so MiniMax inherits the
Responses-vs-chat-completions decision without a way to configure it per provider.

src/Plugins/BotSharp.Plugin.MiniMaxAI/Providers/Chat/ChatCompletionProvider.cs[3-6]
src/Plugins/BotSharp.Plugin.OpenAI/Providers/Chat/ChatCompletionProvider.cs[34-44]
src/WebStarter/appsettings.json[44-46]
src/Plugins/BotSharp.Plugin.OpenAI/Providers/Chat/ChatCompletionProvider.Response.cs[21-26]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`OpenAiSettings.UseResponseApi` is a single global toggle, but MiniMax reuses the OpenAI chat provider and therefore inherits that toggle. This couples MiniMax’s protocol selection to the OpenAI provider’s setting and prevents independent configuration.
## Issue Context
- MiniMax chat provider only overrides `Provider`, so it inherits all OpenAI request-shaping logic.
- The OpenAI chat provider branches to the Responses API when `UseResponseApi` is true.
- WebStarter sets `OpenAi:UseResponseApi` to true.
## Fix Focus Areas
- Make the `UseResponseApi` check provider-aware (e.g., only enable Responses API when `Provider == "openai"`), or add a per-provider/per-model override (e.g., list of providers allowed to use Responses API).
### Suggested minimal fix
Update OpenAI ChatCompletionProvider to use Responses API only for the actual OpenAI provider:
- Change `if (_settings.UseResponseApi)` to `if (_settings.UseResponseApi && Provider == "openai")`
This keeps OpenAI on Responses API while allowing OpenAI-compatible third-party providers (like MiniMax) to stay on legacy chat-completions.
## Fix Focus Areas (by file/lines)
- src/Plugins/BotSharp.Plugin.OpenAI/Providers/Chat/ChatCompletionProvider.cs[34-70]
- src/WebStarter/appsettings.json[44-46]
- src/Plugins/BotSharp.Plugin.MiniMaxAI/Providers/Chat/ChatCompletionProvider.cs[3-6]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---