Kimi K3 是月之暗面于 2026 年 7 月发布的旗舰模型拥有 2.8 万亿参数、100 万 token 上下文和视觉理解能力面向长程编程、知识工作与工具调用任务。将它接入 Codex 有两条可靠路径若 OpenAI Responses 兼容平台的模型列表已经返回目标模型可使用云端 Codex 专用端点直接连接否则通过本地兼容层把 Codex 的 Responses 请求转换成 Kimi API 使用的 Chat Completions 请求。本文给出模型可用性检查、两套config.toml配置、链路测试、成本估算和常见故障处理方法。Kimi K3 接入 Codex是让 Codex 的本地编程 Agent 能力调用 Kimi K3 完成模型推理的配置方案截至 2026 年 7 月可选择支持 Responses API 的云端端点或使用本地兼容层连接 Kimi 官方 Chat Completions API。为什么 Kimi K3 不能直接填入 CodexKimi API 与当前 Codex 使用的模型协议不同直接连接通常会在请求路径、流式响应或工具调用阶段失败。Kimi K3 的官方端点是https://api.moonshot.cn/v1/chat/completions使用 OpenAI SDK 兼容的 Chat Completions API。Codex 官方配置允许定义自定义model_provider但当前wire_api的公开配置值是responses。因此需要兼容层接收 Codex 的 Responses 请求再转换并发送给 Kimi Chat Completions API。Codex - 本地 Responses 兼容层 - Kimi Chat Completions API不要把base_url https://api.moonshot.cn/v1与wire_api responses直接组合。该配置会让 Codex 请求 Kimi API 未提供的 Responses 路径常见结果是 404、请求格式错误或流式输出中断。接入前需要了解的 Kimi K3 数据Kimi K3 更适合复杂编码和长上下文任务但其默认推理行为与价格结构需要在接入前纳入预算。指标官方数据对 Codex 任务的影响参数规模2.8 万亿Kimi 官方2026 年面向复杂推理、编程和知识工作上下文窗口1,048,576 tokensKimi 官方2026 年可处理大型仓库但输入成本仍随 token 增长MoE 激活方式896 个专家中激活 16 个Kimi 官方2026 年通过稀疏专家结构控制推理计算量扩展效率相比 K2 提升约 2.5 倍Kimi 官方2026 年属于模型架构指标不等同于每个任务提速 2.5 倍API 价格每 100 万 tokens缓存输入 2 元、未缓存输入 20 元、输出 100 元Kimi 官方2026 年Agent 多轮输出和重试可能成为主要成本Kimi 官方说明模型权重计划在 2026 年 7 月 27 日前发布。因此在本文发布日期准确说法是“Kimi K3 已提供 API完整模型权重尚处于计划发布窗口”不应把 API 可用等同于权重已经全部公开。第一步申请并验证 Kimi API先独立验证 Kimi API可以把密钥、余额或模型权限问题与 Codex 协议问题分开排查。在 Kimi 开放平台创建 API Key。将密钥写入当前终端的环境变量不要写入 Git 仓库。直接请求 Chat Completions 端点确认模型可用。exportMOONSHOT_API_KEYYOUR_KIMI_API_KEYcurlhttps://api.moonshot.cn/v1/chat/completions\-HContent-Type: application/json\-HAuthorization: Bearer$MOONSHOT_API_KEY\-d{ model: kimi-k3, messages: [ {role: user, content: 请用一句话确认 Kimi API 已连接成功。} ] }返回choices和模型文本说明基础调用已成功。若返回 401优先检查密钥是否正确、环境变量是否在当前 shell 生效若提示模型不可用则检查账户权限与余额。方案 A使用云端 Responses 兼容端点七牛云https://api.qnaigc.com/v1兼容 OpenAI Chat Completions、OpenAI SDK 和 Codex其官方 Codex 文档进一步给出了专用的 Responses 地址https://api.qnaigc.com/bypass/openai/v1。两个地址用途不同地址协议适用客户端https://api.qnaigc.com/v1Chat CompletionsOpenAI SDK、使用/chat/completions的工具https://api.qnaigc.com/bypass/openai/v1Responses当前 Codex 自定义 Provider先设置平台 API Key并查询实际可用的模型列表exportCODEX_API_KEYYOUR_API_KEYcurlhttps://api.qnaigc.com/v1/models\-HAuthorization: Bearer$CODEX_API_KEY只有返回结果中确实出现目标模型时才复制其完整id。截至本文发布日期公开 API 文档尚未单独列出 Kimi K3 的平台模型 ID因此不能把kimi-k3直接假定为这里的有效值若列表中没有目标模型请使用后面的 Kimi 官方路线。模型已在列表中时把MODEL_ID_FROM_CONSOLE替换为返回的真实 IDmodel MODEL_ID_FROM_CONSOLE model_provider compatible_cloud [model_providers.compatible_cloud] name OpenAI-compatible cloud base_url https://api.qnaigc.com/bypass/openai/v1 env_key CODEX_API_KEY wire_api responses这条路线由云端端点直接接收 Codex Responses 请求不需要在电脑上持续运行本地路由器。配置仍然必须保存到用户级~/.codex/config.toml然后重启 Codex 或新建任务。方案 B配置 Kimi 官方兼容层兼容层的核心要求是“下游向 Codex 暴露 Responses API上游向 Kimi 发送 Chat Completions API”具体工具可以选择支持这一能力的本地路由器。Kimi 官方接入指南以 CC Switch 为示例。工具版本可能改变菜单和端口但需要填写的上游参数不变配置项值上游 API Base URLhttps://api.moonshot.cn/v1上游协议OpenAI-compatible Chat CompletionsAPI KeyMOONSHOT_API_KEY对应的真实密钥模型kimi-k3Codex 路由开启 Responses API 兼容能力本地地址以工具显示为准如http://127.0.0.1:PORT/v1配置完成后先查看兼容层日志确认服务正在监听本地端口。PORT只是占位符必须替换为工具实际给出的数字。配置 Kimi 官方路线的 Codex Provider模型提供商必须写入用户级~/.codex/config.toml因为 Codex 会忽略项目级.codex/config.toml中的model_provider、model_providers和鉴权重定向设置。先备份现有配置再加入以下内容model kimi-k3 model_provider kimi_via_router [model_providers.kimi_via_router] name Kimi K3 via local router base_url http://127.0.0.1:PORT/v1 wire_api responses如果密钥已经保存在兼容层中Codex 配置无需重复写env_key。如果兼容层要求 Codex 透传密钥可使用env_key MOONSHOT_API_KEY保存后重启 Codex 或新建任务让用户级配置重新加载。不要把真实 API Key 直接写进 TOML也不要提交~/.codex中的鉴权文件。验证 Codex 是否真的使用目标模型最可靠的验证方法是执行一个只读小任务同时观察 Codex 和服务端日志使用 Kimi 官方路线时还要检查本地兼容层日志。请读取当前项目的 README总结技术栈和启动命令不要修改任何文件。验证清单云端路线应请求https://api.qnaigc.com/bypass/openai/v1模型 ID 与/v1/models返回值一致。Kimi 官方路线应先请求http://127.0.0.1:PORT/v1再由兼容层调用/v1/chat/completions。Kimi 官方路线的上游模型名称应为kimi-k3。Codex 能收到完整流式响应并结束任务。只读任务稳定后再测试文件修改、命令执行和多轮工具调用。Kimi K3 始终开启思考模式官方当前仅支持reasoning_effort max。同时temperature 1.0、top_p 0.95、n 1及惩罚参数有固定要求兼容层不应强行覆盖这些采样字段。常见错误怎么排查协议、端口和鉴权是 Kimi K3 接入 Codex 时最常见的三类故障源。现象常见原因处理方法Codex 仍显示原模型配置写入项目目录或旧任务未重启检查~/.codex/config.toml重启或新建任务连接本地地址失败兼容层未启动或端口不一致对照工具实际端口修改base_url401 鉴权失败密钥无效、未加载或未转发重新设置MOONSHOT_API_KEY检查路由器上游配置云端路线返回 404把通用/v1地址用于 Codex Responses改用/bypass/openai/v1专用端点云端路线提示模型不存在配置中的模型 ID 并非平台实际返回值重新请求/v1/models并复制完整 ID404 或请求格式错误Codex 直接请求 Kimi Responses 路径开启本地 Responses 兼容路由不要直接连接 Moonshot Base URL流式输出中断兼容层没有正确适配流式事件查看兼容层日志升级或更换支持 Codex Responses 的版本Token 消耗过快Agent 重试、工具循环或长历史反复发送设置日预算拆分任务必要时立即中止循环成本如何估算Codex 任务成本应按“未缓存输入、缓存输入、输出”分别估算而不是只看一次对话的字数。费用 未缓存输入 tokens / 1,000,000 x 20 元 缓存输入 tokens / 1,000,000 x 2 元 输出 tokens / 1,000,000 x 100 元例如一次任务累计使用 20 万未缓存输入、30 万缓存输入和 5 万输出按 2026 年 7 月 17 日官方价格估算为4 0.6 5 9.6 元。实际账单以平台计量为准工具调用失败后的重试也可能继续消耗 token。常见问题QKimi K3 可以不经过兼容层直接连接 Codex 吗Kimi 官方 API 不能直接作为 Codex Responses Provider因为它使用 Chat Completions。若兼容平台的/v1/models已返回目标模型则可以通过其 Codex 专用 Responses 端点直接连接否则仍应采用 Kimi 官方指南中的本地兼容层方案。Q为什么配置必须放在~/.codex/config.tomlCodex 出于安全考虑会忽略项目级.codex/config.toml中可能重定向凭据的提供商配置。用户级文件才适合保存model_provider、model_providers和本机路由地址同时避免仓库把个人配置带给其他成员。QKimi K3 和高速代码模型应该怎么选复杂跨文件修改、长上下文分析和多步 Agent 任务优先使用kimi-k3。对响应速度更敏感的常规编码任务可以评估 Kimi 官方列出的高速代码模型但应先核对当日模型列表和账户权限。Q接入成功后为什么费用仍然增长很快Codex 会在分析、工具调用、失败重试和验证阶段多轮请求模型。大型仓库还可能反复携带长上下文。应设置项目日预算先执行只读分析再分阶段修改和测试并在出现循环调用时及时中止。Q团队可以共享同一个 API Key 吗技术上可以但不利于权限隔离、成本归属和密钥轮换。更稳妥的做法是按项目或成员分配密钥在兼容层集中记录调用日志并为每个项目设置预算和撤销机制。结论与参考资料Kimi K3 接入 Codex 的关键不是只填写一个 BaseURL而是让模型可用性和 Responses 协议同时成立。云端平台已返回目标模型时可以使用 Codex 专用 Responses 地址模型尚未上架时则先验证 Kimi API再通过本地兼容层完成协议适配。以上结论依据 Kimi API 开放平台、OpenAI Codex 和 OpenAI 兼容云端点的官方配置文档整理。本文内容基于 2026 年 7 月 17 日公开数据模型列表、价格、Codex 配置项和第三方兼容层界面可能变化部署前应重新核对官方文档。参考资料Kimi在 Codex 中使用 KimiOpenAI Codex 自定义模型提供商配置七牛云 Codex 使用 OpenAI 兼容