feat(auth): add Kimi (Moonshot AI) as a built-in third-party provider

[TianYuan1024]

What this PR does

Adds Kimi (Moonshot AI) as a built-in entry under /auth → Third-party Providers, so connecting to Kimi takes an API key instead of a hand-rolled Custom Provider setup. Selecting it offers a choice between the international and China endpoints, then seeds the current Kimi model catalog — the flagship K3, the two dedicated code models, and K2.6 — with the context window and capability metadata each one needs. The model list stays editable, so users can add newer IDs without waiting for a release.

Moonshot's API speaks the OpenAI protocol, so this is a declarative provider preset with no new mechanism and no change to the provider type. One piece of model metadata is worth calling out: K3 is registered as thinking-mandatory, because its API exposes a reasoning-effort knob but no way to turn thinking off, so the request pipeline must never put a thinking-disabled shape on the wire — that would be a guaranteed failure. The other three models keep thinking toggleable, and all four are registered as accepting image and video input, which Moonshot's model guides state directly.

The new credential environment variable is registered everywhere a provider key has to appear: the no-API-key CI gate that clears provider credentials before the unauthenticated integration run, the pinned assertion list that guards that gate against silent drift, and the telemetry provider mapping — both by environment key and by request hostname, so Kimi traffic is attributed rather than reported as unknown. The three first-run docs that enumerate built-in providers are brought back into agreement with the registry, which also picks up entries that were already stale beforehand.

Why it's needed

Kimi is one of the more popular model families for coding, and Moonshot is a provider of comparable standing to DeepSeek, MiniMax, and Z.AI — all of which already have one-click entries in the Third-party Providers menu. Today, anyone wanting to use Kimi has to either hand-edit settings or walk through Custom Provider, while peers of similar popularity get a guided setup. The product already acknowledges Kimi models through the Alibaba Cloud plans and the Idealab provider, which makes the absence of a first-party Moonshot entry an obvious gap rather than a missing capability.

Reviewer Test Plan

How to verify

1. Launch the CLI and open /auth → Third-party Providers. Kimi should appear in the list alongside the other direct-API providers, with the footer still visible and no entries clipped.
2. Select it. The first step should offer an endpoint choice between International and China, showing the corresponding API address under each.
3. Pick either endpoint and enter any placeholder key. The final step should recommend four Kimi models, each showing its context window and capabilities — K3 at one million tokens, the rest at 256K with thinking toggleable, and all four accepting image and video.
4. Cancel before submitting real credentials, or complete the setup with a genuine key and confirm via /model that the installed entries carry the expected context windows.

Evidence (Before & After)

Before: Kimi had no entry in Third-party Providers; reaching a Moonshot endpoint required Custom Provider or hand-edited settings.

After: the provider list and the endpoint step, captured from the rendered dialog:

Third-party Providers · Provider          Kimi (Moonshot AI) API Key · Step 1/3 · Endpoint

› DeepSeek API Key                        › International
  Grok (xAI) API Key                        https://api.moonshot.ai/v1
  MiniMax API Key
  Z.AI API Key                              China
  Kimi (Moonshot AI) API Key                https://api.moonshot.cn/v1
  Idealab API Key
  ModelScope API Key                      Enter to select, ↑↓ to navigate, Esc to go back
  OpenRouter
  Requesty

Enter to select, ↑↓ to navigate, Esc to go back

The model step, reached after choosing an endpoint and entering a key:

Kimi (Moonshot AI) API Key · Step 3/3 · Model IDs

Recommended models

◉︎   kimi-k3                      1,000,000 tokens, text/image/video
◉︎   kimi-k2.7-code               262,144 tokens, thinking, text/image/video
◉︎   kimi-k2.7-code-highspeed     262,144 tokens, thinking, text/image/video
◉︎   kimi-k2.6                    262,144 tokens, thinking, text/image/video

Automated validation: the provider and telemetry suites pass (216 tests across 16 files), as do the CI-gate guard test, lint, formatting, and the core typecheck. The full core suite was also run: its single failure is an extension update-policy test that reproduces identically on a clean main and is unrelated to this change.

Each model entry is covered by an install-plan assertion, including negative assertions pinning the absence of the thinking-mandatory flag on the toggleable models — mutation probes confirm that corrupting any entry's context window, thinking metadata, or modalities turns the suite red.

