Kimi 开放平台(Moonshot AI)现在允许你直接把原本走 OpenAI 兼容接口和 Anthropic 兼容接口的工具,原生化地指向 Kimi 模型,而不必自己写代理、转译或做薄封装层。对已经重度使用 Codex 与 Claude Code 的团队来说,这意味着可以用远低于美国前沿模型的价格,把一条强编码、长上下文的国产模型链路直接塞进现有的 agent 工作流。本文是一份可执行的 SOP:前半讲两条接入路径的 base_url 与模型标识,后半讲配置片段、最小验证步骤和踩坑清单。为什么一条便宜且足够强的编码模型值得认真对待,横向比较见旗舰级编码与推理模型横评;Kimi 的权重开源动态见Kimi K3 权重开源。
一、两条路径的本质区别
Kimi 开放平台同时提供了两种兼容端点,分别对应两款工具的底层协议:
- OpenAI Responses API 路径 —— 给 Codex 用。Codex 的底层请求是 OpenAI 风格的 Responses 或 Chat 调用,把它指向
https://api.moonshot.cn/v1即可,平台会在后端把请求翻译给 Kimi 模型。 - Anthropic Messages API 路径 —— 给 Claude Code 用。Claude Code 的底层是 Anthropic 风格的 Messages 调用,把它指向
https://api.moonshot.cn/anthropic即可,平台会模拟 Anthropic 端点,让 Claude Code 在完全无感的情况下把流量打到 Kimi。
两条路径不是"二选一",而是"各管各的工具"。同一把 Kimi API Key 可以同时喂给 Codex 和 Claude Code,但配置要分别写进各自的配置文件。下面的表格先对齐对象:
值得强调的是,这种"原生接入"和自己在本地起一个 OpenAI 兼容代理有本质区别。代理方案要你维护一份转发服务、自己处理鉴权与错误重试,而平台端点把这些都在服务端做掉了。你得到的不是一层需要你运维的薄封装,而是直接可用的双协议兼容。对中小团队来说,省掉的恰恰是最容易被低估的运维成本,以及代理本身引入的那一跳额外延迟。
| 工具 | 协议 | base_url | 配置文件 |
|---|---|---|---|
| Codex | OpenAI Responses API | https://api.moonshot.cn/v1 | ~/.codex/config.toml |
| Claude Code | Anthropic Messages API | https://api.moonshot.cn/anthropic | ~/.claude/settings.json |
二、可接入的模型清单
通过这两条路径能拿到的 Kimi 模型如下,注意它们各自的上下文与行为差异:
kimi-k3:1M 上下文的长上下文主力,适合大仓库、长会话与多文档检索类任务。kimi-k2.7-code:256K 上下文,强制思考(forced thinking),偏编码专项,会在推理前先展开思考链。kimi-k2.7-code-highspeed:256K 上下文的高速变体,牺牲一点质量换吞吐,适合大批量低延迟场景。kimi-k2.6:上一档稳定模型,作为降级或对照用。
一个容易忽略的点:kimi-k2.7-code 走的是强制思考模式,也就是说它每次响应都会先产出思考链,再给结果。这对编码任务通常是好事,但如果你想把它当纯补全接口高频调用,要预留思考链带来的额外延迟与 token 开销。
选型上没有标准答案:追求质量上限优先 kimi-k3;纯编码且希望模型先想清楚再写,选 kimi-k2.7-code;同质量但嫌慢,换 kimi-k2.7-code-highspeed;需要稳定对照再留 kimi-k2.6 做 A/B。把模型标识放进配置而不是硬编码进业务代码,切换与回滚都只改配置、不发版。
三、Step 1:拿到 Kimi API Key
到 Moonshot 开放平台控制台(Kimi Open Platform console)注册并创建 API Key。这一步没有任何代理或中转,Key 是平台直接签发的,请按密钥级别保管,不要在仓库、日志或前端代码里硬编码。建议把 Key 放进环境变量或密钥管理,再用配置文件引用变量名,而不是把明文写进 config.toml 或 settings.json。
如果你所在团队有配额分级(tiered),不同 Key 的调用上限不同。具体分级与你在控制台的可见额度请以平台控制台为准,本文不臆造确切数字。
四、Step 2:Codex 接入(Responses API)
编辑 ~/.codex/config.toml,把 Kimi 的 Key 与协议接法写进去。关键两项是 KIMI_API_KEY 和 wire_api = "responses"。下面是一段可直接套用的 TOML:
# ~/.codex/config.toml
[env]
KIMI_API_KEY = "sk-kimi-xxxxxxxxxxxxxxxx"
[model]
# 指向 Kimi 开放平台的 OpenAI 兼容端点
base_url = "https://api.moonshot.cn/v1"
# 使用 Responses API 接法
wire_api = "responses"
# 模型标识
model = "kimi-k3"保存后,Codex 的所有底层请求就会改走 Kimi 的 Responses 端点。注意 wire_api 必须是字符串 "responses",写错类型会导致配置不生效。
五、Step 3:Claude Code 接入(Anthropic Messages API)
编辑 ~/.claude/settings.json,在 env 块里写入三个变量:ANTHROPIC_BASE_URL 指向 Kimi 的 Anthropic 兼容端点,ANTHROPIC_AUTH_TOKEN 填你的 Kimi API Key,ANTHROPIC_MODEL 填 kimi-k3[1m]。下面是一段可直接套用的 JSON:
{
"env": {
"ANTHROPIC_BASE_URL": "https://api.moonshot.cn/anthropic",
"ANTHROPIC_AUTH_TOKEN": "sk-kimi-xxxxxxxxxxxxxxxx",
"ANTHROPIC_MODEL": "kimi-k3[1m]"
}
}这里的 [1m] 后缀不是装饰:它显式声明使用 1M 上下文版本。如果只写 kimi-k3 而不带 [1m],平台可能回落到默认上下文窗口。Claude Code 的 UX(命令、权限、子代理、文件编辑交互)完全保留,只是底层模型换成了 Kimi。
六、Step 4:先做一次最小验证
在把整个 agent 工作流指向 Kimi 之前,务必先做一个不依赖任何工具、不依赖长上下文的最小调用:让模型原样回显一个字符串。目的是确认三件事——Key 有效、base_url 可达、模型标识被正确解析。任何一个环节写错,都会让后续一大串"看起来在跑但其实静默失败"的 agent 调用难以排查。
一个典型的静默失败长这样:Codex 报了某个工具调用错误,但根因其实是 base_url 拼错导致请求没真正到达 Kimi,或者模型标识写错让平台回了一个默认模型、上下文窗口比预期小,于是长文件被截断、agent 在错误的上下文里反复重试。最小验证把这类问题压缩到一行 echo,定位成本从"翻几小时 agent 日志"降到"看一眼回显对不对"。
验证建议:用最简单的 echo 提示词,观察返回是否就是输入字符串本身;再换一个长一点的提示词确认思考链或普通回复形态符合预期。只有最小验证通过,才把完整 agent(带工具、带多轮、带长上下文)切过去。这与旗舰级编码与推理模型横评里强调的"先小范围验证再放量"是一致的工程纪律。
七、避坑清单
- Responses API 暂不支持视频输入:走 OpenAI Responses 路径时,视频类输入目前不在支持范围内。如果你的 Codex 任务会带视频帧或视频文件,先确认平台是否已放开,否则要回退到其他模型或预处理成文本。
[1m]后缀不能省:Claude Code 路径里ANTHROPIC_MODEL必须带[1m]才能拿到 1M 上下文,漏写会回落默认窗口,长仓库任务会悄悄截断。kimi-k2.7-code强制思考:它每次都先走思考链,带来额外延迟和 token 成本。对延迟敏感的高频调用,考虑kimi-k2.7-code-highspeed。- Key 明文风险:不要把 API Key 直接写进会被提交的文件。用环境变量或密钥管理,配置里只放引用。
- 配额是分级的:速率限制(rate limit)为分级制,具体额度以平台控制台显示为准,本文不给出确切数字。上线前先在控制台核对你的档位,避免生产流量被限流。
- 两条路径各自独立:Codex 和 Claude Code 的配置互不影响,改动一处不会自动同步另一处,迁移时要两份都核对。
以上六条里,前两条(视频限制、[1m] 后缀)最容易导致"配置看起来对、跑起来却不对"的假象,迁移时优先核对这两项,再放手跑完整任务。
八、成本与适用场景
Kimi 开放平台的价格显著低于美国前沿模型,具体费率以 Kimi 定价页为准(确切数字本文未确认)。对成本敏感、且任务以编码和多文档理解为重的中长尾场景,把 Codex 与 Claude Code 接入 Kimi,可以把每条 agent 调用的单位成本压低一个数量级级别,而质量在大多数日常编码任务上仍然够用。
这正好呼应了Kimi K3 权重开源里讨论的"强模型平民化"趋势,也和旗舰级编码与推理模型横评中"便宜的强编码模型为什么重要"的结论一致。顺带一提,横向对比里也常出现Gemini 3.8 Flash 热点这类轻量高速选项,可作为另一条低成本支线评估。
需要明确一个边界:便宜不等于无脑替换。kimi-k3 在多数日常编码任务上够用,但在最难的算法题、对长链推理一致性要求极高的场景,与美国前沿模型仍有差距;这部分差距是否值得用成本去换,要按你的任务分布来算。一个务实的折中是按任务路由:日常脚手架、样板代码、文档生成、批量小修小补走 Kimi,真正硬核的推理片段保留前沿模型。这样既吃到成本红利,又不牺牲关键路径的质量。配额上的速率限制为分级制,确切数字以控制台显示为准,本文未确认。
九、一页速查表
| 项目 | Codex 路径 | Claude Code 路径 |
|---|---|---|
| 协议 | OpenAI Responses API | Anthropic Messages API |
| base_url | https://api.moonshot.cn/v1 | https://api.moonshot.cn/anthropic |
| 配置文件 | ~/.codex/config.toml | ~/.claude/settings.json |
| 关键变量 | KIMI_API_KEY, wire_api="responses" | ANTHROPIC_BASE_URL, ANTHROPIC_AUTH_TOKEN, ANTHROPIC_MODEL |
| 模型标识 | kimi-k3 等 | kimi-k3[1m] |
| 已知限制 | Responses API 暂不支持视频输入 | [1m] 后缀决定上下文窗口 |
参考来源
- Kimi 开放平台(Moonshot AI)官方文档:OpenAI 兼容端点
https://api.moonshot.cn/v1、Anthropic 兼容端点https://api.moonshot.cn/anthropic、模型标识(kimi-k3 / kimi-k2.7-code / kimi-k2.7-code-highspeed / kimi-k2.6)、kimi-k2.7-code强制思考与 256K 上下文、kimi-k3 的 1M 上下文与[1m]后缀约定。具体文档 URL 未确认。 - Kimi 开放平台控制台:API Key 签发、配额分级(tiered)、速率限制(rate limit)具体额度。确切数字以控制台显示为准,本文未确认。
- Kimi 定价页:单位价格显著低于美国前沿模型。具体费率未确认,请以官方定价页为准。
- Codex 配置文件约定(
~/.codex/config.toml的env/model段与wire_api字段)、Claude Code 配置文件约定(~/.claude/settings.json的env块与ANTHROPIC_*变量名),属工具本身的配置惯例,参数名以各工具当前版本为准。
常见问题
Q1:用 Claude Code 接 Kimi 需要改哪几个配置?
A1:只改 ~/.claude/settings.json 里的 env 块,写三个变量:ANTHROPIC_BASE_URL 设为 https://api.moonshot.cn/anthropic,ANTHROPIC_AUTH_TOKEN 填你的 Kimi API Key,ANTHROPIC_MODEL 填 kimi-k3[1m]。Claude Code 的交互界面、权限、子代理都不用动,改完底层流量就走 Kimi 了。
Q2:Codex 和 Claude Code 两条路 base_url 各是什么?
A2:Codex 走 OpenAI Responses 路径,base_url 是 https://api.moonshot.cn/v1;Claude Code 走 Anthropic Messages 路径,base_url 是 https://api.moonshot.cn/anthropic。两者是平台提供的两个不同兼容端点,分别对应两款工具的底层协议,不要互相混用。
Q3:kimi-k3[1m] 里的 [1m] 是什么意思?
A3:[1m] 是模型标识的后缀,显式声明使用 1M(一百万 token)上下文版本。如果不带这个后缀只写 kimi-k3,平台可能回落到默认上下文窗口,处理大仓库或长会话时会被悄悄截断。因此 Claude Code 路径里务必保留 [1m]。
Q4:Responses API 目前有什么限制? A4:已知的主要限制是 Responses API 路径(即 Codex 所用的 OpenAI 兼容端点)暂不支持视频输入。如果你的任务会带视频帧或视频文件,需要先确认平台是否已放开该能力,否则应回退到其他模型或把视频预处理成文本再传入。其他模态与能力以平台文档为准。
Q5:接完怎么验证能不能用? A5:先做最小验证:用最简单的提示词让模型原样回显一个字符串,确认 Key 有效、base_url 可达、模型标识被正确解析。再换一个稍长的提示词确认回复形态符合预期。只有最小验证通过,才把完整的、带工具和长上下文的 agent 工作流切到 Kimi,避免一上来就跑大任务却静默失败。