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，避免一上来就跑大任务却静默失败。