Tested on

OS	Status
🍏 macOS	✅
🪟 Windows	⚠️
🐧 Linux	⚠️

Environment (optional)

macOS, Node.js 22, tests run from the package directories; the dialog evidence was captured by rendering the auth dialog headlessly rather than from a live terminal session.

Risk & Scope

• Main risk or tradeoff: model identifiers, context windows, and capabilities track an upstream catalog that will move; the editable model list is the escape hatch between releases. The endpoint choice covers the two regional API endpoints, which share one catalog — the subscription Coding Plan endpoint has a different catalog and is deliberately left out, since the current preset shape carries a single model list per provider.
• Not validated / out of scope: no live paid credentials were submitted, so no end-to-end request was made against either endpoint; Windows and Linux were not exercised locally.
• Breaking changes / migration notes: none. Existing Custom Provider setups pointing at Moonshot keep working.

Linked Issues

Closes #9197

Overlaps with #8368, which adds the same provider as part of a larger change that also introduces a second provider, endpoint-scoped model metadata across every surface, and a provider-list pagination fix. This PR is deliberately the narrow slice the issue asks for and does not attempt to replace that work; see the note posted there. Supersedes #9756, which was closed and reopened here with a clean history.

中文说明

这个 PR 做了什么

在 /auth → Third-party Providers 中加入 Kimi（Moonshot AI）内置入口，用户只需一个 API key 即可接入 Kimi，而不必再手动配置 Custom Provider。选中后先选择国际或中国端点，随后自动填入当前的 Kimi 模型目录 —— 旗舰 K3、两个专用代码模型，以及 K2.6，并为每个模型带上所需的上下文长度与能力元数据。模型列表保持可编辑，用户无需等待发版即可自行添加更新的模型 ID。

Moonshot 的 API 兼容 OpenAI 协议，因此这是一个声明式的 provider 预设，没有引入新机制，也没有改动 provider 类型定义。有一处模型元数据值得说明：K3 被标记为 thinking 强制开启，因为其 API 提供 reasoning effort 调节，但没有关闭 thinking 的方式，因此请求管线绝不能在链路上发出"关闭 thinking"的形状 —— 那必然导致失败。其余三个模型的 thinking 保持可开关，且四个模型均登记为支持图像与视频输入，这一点 Moonshot 的模型指南有明确说明。

新的凭据环境变量已在所有需要登记 provider key 的位置注册：在无凭据集成测试运行前清空 provider 凭据的 no-AK CI 门禁、防止该门禁被悄然改动的固定断言列表，以及遥测的 provider 映射 —— 同时覆盖环境变量与请求域名两条路径，使 Kimi 流量能被正确归因而非记为未知。三处枚举内置 provider 的入门文档也重新与注册表保持一致，并顺带修正了此前已经过期的条目。

为什么需要

Kimi 是编码场景中较受欢迎的模型家族之一，Moonshot 的地位与 DeepSeek、MiniMax、Z.AI 相当，而后三者在 Third-party Providers 菜单中均已有一键入口。目前想使用 Kimi 的用户只能手动编辑配置或走 Custom Provider 流程，而同等热度的同行却有引导式配置。产品中已经通过阿里云各计划与 Idealab provider 承认了 Kimi 模型的存在，这让缺少一方 Moonshot 入口更像是一个明显的空缺，而非能力缺失。

Reviewer 测试计划

如何验证

1. 启动 CLI，打开 /auth → Third-party Providers。Kimi 应与其他直连 API 的 provider 一同出现在列表中，页脚仍然可见，且没有条目被裁剪。
2. 选中它。第一步应提供国际与中国两个端点选项，并在各自下方显示对应的 API 地址。
3. 任选一个端点并输入占位 key。最后一步应推荐四个 Kimi 模型，各自显示上下文长度与能力 —— K3 为一百万 token，其余三个为 256K 且 thinking 可开关，四者均支持图像与视频。
4. 在提交真实凭据前取消，或使用真实 key 完成配置并通过 /model 确认已安装条目的上下文长度符合预期。

证据（Before & After）

Before： Kimi 在 Third-party Providers 中没有入口；接入 Moonshot 端点需要走 Custom Provider 或手改配置。

