Kimi API 原生兼容 Codex 与 Claude Code：开发者无需代理即可直连

月之暗面今天宣布，Kimi API 已原生支持 OpenAI Responses API 和 Anthropic Messages API 两套协议，开发者可以在 Codex 与 Claude Code 中直接配置 Kimi 模型，不再需要本地格式转换工具或第三方代理服务。

这次更新的核心不是又增加了一个模型入口，而是 Kimi 开始主动对齐主流编程 Agent 的原生协议。此前，开发者想让 Codex 或 Claude Code 使用 Kimi 模型，往往需要借助本地路由工具，把一种请求格式转换成另一种格式；现在，Kimi API 直接提供对应接口，接入链路明显缩短。

一句话看懂这次更新

Kimi API 是月之暗面面向开发者提供的模型调用服务；原生兼容意味着客户端可以按照自身熟悉的官方协议发起请求，而不需要额外改写请求和流式响应。

具体来说：

• Codex 使用 OpenAI 的 Responses API，可以通过 https://api.moonshot.cn/v1 作为 base_url 接入 Kimi。
• Claude Code 使用 Anthropic 的 Messages API，可以通过 https://api.moonshot.cn/anthropic 作为 base_url 接入 Kimi。
• 可选择的模型包括 kimi-k3、kimi-k2.7-code-highspeed、kimi-k2.7-code、kimi-k2.6 等。
• Codex CLI、Codex 桌面客户端以及 Claude Code 均可通过自定义模型提供商完成配置。

这里的“原生”需要准确理解：它不是说 Codex 或 Claude Code 已经把 Kimi 列为默认官方供应商，也不是说所有产品界面都会直接显示 Kimi，而是 Kimi 服务端已经提供了与这两套协议匹配的入口。

为什么协议兼容比“换一个模型地址”重要

API 协议是模型客户端与服务端之间约定请求结构、工具调用、流式输出和错误处理方式的一套规则。 对普通聊天应用来说，换一个兼容 OpenAI 格式的地址通常并不困难；但对 Codex 和 Claude Code 这种编程 Agent，协议差异会直接影响任务能否执行。

Codex 不只是把用户问题发送给模型。它还要让模型读取项目文件、调用终端、修改代码、返回中间状态，并在多轮交互中保留任务上下文。Responses API 围绕这一类 Agent 场景设计，支持文本、图片、工具调用以及结构化的响应事件。

Claude Code 也不是一个简单的聊天窗口。它依赖 Anthropic Messages API 的消息结构、内容块、工具调用和流式事件，客户端会根据模型返回的工具请求决定是否读取文件、执行命令或继续下一轮推理。

因此，过去常见的“把 OpenAI 兼容接口改成 Anthropic 格式”并不只是改一个 URL。路由层通常还要处理以下差异：

1. 请求体字段和消息结构不同；
2. 工具调用的参数格式和事件顺序不同；
3. 流式响应的事件类型不同；
4. 上下文、停止原因和错误码的表达方式不同；
5. 图片输入、工具结果和多轮状态的传递方式不同。

这也是为什么原生兼容对于编程 Agent 的价值高于普通聊天客户端。开发者少维护一层转换逻辑，遇到协议升级时也少一个可能失效的环节。

Codex 与 Claude Code 分别怎么接入

Codex 是 OpenAI 面向软件开发任务提供的编程 Agent；Claude Code 是 Anthropic 面向终端和代码仓库的命令行编程 Agent。 两者都能操作本地项目，但底层接入协议并不相同。

Codex：走 Responses API

Codex 侧使用 OpenAI Responses API 格式，Kimi 提供的接入地址为：

https://api.moonshot.cn/v1

开发者需要在 Codex CLI 或 Codex 桌面客户端中添加自定义模型提供商，填写 Kimi 平台生成的访问凭证，并将模型设置为 kimi-k3 或其他支持的 Kimi 模型。完成配置后，Codex 的界面可能把当前供应商显示为“自定义”，但实际请求使用的是所选的 Kimi 模型。

需要注意的是，Codex 桌面客户端近期更新后可能显示为 ChatGPT App。名称变化不改变其自定义模型提供商的使用逻辑，开发者应以客户端当前版本的设置入口为准。

Claude Code：走 Messages API

Claude Code 侧使用 Anthropic Messages API 格式，Kimi 提供的接入地址为：

https://api.moonshot.cn/anthropic

这里需要特别提醒，部分转载信息会把路径写成带空格的 https://api.moonshot.cn/ anthropic，实际配置时应使用没有空格的标准地址。开发者还需要在 Claude Code 的自定义供应商设置中填写模型名称和访问凭证。

