CC Switch 本地路由实战让 Codex CLI 用上 DeepSeek 等 Chat 格式供应商【免费下载链接】cc-switchA cross-platform desktop All-in-One assistant for Claude Code, Codex, OpenCode, OpenClaw, Grok Build Hermes Agent. Only official website: ccswitch.io项目地址: https://gitcode.com/GitHub_Trending/cc/cc-switch本文基于 CC Switch 仓库内文档与源码整理讲解 3.19.1 及以上版本中如何将 DeepSeek、Kimi、智谱 GLM 等暴露 OpenAI Chat Completions 接口的供应商接入 Codex CLI包括需要路由徽章的判断方法、Responses → Chat协议转换的四步链路、本地路由接管的配置步骤以及走直连后用量归属变化的原因。读完后你可以独立完成 Chat 格式供应商的 Codex 接入并看懂~/.codex/config.toml中由 CC Switch 生成的配置字段。先确认你是否还需要这篇攻略适用版本CC Switch 3.19.1 及以上。3.19.1 起有重要变化DeepSeek 预设已改为原生 Responses 直连不再需要本地路由。但这条路由转换的路径并没有作废——它仍是deepseek-v4-pro在官方尚未开通 Codex 集成期间、升级前已保存的供应商以及 Kimi、智谱 GLM 等 Chat 格式供应商的必经之路。判断方法只有一个看 Codex 供应商卡片上有没有需要路由徽章带需要路由徽章这个供应商走 Chat 格式本文全部适用。没有徽章它已经是 Responses 原生直连本文的路由步骤对它没有意义可以直接用。带不支持路由徽章这是官方供应商CC Switch 会阻止它走本地路由见文末常见问题。前端代码中徽章文案就定义在 ProviderCard.tsx分别对应需要路由与不支持路由两种展示状态。徽章由供应商保存时记录的 API 格式决定所以升级 CC Switch不会改变已有供应商的行为。具体到 DeepSeek升级到 3.19.1 之后有三种情况你的情况是否需要路由说明3.19.1 之前保存的 DeepSeek 供应商需要仍带徽章预设改动只影响新建的供应商已保存的配置原样保留想改走直连见下文改造已有的 DeepSeek 供应商3.19.1 之后用预设新建的 DeepSeek不需要直连api.deepseek.com并会拿到 DeepSeek 官方的模型目录想用deepseek-v4-pro官方尚未开通 Codex 集成时需要直连会上游报错必须走 Chat 路由源码中可以看到 3.19.1 之后 DeepSeek 预设的当前形态codexProviderPresets.ts 中name: DeepSeek的预设apiFormat已设为openai_responsesbase URL 为https://api.deepseek.com默认模型为deepseek-v4-flash模型目录中deepseek-v4-flash与deepseek-v4-pro均声明了 1048576 上下文窗口和 low/high/max 三档思考级别。除 DeepSeek 外Kimi、智谱 GLM、SiliconFlow、ModelScope 等大量供应商仍是 Chat 格式本文对它们完全适用——把下文中的 DeepSeek 换成对应预设即可。例如 codexProviderPresets.ts 中Zhipu GLM预设的apiFormat就是openai_chatbase URL 为https://open.bigmodel.cn/api/coding/paas/v4。为什么需要本地路由新版 Codex CLI 面向的是 OpenAI Responses API而很多供应商实际暴露的是 OpenAI Chat Completions 形态也就是/chat/completions。这两种协议的请求体、流式事件和返回结构不同直接把 Chat 接口填进 Codex 配置里常见结果就是模型列表不对、请求 404/400或者流式响应无法被 Codex 正确解析。CC Switch 的做法是让 Codex 始终连本机路由仍以 Responses API 发送请求路由在内部识别当前供应商是否是 Chat 格式再把请求改写成 Chat Completions 发给上游最后把 Chat 响应转换回 Responses 形态返回给 Codex。这条链路主要分成四步Codex 接管时本地配置会被写成http://127.0.0.1:15721/v1并强制保持wire_api responses。Provider 的meta.apiFormat openai_chat会告诉路由真实上游是 Chat Completions。路由把/responses或/v1/responses改写到/chat/completions并把 Responses 请求体转换成 Chat 请求体。上游返回后路由再把 Chat 的 JSON 或 SSE 转回 Codex 能理解的 Responses JSON/SSE。这些步骤在源码中都有对应实现可以逐一印证接管时写wire_api responsescodex_config.rs 中的update_codex_toml_field会把wire_api字段写入[model_providers.current]段若不存在则回退到顶层测试用例wire_api_writes_into_correct_model_provider_section验证了写入位置的正确性。路由端识别 Chat 格式proxy/providers/codex.rs 中对openai_chat、openai_chat_completions等 apiFormat 取值做归一化处理配套的格式转换逻辑位于 transform_codex_chat.rs。本地路由默认端口15721定义在 proxy/types.rs 等服务层代码中接管与切换逻辑集中在 services/provider/mod.rs。供应商原生就是 Responses 的如现在的 DeepSeek 预设第 24 步不发生请求直接发往上游不做任何格式改写。准备工作你需要先准备好三样东西已安装并能启动的 CC Switch。已安装 Codex CLI并至少运行过一次让~/.codex/config.toml目录结构存在。目标供应商的 API Key。以 DeepSeek 为例官方文档写明 OpenAI 兼容 base URL 是https://api.deepseek.com其他供应商常见的是带/v1或更长路径的 base URL例如智谱 GLM 是https://open.bigmodel.cn/api/coding/paas/v4Chat API 路径是/chat/completions。CC Switch 的预设已按这些信息配好请优先使用预设不需要手动拼接口路径。第一步添加 Codex 供应商打开 CC Switch切到顶部的Codex标签点击右上角的加号添加供应商。用预设推荐在预设列表里选中目标供应商填入 API Key保存即可。预设已经内置请求地址、默认模型、模型菜单并会自动设好上游格式Chat 格式的预设保存后卡片上就会出现需要路由徽章。思考参数thinking / reasoning预设已自动配置好不需要手动填。用自定义配置按对方文档填 API Key 和 base URL然后展开表单底部的高级选项把上游格式选为Chat Completions需开启路由。这个下拉共有三个选项上游格式选项含义Responses原生上游原生支持 Responses API直连不转换无需路由Chat Completions需开启路由本文讲的情况由本地路由做 Responses → Chat 转换Anthropic Messages需开启路由上游只提供原生 Anthropic 协议同样由路由转换只有Responses原生不需要开启路由接管另外两个都需要。自定义供应商的思考参数由 CC Switch 按名称与地址自动推断只有在识别不准时才需要展开思考能力手动覆盖。改造已有的 DeepSeek 供应商把上游格式改成Responses原生即可不必删掉重建。下次切换到它时CC Switch 会认出deepseek.com地址并套用 DeepSeek 官方的模型目录freeformapply_patch、GPT-5 harness、low/high/max 思考档与 web_search 都会照常生效。唯一的小差别是上下文窗口供应商自己保存的模型行优先级更高3.19.1 之前存下的1000000会盖掉官方声明的1048576少 4 万多 token。介意的话在高级选项→模型映射里把该行的上下文窗口改成1048576就行或者干脆用预设新建一个。反过来想用deepseek-v4-pro官方尚未开通 Codex 集成时就把上游格式改回Chat Completions。另外直连所用的官方模型目录要求 Codex CLI0.144.0 或更新它带的 freeformapply_patch注册需要这个版本CC Switch 不会替你校验生成的目录文件也会涨到 75 KB 左右因为其中包含完整的 GPT-5 harness 文本。从源码结构看官方模型目录的生成由CC_SWITCH_CODEX_MODEL_CATALOG_FILENAME即cc-switch-model-catalog.json驱动常量定义见 codex_config.rs切换供应商时后端按deepseek.comhost 镜像官方 models.json这一逻辑在 services/proxy.rs 的测试断言cc-switch-model-catalog.json must be created on provider switch中也有体现。第二步开启本地路由并接管 Codex进入设置里的路由页面展开本地路由完成两个开关打开路由总开关启动本地服务。默认地址是127.0.0.1:15721。在路由启用中打开Codex。如果只想让 Codex 走路由可以保持 Claude、Gemini 关闭。接管后CC Switch 会把 Codex 的 live 配置指向本机路由并用占位符管理认证。真实 API Key 仍保存在 CC Switch 的 Provider 配置里由本地路由在转发时注入不需要你把 Key 暴露给 Codex live 配置。对应的 live 配置生成逻辑见 services/provider/live.rs其中注释明确说明了DB 是唯一事实来源SSOTcc-switch-model-catalog.json只是它的投影。路由服务的完整说明可参考用户手册的 代理服务 与 应用路由 两章。第三步切换供应商并重启 Codex回到 Codex 供应商列表点击目标供应商的启用。如果它带需要路由标记而路由没有启动CC Switch 会弹出需要路由服务才能正常使用的提示。切换后建议重启当前 Codex 终端会话。原因是Codex 进程可能已经读取过旧的config.toml。model_catalog_json生成后/model菜单通常需要新进程才能刷新。进入 Codex 后可以用/model查看当前模型是否来自对应预设。随后发一个小问题确认路由面板的请求数增长或者在用量/请求日志里看到 Codex 请求即可。走直连之后用量归属会变这一点值得单独提醒供应商改走直连后它的请求不再经过本地路由按请求计费的代理用量统计也就看不到它了。用量本身不会丢——Codex 的会话日志导入照常记录——但这条路径不携带供应商身份所有没走本地代理的 Codex 用量会一起归入名为Codex (Session)的条目。要区分它们看模型每条用量记录都带着自己的模型 ID用量面板的「模型统计」按模型逐行列出费用与 token 都是分开的。如果你确实需要按供应商维度对账比如比较多个聚合商上的同一个模型那就保持上游格式为 Chat 并开着路由接管。常见问题Codex 报 404 或找不到/responses通常是没有开启 Codex 接管或者你手动把上游 Chat base URL 直接写给了 Codex。检查~/.codex/config.toml是否指向http://127.0.0.1:15721/v1。上游报 404如果用的是内置预设先确认当前供应商确实来自预设并且 Codex 路由已启用。只有在使用自定义供应商时才需要额外检查 base URL它应该是对方文档给出的服务端点而不是带/chat/completions的完整接口路径。切到deepseek-v4-pro后上游报错DeepSeek 官方尚未为该模型开通 Codex 集成官方预计 2026 年 8 月初。把这个供应商的上游格式改回Chat Completions需开启路由并开启路由接管即可——这正是 3.19.1 之前 DeepSeek 走的路径路由的 Responses→Chat 转换照常支持 pro。或者改用deepseek-v4-flash它是预设默认值不受影响。/model看不到供应商的模型保存供应商后重启 Codex。CC Switch 会生成cc-switch-model-catalog.json并把路径写入model_catalog_json但正在运行的 Codex 进程不一定会热加载模型目录。目前 Codex app 不支持多模型选择默认使用配置的第一个模型。开了路由但请求仍走错供应商确认三处状态一致Codex 标签下当前供应商正确本地路由服务正在运行路由启用里 Codex 开关已打开。可以用官方 OpenAI Codex 账号走本地路由吗不建议。CC Switch 会在本地路由接管模式下阻止切到官方供应商因为用代理访问官方 API 可能带来账号风险。路由主要用于第三方、聚合或协议转换场景。参考链接CC Switch 用户手册添加供应商CC Switch 用户手册代理服务CC Switch 用户手册应用路由CC Switch 用户手册常见问题DeepSeek 官方 API 文档api-docs.deepseek.com中的 Integrate with Codex 章节含wire_api responses要求与模型支持范围可作为直连配置的官方依据。【免费下载链接】cc-switchA cross-platform desktop All-in-One assistant for Claude Code, Codex, OpenCode, OpenClaw, Grok Build Hermes Agent. Only official website: ccswitch.io项目地址: https://gitcode.com/GitHub_Trending/cc/cc-switch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
CC Switch 本地路由实战：让 Codex CLI 用上 DeepSeek 等 Chat 格式供应商
CC Switch 本地路由实战让 Codex CLI 用上 DeepSeek 等 Chat 格式供应商【免费下载链接】cc-switchA cross-platform desktop All-in-One assistant for Claude Code, Codex, OpenCode, OpenClaw, Grok Build Hermes Agent. Only official website: ccswitch.io项目地址: https://gitcode.com/GitHub_Trending/cc/cc-switch本文基于 CC Switch 仓库内文档与源码整理讲解 3.19.1 及以上版本中如何将 DeepSeek、Kimi、智谱 GLM 等暴露 OpenAI Chat Completions 接口的供应商接入 Codex CLI包括需要路由徽章的判断方法、Responses → Chat协议转换的四步链路、本地路由接管的配置步骤以及走直连后用量归属变化的原因。读完后你可以独立完成 Chat 格式供应商的 Codex 接入并看懂~/.codex/config.toml中由 CC Switch 生成的配置字段。先确认你是否还需要这篇攻略适用版本CC Switch 3.19.1 及以上。3.19.1 起有重要变化DeepSeek 预设已改为原生 Responses 直连不再需要本地路由。但这条路由转换的路径并没有作废——它仍是deepseek-v4-pro在官方尚未开通 Codex 集成期间、升级前已保存的供应商以及 Kimi、智谱 GLM 等 Chat 格式供应商的必经之路。判断方法只有一个看 Codex 供应商卡片上有没有需要路由徽章带需要路由徽章这个供应商走 Chat 格式本文全部适用。没有徽章它已经是 Responses 原生直连本文的路由步骤对它没有意义可以直接用。带不支持路由徽章这是官方供应商CC Switch 会阻止它走本地路由见文末常见问题。前端代码中徽章文案就定义在 ProviderCard.tsx分别对应需要路由与不支持路由两种展示状态。徽章由供应商保存时记录的 API 格式决定所以升级 CC Switch不会改变已有供应商的行为。具体到 DeepSeek升级到 3.19.1 之后有三种情况你的情况是否需要路由说明3.19.1 之前保存的 DeepSeek 供应商需要仍带徽章预设改动只影响新建的供应商已保存的配置原样保留想改走直连见下文改造已有的 DeepSeek 供应商3.19.1 之后用预设新建的 DeepSeek不需要直连api.deepseek.com并会拿到 DeepSeek 官方的模型目录想用deepseek-v4-pro官方尚未开通 Codex 集成时需要直连会上游报错必须走 Chat 路由源码中可以看到 3.19.1 之后 DeepSeek 预设的当前形态codexProviderPresets.ts 中name: DeepSeek的预设apiFormat已设为openai_responsesbase URL 为https://api.deepseek.com默认模型为deepseek-v4-flash模型目录中deepseek-v4-flash与deepseek-v4-pro均声明了 1048576 上下文窗口和 low/high/max 三档思考级别。除 DeepSeek 外Kimi、智谱 GLM、SiliconFlow、ModelScope 等大量供应商仍是 Chat 格式本文对它们完全适用——把下文中的 DeepSeek 换成对应预设即可。例如 codexProviderPresets.ts 中Zhipu GLM预设的apiFormat就是openai_chatbase URL 为https://open.bigmodel.cn/api/coding/paas/v4。为什么需要本地路由新版 Codex CLI 面向的是 OpenAI Responses API而很多供应商实际暴露的是 OpenAI Chat Completions 形态也就是/chat/completions。这两种协议的请求体、流式事件和返回结构不同直接把 Chat 接口填进 Codex 配置里常见结果就是模型列表不对、请求 404/400或者流式响应无法被 Codex 正确解析。CC Switch 的做法是让 Codex 始终连本机路由仍以 Responses API 发送请求路由在内部识别当前供应商是否是 Chat 格式再把请求改写成 Chat Completions 发给上游最后把 Chat 响应转换回 Responses 形态返回给 Codex。这条链路主要分成四步Codex 接管时本地配置会被写成http://127.0.0.1:15721/v1并强制保持wire_api responses。Provider 的meta.apiFormat openai_chat会告诉路由真实上游是 Chat Completions。路由把/responses或/v1/responses改写到/chat/completions并把 Responses 请求体转换成 Chat 请求体。上游返回后路由再把 Chat 的 JSON 或 SSE 转回 Codex 能理解的 Responses JSON/SSE。这些步骤在源码中都有对应实现可以逐一印证接管时写wire_api responsescodex_config.rs 中的update_codex_toml_field会把wire_api字段写入[model_providers.current]段若不存在则回退到顶层测试用例wire_api_writes_into_correct_model_provider_section验证了写入位置的正确性。路由端识别 Chat 格式proxy/providers/codex.rs 中对openai_chat、openai_chat_completions等 apiFormat 取值做归一化处理配套的格式转换逻辑位于 transform_codex_chat.rs。本地路由默认端口15721定义在 proxy/types.rs 等服务层代码中接管与切换逻辑集中在 services/provider/mod.rs。供应商原生就是 Responses 的如现在的 DeepSeek 预设第 24 步不发生请求直接发往上游不做任何格式改写。准备工作你需要先准备好三样东西已安装并能启动的 CC Switch。已安装 Codex CLI并至少运行过一次让~/.codex/config.toml目录结构存在。目标供应商的 API Key。以 DeepSeek 为例官方文档写明 OpenAI 兼容 base URL 是https://api.deepseek.com其他供应商常见的是带/v1或更长路径的 base URL例如智谱 GLM 是https://open.bigmodel.cn/api/coding/paas/v4Chat API 路径是/chat/completions。CC Switch 的预设已按这些信息配好请优先使用预设不需要手动拼接口路径。第一步添加 Codex 供应商打开 CC Switch切到顶部的Codex标签点击右上角的加号添加供应商。用预设推荐在预设列表里选中目标供应商填入 API Key保存即可。预设已经内置请求地址、默认模型、模型菜单并会自动设好上游格式Chat 格式的预设保存后卡片上就会出现需要路由徽章。思考参数thinking / reasoning预设已自动配置好不需要手动填。用自定义配置按对方文档填 API Key 和 base URL然后展开表单底部的高级选项把上游格式选为Chat Completions需开启路由。这个下拉共有三个选项上游格式选项含义Responses原生上游原生支持 Responses API直连不转换无需路由Chat Completions需开启路由本文讲的情况由本地路由做 Responses → Chat 转换Anthropic Messages需开启路由上游只提供原生 Anthropic 协议同样由路由转换只有Responses原生不需要开启路由接管另外两个都需要。自定义供应商的思考参数由 CC Switch 按名称与地址自动推断只有在识别不准时才需要展开思考能力手动覆盖。改造已有的 DeepSeek 供应商把上游格式改成Responses原生即可不必删掉重建。下次切换到它时CC Switch 会认出deepseek.com地址并套用 DeepSeek 官方的模型目录freeformapply_patch、GPT-5 harness、low/high/max 思考档与 web_search 都会照常生效。唯一的小差别是上下文窗口供应商自己保存的模型行优先级更高3.19.1 之前存下的1000000会盖掉官方声明的1048576少 4 万多 token。介意的话在高级选项→模型映射里把该行的上下文窗口改成1048576就行或者干脆用预设新建一个。反过来想用deepseek-v4-pro官方尚未开通 Codex 集成时就把上游格式改回Chat Completions。另外直连所用的官方模型目录要求 Codex CLI0.144.0 或更新它带的 freeformapply_patch注册需要这个版本CC Switch 不会替你校验生成的目录文件也会涨到 75 KB 左右因为其中包含完整的 GPT-5 harness 文本。从源码结构看官方模型目录的生成由CC_SWITCH_CODEX_MODEL_CATALOG_FILENAME即cc-switch-model-catalog.json驱动常量定义见 codex_config.rs切换供应商时后端按deepseek.comhost 镜像官方 models.json这一逻辑在 services/proxy.rs 的测试断言cc-switch-model-catalog.json must be created on provider switch中也有体现。第二步开启本地路由并接管 Codex进入设置里的路由页面展开本地路由完成两个开关打开路由总开关启动本地服务。默认地址是127.0.0.1:15721。在路由启用中打开Codex。如果只想让 Codex 走路由可以保持 Claude、Gemini 关闭。接管后CC Switch 会把 Codex 的 live 配置指向本机路由并用占位符管理认证。真实 API Key 仍保存在 CC Switch 的 Provider 配置里由本地路由在转发时注入不需要你把 Key 暴露给 Codex live 配置。对应的 live 配置生成逻辑见 services/provider/live.rs其中注释明确说明了DB 是唯一事实来源SSOTcc-switch-model-catalog.json只是它的投影。路由服务的完整说明可参考用户手册的 代理服务 与 应用路由 两章。第三步切换供应商并重启 Codex回到 Codex 供应商列表点击目标供应商的启用。如果它带需要路由标记而路由没有启动CC Switch 会弹出需要路由服务才能正常使用的提示。切换后建议重启当前 Codex 终端会话。原因是Codex 进程可能已经读取过旧的config.toml。model_catalog_json生成后/model菜单通常需要新进程才能刷新。进入 Codex 后可以用/model查看当前模型是否来自对应预设。随后发一个小问题确认路由面板的请求数增长或者在用量/请求日志里看到 Codex 请求即可。走直连之后用量归属会变这一点值得单独提醒供应商改走直连后它的请求不再经过本地路由按请求计费的代理用量统计也就看不到它了。用量本身不会丢——Codex 的会话日志导入照常记录——但这条路径不携带供应商身份所有没走本地代理的 Codex 用量会一起归入名为Codex (Session)的条目。要区分它们看模型每条用量记录都带着自己的模型 ID用量面板的「模型统计」按模型逐行列出费用与 token 都是分开的。如果你确实需要按供应商维度对账比如比较多个聚合商上的同一个模型那就保持上游格式为 Chat 并开着路由接管。常见问题Codex 报 404 或找不到/responses通常是没有开启 Codex 接管或者你手动把上游 Chat base URL 直接写给了 Codex。检查~/.codex/config.toml是否指向http://127.0.0.1:15721/v1。上游报 404如果用的是内置预设先确认当前供应商确实来自预设并且 Codex 路由已启用。只有在使用自定义供应商时才需要额外检查 base URL它应该是对方文档给出的服务端点而不是带/chat/completions的完整接口路径。切到deepseek-v4-pro后上游报错DeepSeek 官方尚未为该模型开通 Codex 集成官方预计 2026 年 8 月初。把这个供应商的上游格式改回Chat Completions需开启路由并开启路由接管即可——这正是 3.19.1 之前 DeepSeek 走的路径路由的 Responses→Chat 转换照常支持 pro。或者改用deepseek-v4-flash它是预设默认值不受影响。/model看不到供应商的模型保存供应商后重启 Codex。CC Switch 会生成cc-switch-model-catalog.json并把路径写入model_catalog_json但正在运行的 Codex 进程不一定会热加载模型目录。目前 Codex app 不支持多模型选择默认使用配置的第一个模型。开了路由但请求仍走错供应商确认三处状态一致Codex 标签下当前供应商正确本地路由服务正在运行路由启用里 Codex 开关已打开。可以用官方 OpenAI Codex 账号走本地路由吗不建议。CC Switch 会在本地路由接管模式下阻止切到官方供应商因为用代理访问官方 API 可能带来账号风险。路由主要用于第三方、聚合或协议转换场景。参考链接CC Switch 用户手册添加供应商CC Switch 用户手册代理服务CC Switch 用户手册应用路由CC Switch 用户手册常见问题DeepSeek 官方 API 文档api-docs.deepseek.com中的 Integrate with Codex 章节含wire_api responses要求与模型支持范围可作为直连配置的官方依据。【免费下载链接】cc-switchA cross-platform desktop All-in-One assistant for Claude Code, Codex, OpenCode, OpenClaw, Grok Build Hermes Agent. Only official website: ccswitch.io项目地址: https://gitcode.com/GitHub_Trending/cc/cc-switch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
