Codex 接入 DeepSeek、Kimi、GLM
Codex 可以通过自定义模型提供商连接第三方服务。接入 DeepSeek、Kimi、GLM 时，需要一起确认接口协议、模型名称、凭证类型和客户端配置。只把模型名换成国产模型，或者只设置一个 API Key，都不足以保证请求走到正确的服务。
截至 2026 年 10 月 24 日，三家已发布各自的 Codex 接入文档。下面先解释官方直连的差异，再给出 ClawSocket 的 provider 模板。官方直连与第三方路由使用不同账户和账单，不能混用密钥，也不应把一家文档中的模型元数据直接当成另一家的配置。
接入前先理解 Responses 协议
Codex 官方配置参考和官方配置 Schema定义了自定义 provider 的字段。当前 Schema 的 wire_api 支持 responses，也提供 base_url、env_key 等配置项。本文按这一工作方式编写，不建议照抄旧教程中的 Chat Completions 配置。
Responses 和 Chat Completions 是不同的请求及事件格式。一个服务能处理 /chat/completions 的普通聊天请求，不代表它也能处理 Codex 发送的 /responses 请求。即使纯文本返回正常，工具调用、流式结果和后续回合也需要单独验收。
供应商提供的模型目录文件，通常用于告诉客户端模型的上下文、工具格式和推理设置。它是客户端元数据，不会凭空给后端增加能力。声明了图片输入，也仍需确认服务端模型支持图片；声明了工具格式，也仍需验证实际工具循环。
开始前保留原配置
先运行 codex --version，确认使用的是预期客户端，再查看用户级配置。macOS 和 Linux 常用路径是 ~/.codex/config.toml，Windows 使用用户目录下的 .codex\config.toml。如果已有配置，先保存副本，尤其是 MCP、项目设置和其他 provider，不要用示例整份覆盖。
修改顶层 model 和 model_provider 时，应放在 TOML 表头之前，或者明确修改现有顶层字段。[model_providers.kimi] 之后的字段属于该表，不能仅靠空行回到顶层。重复粘贴同名配置块也会造成解析问题。
凭证建议通过 env_key 引用环境变量。下面的 Python 命令用于只检查变量是否存在，不显示内容。它只验证当前进程环境，不能证明密钥有效、账户有余额或目标模型可用。
python3 - <<'PY'
import os
print('已设置' if os.environ.get('KIMI_API_KEY') else '未设置')
PYDeepSeek：使用官方 Codex 专用配置
DeepSeek 官方 Codex 指南明确说明其 API 原生支持 Responses，并给出自动配置及手动配置两条路径。当前页面涉及 deepseek-flash、deepseek-v4-pro 及模型目录配置。模型名和脚本内容可能更新，应以该页面当前展示为准。
这条路径不只是增加一个基础 URL。官方方案还包括模型目录声明和相关配置调整，因此建议按完整指南操作，而不是从普通聊天 SDK 示例里拼出一份 Codex 配置。已经有 models.json 的用户，应先检查如何合并或恢复，避免覆盖其他模型目录。
采用自动配置时，先阅读脚本说明和将改动的文件，再决定执行。官方指南描述了备份与恢复方式；操作之后仍应确认自己的原有设置是否保留。采用手工方式时，逐项核对指南要求的目录、路径和模型元数据，完成后重启客户端验证。
不要把 deepseek-chat 等熟悉的历史别名当成当前 Codex 配置必然支持的模型。一个别名在聊天端点可用，并不能证明它在所用 Responses 端点和工具格式下可用。若希望通过 ClawSocket 使用 DeepSeek，应改为核对 ClawSocket 账户中的模型名及接入要求。
Kimi：官方原生 Responses 直连
Kimi 官方 Codex 教程提供了 kimi-k3.1-pro 的直连配置。该指南要求匹配中国区开放平台 Key 与 https://api.moonshot.cn/v1，同时声明上下文窗口。下面保留这些关键字段，密钥通过环境变量提供。
model = "kimi-k3.1-pro"
model_provider = "kimi"
model_context_window = 1048576
[model_providers.kimi]
name = "Kimi"
base_url = "https://api.moonshot.cn/v1"
env_key = "KIMI_API_KEY"
wire_api = "responses"macOS/Linux 可在终端交互读取密钥后启动，避免把真实值直接写入命令历史：
printf '输入 Kimi API Key：'
read -r -s KIMI_API_KEY
printf '\n'
export KIMI_API_KEY
codex这些命令面向 Bash/Zsh；使用其他 shell 时按其语法调整。变量只在当前环境及其子进程中生效。若使用已经打开的桌面应用，应确认它实际取得了所需变量，并在配置修改后重新启动，不要假定终端的 export 会自动改变已有应用环境。
Kimi 文档还提醒，客户端可能把自定义模型显示为“自定义”。因此确认路由时应结合配置、模型和服务端请求记录，不能只依据显示名称。先发送一句短文本，再要求读取测试仓库并总结结构，确认工具结果返回后仍能生成最终回答。
GLM：注意专属端点和套餐 Key
智谱官方 Codex 教程要求使用专属 Responses 基础地址 https://open.bigmodel.cn/api/v1。不要把其他客户端使用的聊天或 Messages 地址直接替换进来。该文档同时明确，个人套餐、团队套餐和标准 API 的密钥分开管理，互不通用。
当前官方方案包括模型目录文件以及 model_catalog_json 引用，页面提供了 glm-5.3 等条目的完整声明。先按官方文档准备目录文件，然后再设置 provider。下面展示使用环境变量的配置核心，不包含目录文件的全文；缺少目录时不能把它视为完整安装方案。
model_provider = "ZAI"
model = "glm-5.3"
model_reasoning_effort = "max"
model_catalog_json = "~/.codex/models.json"
[model_providers.ZAI]
name = "ZAI"
base_url = "https://open.bigmodel.cn/api/v1"
env_key = "GLM_API_KEY"
wire_api = "responses"官方示例使用 experimental_bearer_token；本文根据 Codex Schema 改用 env_key，因此需要在启动进程的环境中设置 GLM_API_KEY。不要同时保留两个来源不清的凭证字段。若本机版本或组织配置另有限制，应先对照相应版本的字段支持范围。
官方也提供 Coding Tool Helper。无论选择助手还是手动方式，都要知道它改了哪些文件，并保存原有状态。安装完成后，检查 JSON 格式、目录路径和模型 ID，再进入小仓库测试。401 时优先检查密钥类型，404 时同时检查专属端点与模型权限。
使用 ClawSocket 统一接入
如果希望在一个服务入口下管理不同模型，可以进入 ClawSocket 控制台，核对当前账户的模型、价格和接口支持。本站使用的基础地址是 https://api.clawsocket.com/v1。这条路径使用 ClawSocket 凭证，不能填入前面三家官方平台的 Key。
下面是 provider 模板。REPLACE_WITH_AVAILABLE_MODEL_ID 必须替换为该账户实际可用、并经过 Responses 与 Codex 工具流程验证的模型 ID。此处不承诺每个上架模型都能完整运行 Codex，也不把官方直连的元数据自动套用到路由服务。
model = "REPLACE_WITH_AVAILABLE_MODEL_ID"
model_provider = "clawsocket"
[model_providers.clawsocket]
name = "ClawSocket"
base_url = "https://api.clawsocket.com/v1"
env_key = "CLAWSOCKET_API_KEY"
wire_api = "responses"设置凭证并启动：
printf '输入 ClawSocket API Key：'
read -r -s CLAWSOCKET_API_KEY
printf '\n'
export CLAWSOCKET_API_KEY
codex先确认模型后再决定是否需要额外目录声明、上下文参数或工具设置。不要为了消除警告，给所有模型填同一组元数据。路由端可能采用不同模型快照和能力约束，应按实际接入说明配置。无法确认时，把错误字段、请求标识和最小复现提交给对应服务排查。
用一次小任务验收接入
第一步测试短文本。输入一条简短请求，确认没有鉴权和参数错误。然后检查请求记录，确认时间、账户和模型路径符合预期。回答中自报的模型名称只能作为文本内容，不能作为请求实际路由的证据。
第二步测试只读工具。选择一个不含敏感材料的小仓库，要求列出根目录文件，再概括项目入口。观察它是否实际调用工具、工具结果是否返回，以及结果返回后是否继续作答。若只输出准备执行的命令，却没有工具结果，不能认定这一环已经通过。
第三步测试可撤销修改。比如在临时目录创建一个小函数和对应示例，要求修改一个明确行为，再运行现有验证命令。检查 Git diff 或文件内容，确认修改与目标一致，命令确实执行。不要把首次验收放在生产数据库、发布脚本或带有外部副作用的任务上。
验收记录应分开写明：文本通过、只读工具通过、写文件通过、验证命令通过，以及尚未覆盖的能力。图片、搜索、并行工具和长上下文等若是实际需求，需要另行测试。一个小任务通过，只说明这条基本路径成立，不能推断所有高级功能都可用。
切换模型时保留哪些信息
为每条路径记录 provider、模型 ID、端点、密钥所属产品、配置日期和已通过的验收项。模型元数据来源也应保留链接，方便升级后重新核对。记录中不需要保存真实 Key，可以写环境变量名和凭证负责人。
切换前先结束或暂停当前任务，保存工作区状态，再修改配置并重启会话。尤其是模型已经改过文件时，不要在不说明现状的情况下让另一模型从最初要求重做。先让它读取当前变更和剩余失败，再继续工作，能减少覆盖和重复操作。
费用也要重新确认。官方编程套餐、标准 API 和 ClawSocket 账单各有口径，模型名称相同不保证价格相同。试运行时记录一次可验收任务的实际费用，再决定是否扩大使用范围。预算方法见Codex 套餐与 API 成本。
桌面端与终端分别验证
终端成功之后，桌面端仍要独立检查。两者可能读取同一份用户配置，却运行在不同环境里。最容易遗漏的是密钥：在终端输入变量以后，已经运行的桌面进程不会因此自动拿到它。先按对应应用支持的方式提供凭证，再重启并检查当前选择，避免连续修改一份其实没有被重新读取的配置。
如果机器上还有配置管理工具，确认它是否会改写 Codex 配置。手动修改后过一会儿又恢复，往往需要先找到写入来源，再决定由哪一处维护。不要让多个工具同时管理相同字段。调整前记下已有路由，调整后检查文件实际内容，必要时再查看启动参数和选中的配置档案。
团队共享接入说明时，最好提供带占位符的配置模板、适用版本和验收任务，凭证由成员分别注入。这样既能复现设置，也能避免文档里的某把个人密钥成为所有人的依赖。模型目录需要更新时，说明替换哪些条目，保留哪些已有配置，而不是要求成员删除整个目录重装。
迁移已有任务时先检查工作区
从官方模型迁移到第三方模型，可以从一个新会话开始，带上任务目标、已完成部分和剩余检查。先让工具读取现有改动，再继续执行。旧会话里的隐含判断未必会完整带入新路径，把重要约束整理成文字，能让后续结果更容易解释。
若迁移后出现质量问题，保留一组相同的输入和验收条件，分别记录两条路径的结果。不要把一次工具失败直接归因于模型推理能力，也不要把更换模型后的偶然通过当成稳定性结论。只有在请求格式、环境和任务范围都明确时，比较才有实际意义。
遇到失败时从哪一层退回
配置加载失败，先查 TOML 和模型目录；401 查 Key 与端点归属；404 查路径和模型；参数错误查协议与模型声明；流式中断查事件和连接；工具失败查工作目录及执行权限。详细流程见Codex 报错大全与诊断树。
接入完成的标准应是：你知道请求发给谁，能查到费用，工具能按预期执行，生成的修改可以审查。满足这些条件后，再逐步把它用于真实任务。需要在官方直连和统一入口之间选择时，用同一个小任务比较配置维护、验收结果和实际账单即可，不必根据品牌或单次回答作结论。