对 Claude Code 用户来说，这次变化尤其直接。过去在国内使用 Claude Code，常见问题包括服务可用性、账号区域限制、模型供应商切换复杂，以及本地路由层对工具调用的兼容不完整。现在，Claude Code 可以按照 Anthropic 原生协议请求 Kimi 服务，减少了额外组件带来的排障成本。

支持哪些模型，怎么选

模型选择决定的是代码生成质量、响应速度和调用成本之间的平衡，而不是客户端功能本身。 目前 Kimi 官方列出的可选模型包括以下几类：

| 模型 | 更适合的场景 | 主要取舍 | |---|---|---| | kimi-k3 | 复杂代码仓库、跨文件重构、长链路 Agent 任务 | 能力优先，适合承担主力编程任务 | | kimi-k2.7-code-highspeed | 高频交互、快速补全、日常修复 | 响应速度优先，适合缩短等待时间 | | kimi-k2.7-code | 常规代码生成、测试编写、问题定位 | 能力与速度较均衡 | | kimi-k2.6 | 成本敏感、简单脚本和常规问答 | 适合轻量任务，不必为所有请求使用最高规格模型 |

上表是面向使用场景的选型建议，不代表官方对模型能力或价格的等级承诺。具体价格、上下文限制、速率限制和可用区域，仍应以 Kimi 开放平台当前页面为准。

如果开发者主要做大型仓库重构、复杂依赖分析和多步骤执行，优先考虑 kimi-k3。如果工作内容以代码解释、单元测试、简单 Bug 修复为主，kimi-k2.7-code 或 kimi-k2.6 往往更合理。对于需要频繁让 Agent 试错的任务，kimi-k2.7-code-highspeed 的价值在于减少每轮等待，而不只是单次生成速度更快。

“无需代理”解决了什么问题

无需代理的真正收益，是把原本由开发者维护的协议适配层交给模型服务商处理。 这里的“代理”指的是额外运行在客户端和模型服务之间的请求转发或格式转换组件，而不是网络访问意义上的通用代理。

在原生兼容之前，开发者通常需要面对三层配置：客户端本身、转换服务以及模型供应商。任何一层升级，都可能造成以下问题：

• 客户端升级后请求字段变化，转换服务无法识别；
• 工具调用能够发出，但流式响应解析失败；
• 图片或文件输入在转换过程中丢失；
• 多轮上下文被截断，Agent 重复读取文件；
• 本地服务未启动，客户端看似配置成功但请求无法发送。

现在，Codex 直接面向 Responses API，Claude Code 直接面向 Messages API，配置拓扑从“客户端—本地转换层—模型服务”变成“客户端—Kimi 原生协议入口”。这对个人开发者意味着少装一个常驻程序，对团队意味着少维护一套内部网关和故障排查手册。

不过，这并不等于所有工程问题都消失了。访问凭证管理、团队权限、用量控制、日志留存和敏感代码的合规处理仍然需要开发者自行负责。原生兼容降低了接入复杂度，但不会自动替代企业内部的安全治理。

图片能用，视频要区分两种限制

Responses API 当前支持文本和图片输入，但 Codex 客户端暂不提供原生视频输入通道。 这两个结论需要分开理解。

对于普通代码截图、网页截图、架构图和错误日志图片，开发者可以在支持视觉输入的场景中交给 Kimi 模型分析。但如果把一个视频文件直接拖进 Codex CLI，当前客户端输入层并不能把它作为完整的视频多模态请求提交。

如果任务是分析录屏、演示视频或摄像头素材，较现实的做法是先在本地提取关键帧，再根据需要对音频进行转写，最后把图片和文字交给 Agent。这样做的限制来自 Codex CLI 的输入通道，而不是简单等同于 Kimi K3 本身不具备视频理解能力。

这一区别对开发者很重要：遇到能力边界时，先判断问题出在模型、API 协议，还是客户端输入层。三者混为一谈，很容易得出错误结论。

对开发者工作流的实际影响

这次更新最有价值的地方，是让模型选择从“绑定某个客户端”变成“在同一套 Agent 工作流中切换模型”。

第一，Codex 和 Claude Code 的使用门槛进一步降低。开发者不必为了尝试 Kimi 模型而更换整个终端工作流，也不需要把项目迁移到新的专用客户端。

第二，模型替换的成本下降。对于已经熟悉 Claude Code 命令、权限控制和项目上下文机制的用户，可以继续使用原有工作方式，只替换背后的模型提供商。对于 Codex 用户也是如此，项目目录、终端操作和 Agent 交互习惯不需要重新学习。

第三，国产模型进入主流编程 Agent 的位置更靠前。过去国产模型常见的接入方式是提供一个“兼容 OpenAI”的聊天接口，但这只能覆盖一部分客户端。此次同时对齐 Responses API 和 Messages API，说明竞争已经从“能不能对话”转向“能不能稳定驱动复杂软件 Agent”。

第四，协议兼容会带来更直接的横向比较。开发者可以在相同的 Codex 或 Claude Code 工作流中，对比 Kimi、OpenAI 和 Anthropic 模型在代码修改、工具调用、上下文保持、中文需求理解以及长任务稳定性上的差异，而不是被不同客户端的交互设计干扰。

但别把“能接入”误读成“完全等价”

协议兼容不等于模型能力、工具生态和服务体验完全等价。 这是这次更新最需要保持理性的地方。

首先，客户端功能由 Codex 或 Claude Code 决定，模型能力由 Kimi 决定。即使请求格式完全兼容，不同模型在复杂规划、代码审查、长上下文召回、终端操作安全性和错误恢复上的表现仍然可能不同。

其次，模型名称显示可能造成误解。Codex 桌面客户端的模型选择器出现“自定义”并不意味着调用失败，也不代表它正在使用 ChatGPT 的默认模型；只要自定义供应商和模型配置正确，实际请求可以指向 kimi-k3 或用户指定的其他 Kimi 模型。

再次，工具调用的稳定性需要真实项目验证。简单的代码补全和单文件修改，很难暴露协议适配中的边界问题。更有参考价值的测试包括：跨目录重构、运行测试后自动修复、处理包含图片的 Issue、连续执行多轮终端命令，以及在上下文接近上限时保持任务目标不丢失。

最后，成本不能只看单次响应速度。编程 Agent 通常会读取大量文件并进行多轮调用，实际费用取决于输入 Token、输出 Token、上下文复用、任务重试次数和模型单价。一个单次回答更便宜的模型，如果需要更多轮修正，最终成本未必更低。

适合现在就尝试的三类用户

最适合立即尝试这次更新的，是已经拥有 Codex 或 Claude Code 工作流、但希望增加模型选择的开发者。

• 国内个人开发者：希望继续使用熟悉的终端 Agent，同时接入 Kimi 模型。
• 团队研发人员：需要在不同模型之间做代码质量、速度和成本对比。
• 工具链开发者：正在构建多模型编程 Agent，希望减少对自建协议适配层的依赖。

不建议把它理解成“安装后所有任务自动变好”。更准确的定位是：Kimi 提供了一个与主流编程 Agent 更贴近的模型入口，开发者获得了更低的切换成本，但最终效果仍需结合项目类型、模型版本和团队工作流评估。

配置前的检查清单

在开始配置前，建议确认以下事项：

1. Codex CLI 或 Codex 桌面客户端已经安装，并至少成功启动过一次；
2. Claude Code 已完成基础安装和登录配置；
3. 已在 Kimi 开放平台创建访问凭证，并按照组织安全要求保存；
4. base_url 使用正确的协议入口，Anthropic 路径中不要包含空格；
5. 模型名称完整填写，例如 kimi-k3，不要把显示名称和实际模型标识混用；
6. 配置完成后重启 Codex CLI 或 Claude Code，使新的提供商设置生效；
7. 先用简单的文本任务测试，再执行会修改大量文件或运行命令的复杂任务；
8. 涉及代码仓库时，先确认 Git 工作区干净，并审查 Agent 生成的修改。

如果电脑上已经安装了 Kimi Code、Kimi Work 等本地 Agent，也可以让本地 Agent 按照 Kimi 官方的 Codex 和 Claude Code 配置教程完成设置。但涉及访问凭证、项目文件和终端权限时，仍应人工确认每一步修改，不要把权限配置完全交给自动化脚本。

OpenAI Hub 观点

Kimi API 原生兼容 Codex 和 Claude Code，是一次有实际使用价值的基础设施更新，但它的意义主要在于降低接入和切换成本，而不是凭协议兼容直接改变模型能力排名。

对个人开发者来说，最大的变化是少折腾一层配置；对团队来说，最大的变化是可以在熟悉的 Agent 环境中做更公平的模型评测；对 Kimi 来说，真正的考验则是协议兼容之后的稳定性，包括长任务成功率、工具调用可靠性、流式响应一致性和高峰期服务质量。

如果你已经在使用 Codex 或 Claude Code，这次更新值得直接测试。建议不要只做一句“写个函数”的演示，而是拿真实仓库中的一个可回滚任务进行评估：让 Agent 读取项目结构、修改多个文件、运行测试并根据错误继续修复。只有在这类完整闭环中，才能看出 Kimi 模型与客户端、工具链和上下文机制是否真正配合顺畅。

从更大的趋势看，编程 Agent 正在逐渐成为模型竞争的主要战场。模型不再只是回答问题的聊天接口，而是要进入代码仓库、调用工具、管理状态并承担连续数十分钟甚至数小时的任务。谁能更稳定地接入这些 Agent，谁就更接近开发者每天真实使用的入口。