
最近在捣鼓 AI 编程助手的时候发现一个挺折腾人的问题Codex 和 Claude Code 这俩大家常用的命令行编程工具默认都把自己绑定在固定的模型来源上。Codex 绝大多数情况下是走 OpenAI 那一套推理接口Claude Code 则习惯性连 Anthropic 自家的服务。想换个模型来跑任务比如试试 DeepSeek、Qwen 或者 GLM要么去翻官方文档找环境变量要么手动改配置然后重启会话改完这头那头又对不上来回折腾一上午可能还没跑通一条指令。后来我找到一个只有 15MB 的小工具叫 ccswitch把 Codex 和 Claude Code 的模型来源集中管理起来想换模型直接改一条配置就能完成切换实测下来非常稳。这篇文章就聊聊这个工具的核心思路、完整配置方法以及我在接入 DeepSeek、Qwen、GLM 这些第三方模型时踩过的坑和排查经验。适合正在用或者打算用 Codex、Claude Code又想灵活切换模型来源的朋友参考。1. 为什么需要一个小工具来做模型切换1.1 两个 CLI 工具的模型绑定逻辑Codex 是 OpenAI 推出的命令行编程代理登录之后默认会走 OpenAI 账号的模型权限模型列表、上下文窗口、计费方式都跟账号绑定。Claude Code 是 Anthropic 的命令行编程工具默认走 Claude 订阅或者 Claude API Key 的通道模型行为也和 Anthropic 账号体系深度绑定。这就带来一个很实际的麻烦如果你想在 Codex 里用 DeepSeek 的模型在 Claude Code 里用 Qwen 的模型官方工具自身并不提供图形化的“模型来源切换面板”。你需要去修改每个工具各自的配置文件有些藏在~/.codex下有些是claude_code的 settings.json还要搞清楚每个字段的作用。更别提一个项目用 Codex、另一个项目用 Claude Code、第三个项目想混着来的时候配置目录一多手一抖就可能把环境变量写串。1.2 为什么用“集中配置 本地转发”的方式ccswitch 的思路很直接不直接去改 Codex 和 Claude Code 的内部逻辑而是在本地起一个轻量级转发服务把两个工具发出去的模型请求统一接收下来再根据你事先写好的规则转发到对应的模型供应商接口。这种做法的好处有三点。第一不动原有工具的认证体系Codex 和 Claude Code 仍然以为自己在跟官方服务通信兼容性最好。第二所有模型来源集中在一个配置文件里管理切换模型只需要改一行配置或者在交互界面里选一下。第三本地转发的延迟开销非常低对于一个 15MB 的二进制工具来说日常使用几乎感觉不到性能损失。打个比方这就相当于在 Codex 和 Claude Code 身后加了一个“调度总机”。原本两台电话机只能各自连各自部门的座机号想联系别的部门得先挂了重新拨号现在中间加了一个总机你只需要告诉总机这次想找谁剩下的线路切换都由它搞定。2. 看懂 ccswitch 的核心机制与配置文件2.1 本地转发服务的请求处理流程ccswitch 启动后会在本机监听一个端口比如127.0.0.1:3456。Codex 和 Claude Code 的模型请求地址会被配置成这个本地端口请求到达后ccswitch 会读取当前生效的模型供应商配置然后携带对应的 API Key 和模型参数向真正的模型服务端发起请求。这个过程有几个关键点需要注意。第一ccswitch 本身只做“转发”和“格式适配”它不消耗大模型算力也不需要运行什么重型服务所以占用内存非常小。我把它挂在后台跑一整天资源占用也几乎可以忽略。第二由于很多第三方模型服务兼容 OpenAI 的接口格式ccswitch 在处理 Codex 的转发时往往只需要改 base_url 和 API Key处理 Claude Code 时则需要兼容 Anthropic 的消息格式这一步是工具内部自动完成的。第三如果你在本地跑着 LM Studio、Ollama 这类本地模型服务ccswitch 同样能把请求转发到http://127.0.0.1:1234/v1这样的本地地址让 Codex 和 Claude Code 直接驱动本地模型。2.2 settings.json、config 文件与模型映射的关系ccswitch 的模型供应商配置一般以 JSON 格式保存在配置目录中不同版本的配置文件字段名可能略有差异但核心的就几个provider供应商名称比如deepseek、qwen、glm、lmstudioapiKey对应供应商的 API KeybaseUrl供应商接口地址本地模型就填http://127.0.0.1:1234/v1model默认模型名比如deepseek-chat、qwen-plus、glm-4-plusenabled是否启用该供应商配置当你需要切换模型时不需要动 Codex 和 Claude Code 本身只需要修改 ccswitch 的默认供应商配置。这个设计非常实用因为你平时真正需要记住的只是一个配置文件的位置和几个字段的含义。前前后后折腾两周我最大的体会是与其去记每个工具各自的环境变量不如把所有模型配置集中到 ccswitch 一个文件里。3. 实操把 DeepSeek、Qwen、GLM 接进 Codex 和 Claude Code3.1 获取并启动 ccswitchccswitch 的发布包通常在官方项目主页的 Releases 页面可以找到下载对应你操作系统的版本即可。它本身是一个可执行文件没有复杂的安装依赖。下载后建议放到一个固定目录比如~/bin/ccswitch然后给它加可执行权限。Windows 用户直接拿到 exe 文件后在命令行里调用即可。启动方式也很简单直接执行./ccswitch正常情况下它会在终端里打印出监听的本地地址例如http://127.0.0.1:3456。看到这个输出就说明本地转发服务已经起来了。这个时候还不需要关闭终端窗口因为它要一直在后台运行才能接收 Codex 和 Claude Code 的请求。3.2 配置 DeepSeek 作为 Codex 的模型来源DeepSeek 是很多开发者接第三方模型时的第一站原因是它的 API 兼容 OpenAI 格式配置起来非常省心。以 DeepSeek 为例我们可以在 ccswitch 的配置文件中添加{ provider: deepseek, apiKey: sk-你的DeepSeek密钥, baseUrl: https://api.deepseek.com/v1, model: deepseek-chat, enabled: true }之后在 Codex 这边需要把模型请求的地址指向本地的 ccswitch 服务。不同版本修改方式不同常见的是在 Codex 的配置里增加环境变量或指定 base_url让它指向http://127.0.0.1:3456。配置完成后再启动 Codexcodex在对话里随便问一个问题如果 Codex 能正常回话说明它已经通过 ccswitch 转发到了 DeepSeek 接口。我实际测试下来DeepSeek 的响应速度和服务稳定性都还不错日常写代码、改 bug 完全够用。3.3 接入 Qwen 和 GLM 的配置差异Qwen 和 GLM 这两家同样提供了兼容 OpenAI 格式的接口但有几个细节需要注意。Qwen 的 base_url 一般是通义千问的官方接口地址模型名通常填qwen-plus或qwen-turbo具体以供应商控制台上展示的模型名为准。GLM 这边目前常见的模型名是glm-4-plus、glm-4-flash这类接口地址同样在控制台里能查到。在 ccswitch 里接入方式跟 DeepSeek 几乎一致{ provider: qwen, apiKey: sk-Qwen密钥, baseUrl: https://dashscope.aliyuncs.com/compatible-mode/v1, model: qwen-plus, enabled: true }{ provider: glm, apiKey: sk-GLM密钥, baseUrl: https://open.bigmodel.cn/api/paas/v4, model: glm-4-plus, enabled: true }重点提示一下model字段的值一定要跟你供应商账号实际开通的模型一致否则请求会报model not found之类的错误。我遇到过不少把qwen-plus写成qwen-max导致调用失败的情况排查到最后发现只是模型名对不上。3.4 在 Claude Code 里切换模型来源Claude Code 的配置方式跟 Codex 略有不同但它也支持通过 settings.json 来指定接口来源。你需要先找到 Claude Code 的配置目录一般是用户目录下的.claude文件夹里面会有settings.json。修改时把请求地址指向 ccswitch 的本地服务即可配置好的效果等同于让 Claude Code 的所有消息请求先经过本地转发服务。下面是一个常见的修改示意{ apiBaseUrl: http://127.0.0.1:3456, apiKey: 在ccswitch里配置的密钥 }当然不同版本的 Claude Code 字段名可能不一样有的版本可能会在登录状态或环境变量层面处理但这并不影响整体思路核心就是让 Claude Code 的请求走 ccswitch。修改后建议先重启 Claude Code再执行一个简单的对话请求确认接口配置生效。如果没有任何回话先检查 ccswitch 的终端窗口有没有打印转发日志日志是最直接的排查线索。4. 高频报错与排查技巧实录4.1 本地转发启动失败failed while handling codex endpoint /responses这个报错出现的场景很典型Codex 请求已经打到了 ccswitch但 ccswitch 在处理/responses这个端点时抛了异常。我在第一次配置时也遇到了检查了半天才发现是端口被占用了。因为 ccswitch 默认监听某个固定端口如果电脑上其他服务抢先占用了这个端口或者上一次启动的 ccswitch 进程没有退出新的请求就会投递失败随之报错。排查步骤建议按这个顺序来先确认 ccswitch 进程是否还活着终端窗口是否还开着。确认监听端口是否被占用比如执行lsof -i :3456查看端口状态。确认供应商的 baseUrl 是否填写正确有些第三方接口要求/v1结尾漏掉之后路径对不上就会报错。确认 API Key 是否有效尤其是复制的时候容易把空格或者换行符带进去。其中一个很隐蔽的坑是Codex 请求时会在路径后面拼接/v1或者/responses如果你的供应商接口本身带了/v1之后再拼一次就会形成双路径导致 404 或者异常。解决办法是仔细检查供应商文档看它给的 base_url 是根域还是完整路径。4.2 Claude Code 提示 your organization has disabled claude subscription access这个提示字面意思是“你的组织已经禁用了 Claude 订阅访问”。如果你遇到这个提示跟 ccswitch 本身关系不大更多是 Claude Code 登录的账号权限问题。有些用户用的是组织账号但组织管理员出于统一管控的考虑会关闭成员对 Claude 订阅的访问权限。碰到这种情况请先确认自己的账号类型。个人账号通常不会出现这个限制组织账号则需要检查组织层面的订阅策略。如果业务上确实需要用 Claude Code可以联系组织管理员开启相应权限或者改用单独的 API Key 计费模式。在 ccswitch 配置中也可以把 provider 指向其他兼容 Anthropic 接口的第三方服务从而绕过对默认 Claude 订阅的依赖。这里我不建议去尝试任何“破解”或绕过组织限制的方法一方面不合规另一方面也容易导致账号异常。安全合规地用正规渠道才是长期稳定的做法。4.3 想让 Claude Code 调用 LM Studio 的本地模型这是一个让我折腾了最久的场景。LM Studio 是一个本地模型管理工具启动后会在本机起一个兼容 OpenAI 格式的服务默认地址一般是http://127.0.0.1:1234/v1。理论上只要让 ccswitch 把请求转发到这个地址Claude Code 就能驱动本地模型。实际配置时需要注意两点。第一LM Studio 的模型名必须跟你在软件里加载的模型完全一致一个字符都不能差比如qwen2.5-7b-instruct写成qwen2.5-7b就很可能直接报错。第二本地模型的上下文窗口和推理能力跟云端模型差距很大Claude Code 某些功能行为会明显变慢如果你的电脑配置一般建议选择 7B 级别以下的小模型。4.4 Codex 无法加载组织设置、登录不上该怎么办这类问题大多不是模型配置的问题而是 Codex 登录态、本地缓存或网络连通性导致的。遇到“无法加载组织设置”时可以试着先退出 Codex 进程清掉本地的登录缓存目录然后重新登录。注意一点登录态过期后模型请求不一定立刻报错可能表现为对话响应延迟或者某些功能不可用。如果清缓存重新登录仍然无效建议检查 Codex 版本或者看看是否有系统代理设置干扰了请求路径。4.5 常见问题速查表我整理了一张高频问题速查表方便后续排查直接对照现象可能原因解决思路codex 请求报 failed while handling endpoint端口被占用/供应商路径拼接错误检查 ccswitch 进程与端口占用检查 baseUrl 是否多余拼接Claude Code 提示组织禁用访问组织订阅权限被关闭联系管理员开通或改用 API Key 方式调用 LM Studio 本地模型报错模型名不一致确认 LM Studio 中加载的模型名与配置完全一致切换模型后仍然走旧模型配置文件未生效/未重启修改配置后重启 ccswitch 和编码工具API Key 无效密钥复制时混入空格/换行重新复制确保无多余字符model not found模型名不在供应商支持列表到供应商控制台确认模型名4.6 我个人的排查习惯踩过几次坑之后我现在遇到问题会先看 ccswitch 终端窗口里的转发日志因为日志里能看到实际请求的路径、目标地址和响应状态码比猜测省时间多了。其次是严格控制配置文件的修改范围一次只改一个字段验证生效后再改下一个。如果一次性把 provider、model、baseUrl 全改了出了问题反而不容易定位。另外我会把常用的几套模型配置分别存成备份文件哪天改坏了直接恢复五秒钟就能回到稳定状态。这个 15MB 的小工具本身不难难的是理解它背后的转发逻辑Codex 和 Claude Code 只是“发件人”真正的“收件分配”全靠 ccswitch 这个本地总机。弄懂这一点之后无论以后新出什么编程 CLI 或者模型供应商配置思路都是相通的——先让工具的请求指向本地转发服务再去本地转发服务里调整目标模型供应商。就像我平时说的模型来源这件事最好还是握在自己手里比较踏实。