[Feature]: Provider onboarding: allow editing/adding model IDs, reachable custom mode, and persist a config.yaml template when the test fails

[SvenMeyer]

Product or interface

CLI - interactive TUI

Use case and problem

The interactive "add third-party provider" flow is too rigid for aggregators like OpenRouter, and a failed connectivity test discards everything instead of leaving an editable config template. Concretely:

1. OpenRouter is not offered at all. Presets come from models.dev via packages/local-runtime-v2/src/service/model-system/catalog/provider-presets/provider-presets.service.ts, but resolveTransport() only recognizes @ai-sdk/openai, @ai-sdk/openai-compatible, and @ai-sdk/anthropic. models.dev lists OpenRouter as @openrouter/ai-sdk-provider, so the OpenRouter preset is silently dropped from the picker.

2. Known-provider models are locked to the preset list; only the URL can be edited. In packages/tui/src/tui/features/provider/onboarding.ts, the known-provider flow lists this.template.models, and Ctrl+E edits only the Base URL. saveInput() for a template sends models: this.template.models and modelId: this.selectedModelId. So if a user picks the DeepSeek preset (base URL https://api.deepseek.com, model ID deepseek-flash) and changes the URL to OpenRouter, they cannot change the model ID to deepseek/deepseek-v4.1-flash — the test fails, and there is no model-ID field to fix it. (The generic "Custom provider" entry does let you type a model ID, but it is a separate path and does not carry the preset's base URL/format.)

3. A failed test saves nothing. onboarding.ts save() reports Changes were not saved. ... and returns; no custom_provider entry is written to config.yaml. The only recovery is to quit and hand-edit ~/.minimax/config.yaml.

Net effect: adding OpenRouter requires knowing the models.dev npm quirk, hand-editing YAML, and guessing the custom_provider shape.

Desired behavior

Make the interactive flow flexible enough that a known aggregator/provider can be configured without hand-editing YAML:

• Recognize aggregator presets. Accept @openrouter/ai-sdk-provider (map it to openai-completions), or more generally treat OpenAI-compatible providers as addable.
• Editable model ID in the known-provider flow. Allow adding/editing a model ID (and optionally capability/limit fields) for a selected preset, not just choosing from template.models. A good UX: keep the preset list, but offer "Add model ID..." / an editable field alongside Ctrl+E edit URL.
• Reachable custom mode prefilled from a preset. Entering a model ID manually should be possible without abandoning the preset's base URL and API format.
• Persist on failure. When the connection test fails, still write the provider entry (or a clearly-marked draft/template) to config.yaml and point the user at it, instead of discarding all input. The pre-save docs already say unsaved changes remain in the UI as a draft; persisting a template would make that usable across restarts.

Acceptance criteria:

• Picking OpenRouter (or a provider whose models.dev npm is unknown) is possible from the picker, or results in an editable custom entry rather than a dropped preset.
• From a known-provider entry, a user can change both the Base URL and the model ID before testing.
• After a failed test, the provider appears as an editable entry in config.yaml (or the UI explicitly offers "Save anyway as template").
• A validated example fixture covers an OpenRouter openai-completions provider added through the interactive flow.

Platform

Multiple platforms

Alternatives and additional context

• Workaround today: hand-edit ~/.minimax/config.yaml and add the custom_provider entry directly.
• Related: [Feature]: Openrouter support in custom models #215 (generic OpenRouter support), [Feature]: Honor compat.openRouterRouting in BYOK custom providers (OpenRouter provider routing: sort/order/only) #288 (runtime support for compat.openRouterRouting, which is the other half of OpenRouter support).
• mcode --version: 0.5.1.

[SvenMeyer]

A smaller change than opening the whole models.dev catalog: admit only the openrouter preset, and keep every other filter.

resolveTransport() drops OpenRouter because models.dev sets npm to @openrouter/ai-sdk-provider. The HTTP API is still Chat Completions at https://openrouter.ai/api/v1, which this runtime already speaks. Match the provider id, not that npm package. standardcompute reuses @openrouter/ai-sdk-provider with a different base URL (https://api.stdcmpt.com/v1), so an npm-wide exception would admit a second provider.

} else if (providerId === 'openrouter') {
  // models.dev tags OpenRouter with @openrouter/ai-sdk-provider, but the
  // endpoint is Chat Completions. Match the id: other providers reuse that package.
  apiFormat = 'openai-completions';
  baseUrl = stringValue(provider.api);
} else {
  return undefined;
}

What stays filtered:

• MiniMax provider ids (minimax, minimax-cn, and the coding-plan ids)
• models with tool_call !== true (the agent always sends tools)
• every other non-allowlisted SDK (Google, xAI, Groq, the Vercel gateway, …)

Saving a new preset still copies template.models into custom_provider (onboarding.ts saveInput()). For OpenRouter that is the tool-calling subset, about 300 models, including xiaomi/mimo-v2.6-pro. One model is selected with modelId.

I checked this on a fork, not against a live OpenRouter call: SvenMeyer/minimax-code@bd97572 (openrouter-preset). The new test expects OpenRouter at https://openrouter.ai/api/v1 with openai-completions, keeps xiaomi/mimo-v2.6-pro, drops a tool_call: false model, and drops standardcompute.

pnpm exec vitest run --config vitest.oss.config.mjs \
  packages/local-runtime-v2/src/service/model-system/catalog/provider-presets/provider-presets.service.test.ts

38 passed.

This does not implement #288. compat.openRouterRouting is still ignored by readModelCompat() before the pi transport can set the request provider field. Routing variants such as :nitro keep working from the model id alone.

[SvenMeyer]

Tested the OpenRouter preset mapping in the TUI, from SvenMeyer/minimax-code@bd97572. Branch: https://github.com/SvenMeyer/minimax-code/tree/openrouter-preset

I could not open a pull request from this account (CreatePullRequest is rejected, which matches the collaborator-only note in CONTRIBUTING). The patch is ready for a maintainer to take from that branch, or from the compare view: https://github.com/MiniMax-AI/minimax-code/compare/main...SvenMeyer:openrouter-preset?expand=1

Add 3rd-party provider on an already configured custom_provider:openrouter offers Use existing connection. Search mimo-v2.6 lists:

• xiaomi/mimo-v2.6-flash
• xiaomi/mimo-v2.6-pro
• xiaomi/mimo-v2.6-pro-ultraspeed

Flash details match models.dev: context 1,048,576, output 131,072, input text/image/video/audio, attachments, reasoning, tools, temperature. Base URL stayed https://openrouter.ai/api/v1.

What happened on save:

• First Flash attempt: Changes were not saved. Request timed out after 10000ms. The failed-test path in this issue is still open. This patch does not persist a template when the test times out.
• Pro-UltraSpeed saved: Provider updated: openrouter · custom_provider:openrouter/xiaomi/mimo-v2.6-pro-ultraspeed and the model answered.
• Flash saved on a later attempt. The status line showed MiMo-V2.6-Flash.

Still out of scope for the PR: typing an arbitrary model id on a known preset, and saving a draft when the connection test fails. #288 (compat.openRouterRouting) is also unchanged.