feat(auth): add Kimi (Moonshot AI) as a built-in third-party provider - #9756
feat(auth): add Kimi (Moonshot AI) as a built-in third-party provider#9756TianYuan1024 wants to merge 3 commits into
Conversation
Adds a Moonshot preset to the /auth Third-party Providers menu, offering the international and China API endpoints and seeding the current Kimi model catalog. Moonshot speaks the OpenAI protocol, so this is a declarative preset with no new mechanism. K3 is registered as thinking-mandatory: the API exposes reasoning_effort but no way to turn thinking off, so a disable shape must never reach the wire. K2.6 stays text-only, matching the modality metadata the Token Plan and Idealab presets already carry for that model. Registers the new credential env key everywhere a provider key has to appear: the no-AK CI gate and its pinned assertion list, and the telemetry provider mapping (by env key and by hostname). Closes QwenLM#9197
|
Thanks for the PR! Template: complete ✓ — all required sections present, including the reviewer test plan and the Chinese summary. Problem: real user request, not theoretical. The linked issue #9197 is open and triaged ( Direction: aligned with the provider-ecosystem direction — this is a gap in the Third-party Providers menu, not a solution looking for a problem. But this is where I have to stop and hand over, for two reasons:
Size: core paths touched ( Approach: from a skim of the diff, this is a declarative preset in the established shape — endpoint choice via the Risk: no changed file matches the revert-correlated high-risk paths. No elevated risk signals. ⏸️ Escalating to @wenshao for the direction call before anyone spends time on code review: land this slice now, or hold for #8368? This escalation is not a quality judgment — the diff follows the established preset pattern and nothing in it raises a concern. A maintainer re-run of 中文说明感谢贡献！ 模板： 完整 ✓ —— 所有必需章节齐全，包含 Reviewer 测试计划与中文说明。 问题： 真实用户需求，非理论性问题。关联 issue #9197 处于 open 状态且已完成分类（ 方向： 与 provider 生态方向一致 —— 这是 Third-party Providers 菜单的真实空缺，而非"为方案找问题"。但我需要在此停下并转交维护者，原因有二：
规模： 触及核心路径（ 方案： 从 diff 结构看，这是一个遵循既有形态的声明式预设 —— 通过 风险： 无改动文件命中与 revert 相关的高风险路径。无升级风险信号。 ⏸️ 转交 @wenshao 做方向决策，之后再投入代码评审：是先落地这个切片，还是等待 #8368？此转交并非质量评判 —— diff 遵循既有预设模式，未发现问题。维护者重新触发 — Qwen Code · qwen3.8-max Reviewed at |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Reviewed — no blockers. Suggestions are inline.
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.
中文说明
已审查——无阻断问题。 建议见行内评论。
未检查（工具限制，非阻断）：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)
|
|
||
| - **Alibaba ModelStudio**: official recommended setup. Opens a sub-menu with **Coding Plan** (for individual developers · weekly quota included), **Token Plan** (for teams and companies · usage-based billing with a dedicated endpoint), or **Standard API Key** (connect with an existing ModelStudio API key). | ||
| - **Third-party Providers**: choose a built-in provider and connect with an API key (DeepSeek, MiniMax, Z.AI, Idealab, ModelScope, OpenRouter, Requesty). | ||
| - **Third-party Providers**: choose a built-in provider and connect with an API key (DeepSeek, Grok, MiniMax, Z.AI, Kimi, Idealab, ModelScope, OpenRouter, Requesty). |
There was a problem hiding this comment.
[Suggestion] This PR adds Kimi to two provider lists (this one and the one in docs/users/overview.md) but not to the third sibling list at docs/users/quickstart.md:75 — "choose a built-in provider (DeepSeek, MiniMax, Z.AI, ModelScope, OpenRouter, Requesty, and more)" — so immediately after this change ships a built-in Kimi, the three first-run docs disagree about which providers are built in. The quickstart list is explicitly non-exhaustive ("and more") and already omitted Grok and Idealab before this PR, so leaving it as a summary is defensible — but syncing it would fix every stale entry at once. If the list is meant to track the registry, update it to (DeepSeek, Grok, MiniMax, Z.AI, Kimi, Idealab, ModelScope, OpenRouter, Requesty, and more).
中文说明
本 PR 在两处 provider 列表（此处的 auth.md 与 docs/users/overview.md）中加入了 Kimi，但第三处同类列表 docs/users/quickstart.md:75 —— "choose a built-in provider (DeepSeek, MiniMax, Z.AI, ModelScope, OpenRouter, Requesty, and more)" —— 未同步，导致本改动上线后三个入门文档对内置 provider 的口径不一致。quickstart 的列表本身是非穷举的（"and more"），且在本 PR 之前就已缺少 Grok 与 Idealab，因此维持现状作为摘要也说得通；但若同步一次，可以一并修复所有过期条目。若该列表意在跟随注册表，可更新为 (DeepSeek, Grok, MiniMax, Z.AI, Kimi, Idealab, ModelScope, OpenRouter, Requesty, and more)。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
Agreed and synced in e9d712f. The list now reads (DeepSeek, Grok, MiniMax, Z.AI, Kimi, Idealab, ModelScope, OpenRouter, Requesty, and more), so all three first-run docs now name the same set. As you noted, that also clears the Grok and Idealab entries that were already stale before this branch.
中文说明
同意，已在 e9d712f 同步。该列表现为 (DeepSeek, Grok, MiniMax, Z.AI, Kimi, Idealab, ModelScope, OpenRouter, Requesty, and more)，三处入门文档口径已一致。正如你指出的，这同时修正了本分支之前就已过期的 Grok 与 Idealab 条目。
| const plan = buildInstallPlan(moonshotProvider, { | ||
| baseUrl: INTL_BASE_URL, | ||
| apiKey: 'sk-moonshot', | ||
| modelIds: ['kimi-k3', 'kimi-k2.7-code', 'kimi-k2.6'], |
There was a problem hiding this comment.
[Suggestion] The fourth preset model, kimi-k2.7-code-highspeed (packages/core/src/providers/presets/moonshot.ts:45-50), is exercised by no test — the ID appears exactly once in the whole tree, in the preset itself. Mutation probe: changing highspeed's contextWindowSize to 999999 and dropping enableThinking/modalities leaves this suite green (6/6 pass), while the identical mutation on the tested kimi-k2.6 entry turns it red (1 failed | 5 passed) — so the entry can be deleted or corrupted without CI noticing. Since getDefaultModelIds returns all four models and feeds the default-install paths, a default Kimi install would then silently ship a model with a wrong context window or a missing enable_thinking: true on the wire. Add 'kimi-k2.7-code-highspeed' to modelIds (updating toHaveLength(3) accordingly) and assert its generationConfig — contextWindowSize: 262144, extra_body: { enable_thinking: true }, modalities: { image: true, video: true } — mirroring the k2.7-code assertions.
中文说明
第四个预设模型 kimi-k2.7-code-highspeed（packages/core/src/providers/presets/moonshot.ts:45-50）没有任何测试覆盖 —— 该 ID 在整个代码树中仅出现一次，就在预设本身。变异探针：把 highspeed 的 contextWindowSize 改为 999999 并删掉 enableThinking/modalities，本测试套件仍然全绿（6/6 通过）；而对已有测试覆盖的 kimi-k2.6 条目做同样的变异则会变红（1 failed | 5 passed）—— 也就是说，直接删除或破坏这个条目，CI 也不会发现。由于 getDefaultModelIds 会返回全部四个模型并供默认安装路径使用，默认安装 Kimi 时可能会悄然带上一个上下文窗口错误、或链路上缺少 enable_thinking: true 的模型。建议将 'kimi-k2.7-code-highspeed' 加入 modelIds（同步把 toHaveLength(3) 改为 4），并仿照 k2.7-code 的断言，校验其 generationConfig —— contextWindowSize: 262144、extra_body: { enable_thinking: true }、modalities: { image: true, video: true }。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
Good catch, and the mutation probe made it concrete — fixed in e9d712f. The highspeed entry now goes through buildInstallPlan with the same assertions as its sibling (contextWindowSize: 262144, extra_body: { enable_thinking: true }, modalities: { image: true, video: true }), and toHaveLength is 4.
I re-ran your probe against the fix to confirm it bites: setting highspeed's contextWindowSize to 999999 and dropping enableThinking/modalities now fails the suite (1 failed | 5 passed) where it previously stayed green at 6/6. Restored, the suite is 6/6.
中文说明
指出得好，变异探针也让问题很具体 —— 已在 e9d712f 修复。highspeed 条目现在与其同族模型一样走 buildInstallPlan 并使用相同断言（contextWindowSize: 262144、extra_body: { enable_thinking: true }、modalities: { image: true, video: true }），toHaveLength 改为 4。
我用你的探针对修复做了回验以确认其确实生效：将 highspeed 的 contextWindowSize 改为 999999 并删除 enableThinking/modalities 后，测试套件现在会失败（1 failed | 5 passed），而此前维持全绿 6/6。恢复原状后套件为 6/6。
…dent TianYuan1024's review of the QwenLM#9756 scope split flagged that K2.6 should be text-only, matching what QwenLM#5328 deliberately set for the same model id in the Token Plan and Idealab presets (alibaba-token-plan.ts / idealab.ts both leave kimi-k2.6 without modalities). The Kimi API preset instead granted image + video, and the kimi-k2.x heuristic in modalityDefaults re-filled any path that resolved without an explicit field. - Drop modalities from the kimi-k2.6 API preset entry - Add a specific kimi-k2.6 -> {} heuristic rule ahead of the multimodal kimi-k2.x rule, so every fill path stays text-only - Pin the heuristic and preset expectations with tests K3 is already registered thinking-mandatory (its API exposes reasoning_effort but offers no way to disable thinking), matching the other review note.
…t list Review round 1 on QwenLM#9756 raised two suggestions, both addressed here. The highspeed code model was declared in the preset but asserted nowhere, so its metadata could be corrupted or the entry deleted without CI noticing — and since the default install path ships every preset model, that would silently install a wrong context window or drop the thinking flag from the wire. It now goes through the install plan alongside its sibling with the same assertions; the reviewer's mutation probe turns the suite red instead of green. The quickstart's provider list was the one first-run doc left unsynced, which would have made the three of them disagree about what ships built in. It now matches the registry, picking up the entries that were already stale before this branch.
…t list Review round 1 on QwenLM#9756 raised two suggestions, both addressed here. The highspeed code model was declared in the preset but asserted nowhere, so its metadata could be corrupted or the entry deleted without CI noticing — and since the default install path ships every preset model, that would silently install a wrong context window or drop the thinking flag from the wire. It now goes through the install plan alongside its sibling with the same assertions; the reviewer's mutation probe turns the suite red instead of green. The quickstart's provider list was the one first-run doc left unsynced, which would have made the three of them disagree about what ships built in. It now matches the registry, picking up the entries that were already stale before this branch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011wsovL36fX2Y6ptLKFWJXw
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Reviewed. Suggestions are inline.
中文说明
已审查。 建议见行内评论。
— qwen3.8-max via Qwen Code /review (v0.22.0)
| expect(models?.[2]).toMatchObject({ | ||
| id: 'kimi-k2.7-code-highspeed', | ||
| name: '[Kimi] kimi-k2.7-code-highspeed', |
There was a problem hiding this comment.
[Suggestion] The new kimi-k2.7-code-highspeed assertion uses a partial toMatchObject and never pins the absence of thinkingMandatory — unlike the K3 block above, which pins extra_body as toBeUndefined(). Mutation probe: adding thinkingMandatory: true to the highspeed spec in presets/moonshot.ts survives the whole test file (all 6 tests still pass). The mutant is not equivalent: thinkingMandatory changes wire behaviour — pipeline.ts strips the thinking-disable shape (enable_thinking: false, reasoning_effort: 'none') for such models. So if a future edit marks kimi-k2.7-code-highspeed (or kimi-k2.7-code, whose block has the same shape) as thinking-mandatory, buildGenerationConfig would emit thinkingMandatory: true, the pipeline would silently stop shipping the thinking-disable shape on the wire, users would lose the ability to turn thinking off on a toggleable model, and this test would stay green.
Witness (mutation run in a scratch tree, npx vitest run src/providers/__tests__/presets/moonshot.test.ts):
baseline (unmodified PR): Tests 6 passed (6)
mutant (thinkingMandatory: true): Tests 6 passed (6) <- survives
mutant + negative assertion: AssertionError: expected true to be undefined -> 1 failed | 5 passed
Mirror the K3 negative assertion — after the highspeed block closes, add:
expect(models?.[2]?.generationConfig?.thinkingMandatory).toBeUndefined();(optionally the same for models?.[1]).
中文说明
新增的 kimi-k2.7-code-highspeed 断言使用了部分的 toMatchObject，没有钉住 thinkingMandatory 的缺席——不像上面的 K3 断言那样把 extra_body 钉为 toBeUndefined()。变异探测证实：在 presets/moonshot.ts 的 highspeed 规格中加入 thinkingMandatory: true 后，整个测试文件仍然全部通过（6/6）。该变异体并非等价变异：thinkingMandatory 会改变线上行为——pipeline.ts 会为此类模型剥离关闭 thinking 的请求形状（enable_thinking: false、reasoning_effort: 'none'）。因此，如果未来某次修改把 kimi-k2.7-code-highspeed（或断言形状相同的 kimi-k2.7-code）标记为强制 thinking，buildGenerationConfig 会输出 thinkingMandatory: true，管线会悄然在线上剥离关闭 thinking 的形状，用户将无法在可开关 thinking 的模型上关闭它，而该测试依然绿灯。
见证（在临时树中运行变异，npx vitest run src/providers/__tests__/presets/moonshot.test.ts）：基线（未修改的 PR）Tests 6 passed (6)；变异（加入 thinkingMandatory: true）Tests 6 passed (6)，变异存活；变异 + 负向断言 AssertionError: expected true to be undefined，1 failed | 5 passed。
建议参照 K3 的负向断言——在 highspeed 断言块结束后补充 expect(models?.[2]?.generationConfig?.thinkingMandatory).toBeUndefined();（也可同样为 models?.[1] 补充）。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
Agreed — fixed in 03b9651. Added expect(models?.[N]?.generationConfig?.thinkingMandatory).toBeUndefined(); after both code-model blocks, not just highspeed, since as you noted kimi-k2.7-code had the identical shape.
Re-ran your probe against the fix: adding thinkingMandatory: true to the highspeed spec now gives 1 failed | 5 passed where it previously survived at 6/6.
中文说明
同意，已在 03b9651 修复。在两个代码模型断言块之后都补充了 expect(models?.[N]?.generationConfig?.thinkingMandatory).toBeUndefined();，而不只是 highspeed —— 正如你指出的，kimi-k2.7-code 的断言形状完全相同。
已用你的探针回验：向 highspeed 规格加入 thinkingMandatory: true 后现在为 1 failed | 5 passed，此前该变异以 6/6 存活。
| // K2.6 is text-only, matching modalityDefaults for that ID. | ||
| expect(models?.[3]).toMatchObject({ | ||
| id: 'kimi-k2.6', |
There was a problem hiding this comment.
[Suggestion] This comment states an invariant that does not hold: modalityDefaults.ts maps /^kimi-k2\./ to { image: true, video: true } (first-match-wins, ahead of the text-only /^kimi-/ catch-all), and modelConfigResolver.ts applies defaultModalities(modelId) whenever the installed config's modalities is undefined — exactly the shape this test asserts for k2.6. A probe driving this PR's own buildInstallPlan output into the real resolveModelConfig confirms an installed kimi-k2.6 resolves to image+video-capable at runtime:
installed.generationConfig.modalities=undefined
resolved.config.modalities={"image":true,"video":true}
defaultModalities(kimi-k2.6)={"image":true,"video":true}
That is the opposite of "text-only", so omitting modalities in the preset does not achieve text-only at runtime. If k2.6 really is text-only, the curated install path this PR adds lets users attach images/video to a text-only model — the unrecoverable API error modalityDefaults' own doc comment warns about — and the missing piece is a narrower entry (e.g. [/^kimi-k2\.6/, {}] before the /^kimi-k2\./ rule in modalityDefaults.ts) or an explicit modalities: {} in the preset. If k2.6 is actually multimodal, the comment is still false and will misdirect the next maintainer who edits either table. Could you confirm k2.6's real capability and make the code and comment agree?
中文说明
这条注释声明了一个不成立的不变量：modalityDefaults.ts 将 /^kimi-k2\./ 映射为 { image: true, video: true }（首次匹配生效，排在纯文本的 /^kimi-/ 兜底规则之前），而 modelConfigResolver.ts 会在已安装配置的 modalities 为 undefined 时应用 defaultModalities(modelId)——这正是本测试为 k2.6 断言的形状。探针将本 PR 自己的 buildInstallPlan 输出喂给真实的 resolveModelConfig，确认安装后的 kimi-k2.6 在运行时解析为支持图像+视频：installed.generationConfig.modalities=undefined，resolved.config.modalities={"image":true,"video":true}，defaultModalities(kimi-k2.6)={"image":true,"video":true}。
这与"纯文本"相反，因此预设中省略 modalities 并不能在运行时达成纯文本。如果 k2.6 确实是纯文本模型，本 PR 新增的引导式安装路径会允许用户向纯文本模型附加图像/视频——正是 modalityDefaults 自身文档注释所警告的不可恢复 API 错误——缺失的是一条更窄的规则（例如在 modalityDefaults.ts 的 /^kimi-k2\./ 规则之前加入 [/^kimi-k2\.6/, {}]），或在预设中显式写入 modalities: {}。如果 k2.6 实际是多模态的，这条注释依然是错的，会误导下一个编辑这两张表的维护者。请确认 k2.6 的真实能力，并让代码与注释保持一致。
— qwen3.8-max via Qwen Code /review (v0.22.0)
There was a problem hiding this comment.
You're right, and the conclusion is that K2.6 is multimodal — my comment was simply wrong. Fixed in 03b9651: the preset now declares modalities: { image: true, video: true } for K2.6 and the false comment is gone.
Moonshot's own docs settle it. The K2.6 guide states "It supports text, image, and video input, thinking and non-thinking modes, and dialogue and Agent tasks," and ships working image-understanding and video-understanding examples; the model list describes K2.6 as supporting visual and text input.
Worth recording why the original reasoning was wrong, since it could mislead someone again: I cited #5328 as precedent for text-only, but that change only dropped a redundant modalities field from the Token Plan and Idealab entries. Because the resolver fills modalities from modalityDefaults whenever the installed config omits them, and that table already maps /^kimi-k2\./ to image+video, the omission never produced a text-only model at runtime — exactly as your probe demonstrates. So #5328 never established text-only for K2.6; there was no precedent to follow.
I've declared the modalities explicitly rather than relying on the heuristic, so the preset states the capability directly instead of depending on a table that may be retuned for other members of the family. Your probe now bites: dropping modalities from the K2.6 entry gives 1 failed | 5 passed.
I've also flagged this on #8368 — an earlier note from me led that PR to add a [/^kimi-k2\.6/, {}] rule to modalityDefaults.ts, which on this evidence would be a regression.
中文说明
你是对的，结论是 K2.6 支持多模态 —— 我的注释就是错的。已在 03b9651 修复：预设现在为 K2.6 显式声明 modalities: { image: true, video: true }，错误注释已删除。
Moonshot 官方文档可以定论。K2.6 指南写明"It supports text, image, and video input, thinking and non-thinking modes, and dialogue and Agent tasks"，并提供了可运行的图像理解与视频理解示例；模型列表也将 K2.6 描述为支持视觉与文本输入。
有必要记录原推理错在哪里，以免再次误导他人：我把 #5328 当作纯文本的先例，但那次改动只是从 Token Plan 与 Idealab 条目中删除了冗余的 modalities 字段。由于已安装配置省略该字段时解析器会从 modalityDefaults 填充，而该表已将 /^kimi-k2\./ 映射为图像+视频，因此这一省略在运行时从未产生纯文本模型 —— 正如你的探针所证明的。所以 #5328 从未为 K2.6 确立纯文本口径，也就不存在可循的先例。
我选择显式声明模态而非依赖启发式规则，这样预设直接陈述能力，而不依赖一张可能因该家族其他成员而被调整的表。你的探针现在能生效：从 K2.6 条目中删除 modalities 会得到 1 failed | 5 passed。
我也已在 #8368 提示此事 —— 我此前的一条留言导致该 PR 在 modalityDefaults.ts 中加入了 [/^kimi-k2\.6/, {}] 规则，依据现有证据这会造成回归。
…data Review round 2 on QwenLM#9756 caught that the text-only claim for K2.6 was wrong, and checking Moonshot's own documentation confirms it: the K2.6 guide states the model supports text, image, and video input, and ships working image and video examples. The earlier reasoning leaned on QwenLM#5328 as precedent, but that change only dropped a redundant field from two Alibaba-hosted entries. Because the resolver fills modalities from the shared heuristic table whenever the installed config omits them, and that table already treats the K2.x family as multimodal, the omission never produced a text-only model at runtime. There was no precedent to follow. K2.6 now declares image and video explicitly, so the preset states the capability rather than leaning on a heuristic that could be retuned for other members of the family. Also pins the absence of the thinking-mandatory flag on both code models. Only K3 rejects a thinking-disable shape; marking a toggleable model that way would silently stop the disable from reaching the wire and take away the user's ability to turn thinking off, which the previous assertions would not have caught.
…data Review round 2 on QwenLM#9756 caught that the text-only claim for K2.6 was wrong, and checking Moonshot's own documentation confirms it: the K2.6 guide states the model supports text, image, and video input, and ships working image and video examples. The earlier reasoning leaned on QwenLM#5328 as precedent, but that change only dropped a redundant field from two Alibaba-hosted entries. Because the resolver fills modalities from the shared heuristic table whenever the installed config omits them, and that table already treats the K2.x family as multimodal, the omission never produced a text-only model at runtime. There was no precedent to follow. K2.6 now declares image and video explicitly, so the preset states the capability rather than leaning on a heuristic that could be retuned for other members of the family. Also pins the absence of the thinking-mandatory flag on both code models. Only K3 rejects a thinking-disable shape; marking a toggleable model that way would silently stop the disable from reaching the wire and take away the user's ability to turn thinking off, which the previous assertions would not have caught. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011wsovL36fX2Y6ptLKFWJXw
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Not reviewed: build-and-test — Integration Tests (CLI, No Sandbox) was skipped in CI and its suite did not run locally.
中文说明
未审查：build-and-test — Integration Tests (CLI, No Sandbox) was skipped in CI and its suite did not run locally。
— qwen3.8-max via Qwen Code /review (v0.22.0)
Reverts the text-only treatment from d768539, which was based on a since-corrected review note: K2.6 is multimodal per Moonshot's model docs (text, image, and video input; the K2.6 guide ships working image/video understanding examples), and the QwenLM#9756 reviewer's runtime probe confirmed the pre-existing resolution (undefined modalities -> {image, video}) was the correct behavior. The narrow text-only rule would have blocked legitimate image/video input across the Kimi API, Token Plan, and Idealab paths. - Drop the kimi-k2.6 rule from modalityDefaults.ts (the generic kimi-k2.x rule grants image + video) - Declare modalities explicitly on the kimi-k2.6 preset entry, stating capability rather than inheriting the heuristic (same approach as 03b9651) - Tests updated to pin the multimodal expectation
03b9651 to
c3e21ad
Compare
|
Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. 中文请勿对活跃的 PR 执行 rebase 或 force-push，因为这会使已有的评审评论失效。另外，供日后参考：作为集成流程的一部分，机器人始终会自动将所有改动压缩（squash）为单个提交。 |
|
Closing in favour of #9814, which is the same change resubmitted with a clean commit history. No review feedback is lost — both suggestions from this thread are incorporated there:
Thanks for both catches — the K2.6 one was a genuine error on my side, and the runtime probe is what made it unambiguous. 中文说明关闭本 PR，改由 #9814 承接 —— 同样的改动，以干净的提交历史重新提交。审查意见没有遗失，本线程的两条建议均已包含在新 PR 中：
感谢这两条意见 —— K2.6 那条确实是我这边的错误，运行时探针让问题变得毫无歧义。 |
2 participants
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 changes to the provider type. Two pieces of model metadata are worth calling out. K3 is registered as thinking-mandatory: 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, which would be a guaranteed failure. K2.6 is registered text-only, matching the modality metadata the Token Plan and Idealab presets already carry for that same model.
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 provider lists in the authentication and overview docs are updated to match the menu, which also picks up Grok, already shipping but missing from that list.
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
/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./modelthat 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:
The model step, reached after choosing an endpoint and entering a key:
Automated validation: the full core suite passes (20,856 tests; the one failure, an extension update-policy test, reproduces identically on a clean main and is unrelated). The provider and telemetry suites, the CI-gate guard test, lint, formatting, and the core typecheck all pass.
Tested on
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
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.
中文说明
这个 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"的形状，否则必然失败。K2.6 被标记为纯文本，与 Token Plan 和 Idealab 预设中同一模型已有的模态元数据保持一致。
新的凭据环境变量已在所有需要登记 provider key 的位置注册：在无凭据集成测试运行前清空 provider 凭据的 no-AK CI 门禁、防止该门禁被悄然改动的固定断言列表，以及遥测的 provider 映射 —— 同时覆盖环境变量与请求域名两条路径，使 Kimi 流量能被正确归因而非记为未知。认证与概览文档中的 provider 列表也同步更新，顺带补上了已经上线但未被列出的 Grok。
为什么需要
Kimi 是编码场景中较受欢迎的模型家族之一，Moonshot 的地位与 DeepSeek、MiniMax、Z.AI 相当，而后三者在 Third-party Providers 菜单中均已有一键入口。目前想使用 Kimi 的用户只能手动编辑配置或走 Custom Provider 流程，而同等热度的同行却有引导式配置。产品中已经通过阿里云各计划与 Idealab provider 承认了 Kimi 模型的存在，这让缺少一方 Moonshot 入口更像是一个明显的空缺，而非能力缺失。
Reviewer 测试计划
如何验证
/auth→ Third-party Providers。Kimi 应与其他直连 API 的 provider 一同出现在列表中，页脚仍然可见，且没有条目被裁剪。/model确认已安装条目的上下文长度符合预期。证据（Before & After）
Before： Kimi 在 Third-party Providers 中没有入口；接入 Moonshot 端点需要走 Custom Provider 或手改配置。
After： provider 列表与端点选择步骤，取自实际渲染的对话框（见上方英文正文中的两段终端输出）。模型步骤在选择端点并输入 key 后到达，四个推荐模型及其元数据同见上方英文正文。
自动化验证：core 全量测试通过（20,856 项；唯一失败的扩展更新策略测试在干净的 main 上同样复现，与本次改动无关）。provider 与遥测测试套件、CI 门禁守卫测试、lint、格式化以及 core 类型检查均通过。
测试环境
环境（可选）
macOS，Node.js 22，测试从各 package 目录执行；对话框证据通过无头渲染 auth 对话框获得，而非实际终端会话截图。
风险与范围
关联 Issue
Closes #9197
与 #8368 存在重叠：该 PR 在一个更大的改动中加入了同一 provider，同时还引入了第二个 provider、贯穿各端的 endpoint 级模型元数据，以及 provider 列表分页修复。本 PR 有意只做 issue 所要求的最小切片，并不试图取代那项工作；详见已在该 PR 中留下的说明。