After： provider 列表、端点选择步骤与模型步骤，均取自实际渲染的对话框，见上方英文正文中的终端输出。

自动化验证：provider 与遥测测试套件通过（16 个文件共 216 项），CI 门禁守卫测试、lint、格式化与 core 类型检查亦均通过。core 全量测试也已运行：其唯一失败为扩展更新策略测试，在干净的 main 上同样复现，与本次改动无关。

每个模型条目都有 install plan 断言覆盖，其中包含针对可开关 thinking 模型钉住"无 thinking 强制标志"的负向断言 —— 变异探测确认，破坏任一条目的上下文长度、thinking 元数据或模态都会使测试变红。

测试环境

OS	Status
🍏 macOS	✅
🪟 Windows	⚠️
🐧 Linux	⚠️

环境（可选）

macOS，Node.js 22，测试从各 package 目录执行；对话框证据通过无头渲染 auth 对话框获得，而非实际终端会话截图。

风险与范围

• 主要风险或取舍：模型标识、上下文长度与能力跟随上游目录变化；可编辑的模型列表是版本间的兜底方案。端点选择覆盖两个区域 API 端点（二者共用同一模型目录）—— 订阅制 Coding Plan 端点的模型目录不同，本 PR 有意不涵盖，因为当前预设结构对每个 provider 只承载一份模型列表。
• 未验证 / 范围之外：未提交真实付费凭据，因此未对任一端点发起端到端请求；未在本地验证 Windows 与 Linux。
• 破坏性变更 / 迁移说明：无。已有指向 Moonshot 的 Custom Provider 配置继续有效。

关联 Issue

Closes #9197

与 #8368 存在重叠：该 PR 在一个更大的改动中加入了同一 provider，同时还引入了第二个 provider、贯穿各端的 endpoint 级模型元数据，以及 provider 列表分页修复。本 PR 有意只做 issue 所要求的最小切片，并不试图取代那项工作；详见已在该 PR 中留下的说明。本 PR 取代 #9756，后者已关闭并在此以干净的提交历史重新提交。

[qwen-code-ci-bot]

✅ Qwen Triage finished — CI landed green on 5ca34b2 and the deferred approval was posted. finalize run

✅ Qwen Triage 已完成 —— 5ca34b2 的 CI 全绿，延迟审批已提交。查看 finalize 运行

[qwen-code-ci-bot]

Thanks for the PR — this is a clean re-submission of #9756 with the history tidied up, and it lands exactly on the sketch we left on #9197.

• Template: complete ✓
• Problem: real and observed — feat(auth): add Kimi (Moonshot AI) as a built-in third-party provider in /auth #9197 is a user-filed feature request carrying maintainer labels (type/feature-request, category/authentication, roadmap/model-inference), and the issue-level direction review already accepted it for exploration with an implementation sketch.
• Direction: aligned. Umbrella Enhance support for non-Qwen models and providers #975 (non-Qwen provider support) covers it, DeepSeek/Grok/MiniMax/Z.AI all ship the same one-click preset, and the same author's Grok preset (feat(providers): add xAI Grok provider preset #6805) merged through this exact path in July. The direction question was settled at the issue stage; this PR is the implementation of it.
• Size: core paths touched (providers/**, telemetry/**). ~79 production lines (preset 61, telemetry 7, registry 4, CI gate 1, docs 3 files ±3) vs. ~146 test lines — a small feat, no threshold applies.
• Approach: scope is right — one declarative preset plus the registrations the registry comment in all-providers.ts explicitly requires (no-AK CI gate, pinned env list, telemetry mapping), no new mechanism. The docs hunks also re-add Grok/Idealab entries that were stale on main; that's on the same lines the PR must touch, and the body discloses it. One coordination note for maintainers, not a blocker: feat(auth): add Kimi and Xiaomi MiMo providers #8368 (Kimi + MiMo) is still open and overlaps this provider — its MiMo half has already landed separately, so this looks like the narrow slice the issue asks for, but the merge order is yours to call.
• Risk: no high-risk path matches from the revert-history signal.

Moving on to code review. 🔍

中文说明

感谢贡献 —— 这是 #9756 清理提交历史后的重新提交，且与我们在 #9197 中给出的实现要点完全一致。

• 模板：完整 ✓
• 问题：真实且已观测 —— feat(auth): add Kimi (Moonshot AI) as a built-in third-party provider in /auth #9197 是用户提交的功能请求，带有维护者标签（type/feature-request、category/authentication、roadmap/model-inference），issue 阶段的方向评审已接受探索并给出实现要点。
• 方向：对齐。伞 issue Enhance support for non-Qwen models and providers #975（非 Qwen provider 支持）覆盖此方向，DeepSeek/Grok/MiniMax/Z.AI 均已有同类一键预设，同一作者的 Grok 预设（feat(providers): add xAI Grok provider preset #6805）七月已经走通同样路径合入。方向问题已在 issue 阶段解决，本 PR 是其实现。
• 规模：触及核心路径（providers/**、telemetry/**）。约 79 行生产代码（preset 61、遥测 7、注册表 4、CI 门禁 1、文档 3 文件 ±3），测试约 146 行 —— 小型 feat，不触及任何阈值。
• 方案：范围合理 —— 一个声明式预设，加上 all-providers.ts 注册表注释明确要求的登记（no-AK CI 门禁、固定环境变量列表、遥测映射），无新机制。文档改动顺带补回了 Grok/Idealab 两个在 main 上已过期的条目，与本 PR 必须修改的行重合，且正文已披露。一个供维护者知悉的协调事项（非阻塞）：feat(auth): add Kimi and Xiaomi MiMo providers #8368（Kimi + MiMo）仍然 open 且与本 provider 重叠 —— 其 MiMo 部分已单独合入，本 PR 看起来正是 issue 所要求的最小切片，但合入顺序由维护者决定。
• 风险：回滚历史高风险路径无匹配。

进入代码审查。🔍

— Qwen Code · qwen3.8-max

_{Reviewed at 5ca34b2f8eeea2b0dbdcf151c626ece88ea286d0 · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Code review

Read against 5ca34b2. My independent proposal for this issue — a declarative preset mirroring zai.ts, registered in all-providers.ts, plus the env-key registrations — is exactly what this PR does, so the review was about verifying the details, and they hold up:

• Preset shape: every field type-checks against ProviderConfig / ModelSpec / BaseUrlOption; the two-endpoint baseUrl array follows the Z.AI Standard/Coding-Plan pattern verbatim.
• K3 thinkingMandatory is the one non-obvious claim, so I traced it: the pipeline's strip of enable_thinking: false / reasoning_effort: 'none' / chat_template_kwargs disable shapes is explicitly model- and host-agnostic (thinkingMandatory "stays ungated … model-agnostic by design"), there is an end-to-end test that a disable shape never ships to a thinking-mandatory model, and runtime error-learning retries as a second net. The flag is already in production use on Token Plan models, and buildGenerationConfig maps the spec fields exactly as the new tests assert (K3 gets no extra_body at all — correct).
• Model metadata corroborated in-tree: tokenLimits.ts already maps kimi-k3 → 1M and kimi- fallback → 256K, modalityDefaults.ts maps kimi-k3 / kimi-k2.x → image+video, and Token Plan ships kimi-k2.7-code with identical numbers (this PR's k2.6 gains modalities, matching modalityDefaults — the Token Plan entry is the stale one, not this PR).
• Registration checklist from the registry comment is complete: cleared env in ci.yml and the pinned no-AK assertion list (both alphabetical), telemetry mapping by env key and by both hostnames, with tests on each.
• Tests are real: negative assertions pin the absence of thinkingMandatory on the toggleable models and of extra_body on K3, credential lookup has a mismatch negative, and unknown IDs fall back cleanly.

No critical findings, no convention violations. Not verified: the rendered /auth dialog flow (see the lane below), and no live Moonshot request was made — the PR says so itself, and the preset carries no paid-credential path to test here.

Testing — the PR's own CI, read via API (unattended run; no PR code executed here). Security and desktop checks are green; the core unit suite on ubuntu-latest is still running at the time of this pass — I don't poll, and the finalize job will refresh the table below once CI settles. The macOS/Windows test legs and the no-sandbox integration leg are skipped by CI profile gating, which is the usual shape for fork PRs.

Final CI results for 5ca34b2 (auto-updated by the triage finalize job after CI completed):

Check	Conclusion
Classify PR	✅ success
Dependency CVE audit	✅ success
Desktop Shell (ubuntu-22.04)	✅ success
Desktop Shell (windows-2022)	✅ success
Secret scan (TruffleHog)	✅ success
Test (ubuntu-latest, Node 22.x)	✅ success
web-shell E2E Smoke (ubuntu-latest, Node 22.x)	✅ success

_{One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行（取最新一次运行），省略 skipped，失败项排在最前。}

Sandboxed verification would settle the remaining surface claim: @qwen-code /verify — that the Kimi entry actually renders in /auth → Third-party Providers (now nine entries — is anything clipped?) and that the endpoint + model steps install the four models with the pinned metadata end-to-end is not observable from the diff, and this PR's suite would still pass with the registry wiring severed. The author lacks write access, so this would be a sponsored run: a maintainer's @qwen-code /verify approves the head it's written against, the run carries a pre-execution risk screen and a full workspace wipe — and its report should be read with the same skepticism as the fork's own CI logs.

中文说明

代码审查

基于 5ca34b2 阅读。我对该 issue 的独立方案 —— 仿照 zai.ts 的声明式预设、在 all-providers.ts 注册、补齐环境变量登记 —— 与本 PR 完全一致，因此审查重点是核对细节，且均成立：

• 预设结构：所有字段均符合 ProviderConfig / ModelSpec / BaseUrlOption 类型；双端点 baseUrl 数组与 Z.AI 的 Standard/Coding-Plan 模式一致。
• K3 的 thinkingMandatory 是唯一不显然的论断，已完整追踪：管线对 enable_thinking: false / reasoning_effort: 'none' / chat_template_kwargs 禁用形状的剥离明确不限模型与主机（代码注释：thinkingMandatory "stays ungated … model-agnostic by design"），有端到端测试确保禁用形状绝不发往 thinking 强制模型，运行时错误学习重试是第二道保险。该标志已在 Token Plan 模型上生产使用，buildGenerationConfig 对 spec 字段的映射与新测试断言一致（K3 完全不携带 extra_body —— 正确）。
• 模型元数据有仓内佐证：tokenLimits.ts 已将 kimi-k3 映射为 1M、kimi- 兜底为 256K，modalityDefaults.ts 将 kimi-k3 / kimi-k2.x 映射为图像+视频，Token Plan 中的 kimi-k2.7-code 数值完全相同（本 PR 为 k2.6 补上模态，与 modalityDefaults 一致 —— 过期的是 Token Plan 条目，而非本 PR）。
• 注册清单（来自注册表注释）完整：ci.yml 清空变量与 no-AK 固定断言列表（均按字母序）、遥测按环境变量与两个域名的映射，且各有测试。
• 测试有效：负向断言钉住可开关模型不带 thinkingMandatory、K3 不带 extra_body，凭据查找有不匹配负例，未知 ID 优雅回退。

无阻塞问题，无规范违规。未验证：/auth 对话框实际渲染（见下方通道）；未发起真实 Moonshot 请求 —— PR 本身亦如此说明，预设也没有可在此测试的付费凭据路径。

测试 —— 读取 PR 自身 CI（API）（无人值守运行，此处未执行任何 PR 代码）。安全与桌面检查已通过；ubuntu-latest 核心单测在本评论发出时仍在运行 —— 不轮询，finalize 任务会在 CI 落定后刷新下表。macOS/Windows 测试与无沙箱集成腿被 CI profile 门控跳过，这是 fork PR 的常见形态。

沙箱验证可以补齐剩余的表面论断：@qwen-code /verify —— Kimi 条目是否真实渲染于 /auth → Third-party Providers（现为九个条目 —— 是否有裁剪？）、端点与模型步骤是否端到端安装四个带钉住元数据的模型，这些无法从 diff 观察，且即使注册接线被切断本 PR 测试仍会通过。作者无写权限，因此这是一次赞助运行：维护者的 @qwen-code /verify 将批准其书写时的 head，运行带有执行前风险筛查与完整工作区清理 —— 其报告应与 fork 自身 CI 日志同样审慎看待。

— Qwen Code · qwen3.8-max

_{Reviewed at 5ca34b2f8eeea2b0dbdcf151c626ece88ea286d0 · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Confidence: 4/5 — a textbook provider preset that does exactly what the accepted issue asked; the one reservation is a merge-order call against an open sibling PR, which is a maintainer's to make, not a defect here.

Stepping back: this is the narrow slice #9197 asked for, implemented almost line-for-line along the sketch that issue-triage left there. I proposed the same approach independently before reading the diff — a USE_OPENAI declarative preset with a two-endpoint selector and per-model metadata — and the PR matches it, so there was no simpler path being missed. The one part with real teeth, K3's thinkingMandatory, checks out end to end: the pipeline's disable-shape strip is model-agnostic by design, there's an E2E test that a disable never ships to a thinking-mandatory model, and the flag is already live on Token Plan models. The catalog numbers aren't invented — they're corroborated by tokenLimits.ts, modalityDefaults.ts, and the Token Plan preset that already ships the same k2.7-code entry. Tests pin the metadata with real negative assertions rather than just snapshotting it.

The honest reservations, neither of which I think blocks: (1) #8368 is still open and ships this same provider inside a larger change — its MiMo half already landed separately, so this reads as the intended minimal slice, but the merge order is a human call and I've flagged it; (2) no live Moonshot request was made (no paid credential to test with), which is inherent to a preset — the install-plan and pipeline coverage is the substitute and it's solid. If I'm maintaining this in six months it's a flat data file that's trivial to update as Kimi's catalog moves, which is the right shape.

Approving, with the unit suite still in flight — the approval lands pinned to the reviewed commit once CI is green on it, not before.

中文说明

置信度：4/5 —— 一个教科书式的 provider 预设，恰好实现了已被接受的 issue 所要求的内容；唯一保留意见是与一个仍 open 的同源 PR 的合入顺序，那是维护者的决定，而非本 PR 的缺陷。

退一步看：这是 #9197 所要求的最小切片，几乎逐行沿着 issue 评审留下的要点实现。我在读 diff 之前独立提出了同样的方案 —— 带双端点选择与逐模型元数据的 USE_OPENAI 声明式预设 —— 本 PR 与之吻合，因此不存在被错过的更简路径。唯一有分量的部分，K3 的 thinkingMandatory，经端到端核实：管线对禁用形状的剥离按设计不限模型，有 E2E 测试确保禁用形状绝不发往 thinking 强制模型，且该标志已在 Token Plan 模型上生产使用。目录数值并非凭空 —— 有 tokenLimits.ts、modalityDefaults.ts 以及已包含同一 k2.7-code 条目的 Token Plan 预设佐证。测试以真实的负向断言钉住元数据，而非仅做快照。

两点诚实的保留意见，我认为均不阻塞：（1）#8368 仍 open，且在一个更大的改动中包含同一 provider —— 其 MiMo 部分已单独合入，因此本 PR 读起来正是预期的最小切片，但合入顺序是人类决定，我已标记；（2）未发起真实 Moonshot 请求（无付费凭据可测），这是预设类改动的固有情况 —— install-plan 与管线覆盖是其替代，且扎实。若六个月后由我维护，这是一个随 Kimi 目录演进而极易更新的扁平数据文件，形态正确。

予以批准；鉴于单元测试仍在进行，批准将在 CI 于被审提交上转绿后、钉住该提交落地，而非在此之前。

— Qwen Code · qwen3.8-max

_{Reviewed at 5ca34b2f8eeea2b0dbdcf151c626ece88ea286d0 · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

LGTM, looks ready to ship — CI landed green after the review. ✅

[qwen-code-ci-bot]

No issues found. LGTM! ✅

Not linted (tool limitation, not a blocker): the executable-script lint — .github/workflows/ci.yml: actionlint embedded-shell source mapping is not yet supported — not linted.

中文说明

未发现问题。LGTM！✅

未检查（工具限制，非阻断）：the executable-script lint — .github/workflows/ci.yml: actionlint embedded-shell source mapping is not yet supported — not linted。

— qwen3.8-max via Qwen Code /review (v0.22.0)

[pomelo-nwu]

lgtm

[qwen-code-ci-bot]

Released in v0.22.2.