feat(tui): add OpenAI-compatible provider setup from /provider

[WENGENG-boop]

Related Issue

No linked issue yet. This PR addresses a provider setup limitation in the native Kimi Code TUI: users can configure custom OpenAI-compatible providers in config.toml, but the current /provider flow does not provide a native way to enter a provider base URL/API key, discover available models, and make those models available through /model.

Problem

OpenAI-compatible third-party providers often expose many models and may change their model list over time. Today, users who want to use those providers need to manually edit configuration, predefine model aliases, and keep those aliases in sync themselves.

That makes the experience especially awkward for users who expect provider setup to stay inside Kimi Code's native terminal UI:

• /provider can manage known providers, but not arbitrary OpenAI-compatible endpoints.
• /model only shows aliases that were manually configured in advance.
• GPT/OpenAI reasoning models cannot reliably expose native /effort choices unless the alias is written with the right thinking metadata.

What Changed

This PR adds a native OpenAI-compatible provider setup flow to /provider.

Users can now choose OpenAI-compatible provider from the provider add menu, then enter:

• Provider ID
• Base URL
• API Key

After submission, Kimi Code fetches ${baseUrl}/models, creates model aliases automatically, refreshes config, and opens the native model selector with the newly discovered models.

The generated provider config uses the existing OpenAI provider type, and generated model aliases use the existing Kimi Code model alias schema. For model ids that look like OpenAI/GPT reasoning models, the aliases include native thinking support so /effort can offer:

• low
• medium
• high
• xhigh

The provider manager also now allows single provider rows to be edited with Enter, so users can update an OpenAI-compatible provider's base URL or API key from the native /provider UI later.

Why This Fits Kimi Code

The implementation reuses existing Kimi Code behavior instead of introducing a separate plugin command or a parallel model switching surface:

• Provider configuration is still written through the existing config harness.
• Model selection stays in the existing native /model selector.
• Thinking strength stays in the existing native /effort command.
• Existing known-provider and custom-registry flows remain unchanged.

Checklist

• I have read the CONTRIBUTING document.
• I have linked a related issue, or explained the problem above.
• I have added tests that prove my feature works.
• Ran gen-changesets skill, or this PR needs no changeset.
• Ran gen-docs skill, or this PR needs no doc update.

Test Plan

• pnpm --filter @moonshot-ai/kimi-code run typecheck
• .\node_modules\.bin\vitest.CMD run apps\kimi-code\test\tui\components\dialogs\provider-manager.test.ts
• Manually verify /provider with a real OpenAI-compatible endpoint:
  • Add provider from the native TUI.
  • Confirm ${baseUrl}/models is fetched successfully.
  • Confirm discovered aliases appear in /model.
  • Select a GPT/OpenAI reasoning model and confirm /effort exposes low, medium, high, and xhigh.

[changeset-bot]

🦋 Changeset detected

Latest commit: 5f133d6

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@moonshot-ai/kimi-code	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR