1. Codex 切换模型只显示「自定义」是怎么回事如果你正在用 CC-Switch 管理多个模型供应商给 Codex 配好了 DeepSeek 的 API Key结果打开 Codex 桌面端点击右下角切换模型时下拉框里只孤零零地显示「自定义」三个字看不到deepseek-chat、deepseek-reasoner这些具体模型名——这不是你配置写错了而是 Codex 桌面端 UI 层的一个判断逻辑在作怪。Codex 桌面端的模型选择器并不是直接读取 CC-Switch 的供应商列表它有一套自己的「放行规则」只有当它检测到本地存在官方登录身份时才允许在切换处展示自定义模型。换句话说CC-Switch 负责把请求转发到 DeepSeek但 Codex 的 UI 需要一份官方登录态来「解锁」自定义模型的显示权限。很多人只配了 CC-Switch 的供应商和 Key漏掉了官方登录这一步于是模型名就被折叠成了「自定义」。这个问题适合已经用 CC-Switch 管理多模型、对config.toml和 API Key 配置不陌生的开发者。下面我会给出可复制的config.toml骨架、TaoToken 统一 Key 的接入步骤以及用codex debug models验证自定义模型是否正常显示的动作帮你把「自定义」还原成真实的模型名。2. 用 TaoToken 统一 Key 接入前的准备在动手改配置之前先把「Key 从哪来」这件事理顺。我试过把每个供应商的 Key 分散写在不同的配置文件里结果切换模型时经常对不上号后来改成用 TaoToken 统一管理 KeyCC-Switch 里只维护一份凭据省心很多。TaoToken 是一个面向开发者的模型接入平台你可以把它理解成一个「统一入口」通过它拿到一个 API Key就能在 CC-Switch 里配置多个模型供应商Codex 侧只需要认这一个 Key。它的官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 这个地址不加 UTM 参数配置时直接用。你需要提前准备的东西不多一个 TaoToken 账号、在控制台生成的 API Key、已经装好的 CC-Switch 和 Codex 桌面端。如果你还没生成 Key可以先去控制台的 API Keys 页面创建一个地址是 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。生成后先复制保存后面配置config.toml和 CC-Switch 都要用到。这里有个容易踩的坑TaoToken 的 Key 是统一凭据不要把它和 DeepSeek 官方 Key 混用。CC-Switch 里配置供应商时Base URL 指向 TaoToken 的 API 端点Key 填 TaoToken 生成的这一份模型名按 DeepSeek 的实际名称填写。这样 Codex 发出的请求会先到 CC-Switch再由 CC-Switch 带着 TaoToken 的 Key 转发出去。3. 可复制的 config.toml 骨架与 CC-Switch 配置这一节是核心操作部分。Codex 的配置文件默认在~/.codex/config.tomlCC-Switch 的供应商配置则通过它的界面或本地配置文件管理。下面给出一个可以直接复制修改的config.toml骨架重点是把模型供应商指向 CC-Switch 的本地路由。# ~/.codex/config.toml # Codex 侧配置骨架请求统一走 CC-Switch 本地路由 [model] # 默认使用的模型切换处会读取这里 default deepseek-chat [model_providers.ccswitch] # 供应商名称CC-Switch 里保持一致 name cc-switch # 指向 CC-Switch 的本地路由地址 base_url http://127.0.0.1:你的CC-Switch端口/v1 # 这里填 TaoToken 统一 Key api_key sk-你的TaoTokenKey [model_providers.ccswitch.models] # 声明可用模型切换处据此展示 deepseek-chat {} deepseek-reasoner {}几个参数需要你按实际情况替换。base_url里的端口要和你 CC-Switch 里设置的本地路由端口一致常见的是3000或8080具体看 CC-Switch 的「路由接管」设置页。api_key填 TaoToken 控制台生成的那份 Key。models段里声明的模型名就是切换处应该显示出来的名字。CC-Switch 侧的配置要点是新建一个供应商类型选自定义或 OpenAI 兼容Base URL 填https://taotoken.net/apiAPI Key 填 TaoToken 的 Key模型列表里加上deepseek-chat和deepseek-reasoner。然后确认这个供应商的「本地路由 / 路由接管」开关是打开的——这是让 Codex 的请求真正走 CC-Switch 代理的前提很多人漏掉这一步结果 Codex 根本没连上 CC-Switch。配置完成后还有一步不能省在 Codex 桌面端登录一次官方 ChatGPT 账号。这一步会生成~/.codex/auth.json里面存着官方登录凭据。Codex 的 UI 层就是靠这个文件判断「是否允许展示自定义模型」。保留官方登录态给 UI 放行实际 API 请求仍然由 CC-Switch 转发到 DeepSeek两者互不冲突。登录完成后彻底退出 Codex 桌面端——不是最小化而是完全退出进程——再重新打开。4. 用 codex debug models 验证自定义模型是否显示配置改完、Codex 重启之后先别急着在 UI 里点。打开终端跑一条命令确认模型列表是否被正确读取codex debug models这条命令会输出 Codex 当前识别到的模型列表。如果输出里能看到deepseek-chat和deepseek-reasoner说明配置文件读取正常问题如果还存在就集中在 UI 层按上一节的官方登录态和重启步骤再检查一遍。如果输出里看不到这两个模型那问题在配置侧重点检查 CC-Switch 的供应商配置和config.toml的models段。实测下来一个典型的成功输出会类似这样Available models: - deepseek-chat - deepseek-reasoner - (default) deepseek-chat看到这个列表后再打开 Codex 桌面端点击输入框右下角的模型切换处DeepSeek 的模型名应该正常显示而不是「自定义」。如果此时切换处仍然显示「自定义」但codex debug models能看到模型那基本可以确定是官方登录态过期或 UI 缓存问题重新登录一次官方账号并彻底重启即可。如果你想在配置过程中直接验证 TaoToken 的 Key 是否可用可以先用模型对话页面发一条测试请求地址是 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 。确认 Key 能正常返回结果再回到 Codex 侧排查能少走很多弯路。5. 本篇常见错误排查配置过程中有几个高频问题我按现象和原因整理成对照表方便你快速定位。现象可能原因处理动作切换处只显示「自定义」缺少官方登录态auth.json登录一次官方账号彻底重启 Codexcodex debug models无输出模型config.toml的models段未声明补上deepseek-chat等模型名请求报 401 / 鉴权失败Key 填错或 Base URL 不对确认填的是 TaoToken Key端点用https://taotoken.net/api用了几天后又看不到模型官方登录态过期重新登录官方账号一次CC-Switch 路由不生效本地路由 / 路由接管未开启在 CC-Switch 里打开该开关端口冲突连不上base_url端口与 CC-Switch 不一致核对 CC-Switch 路由设置页的端口其中「官方登录态过期」这个坑最隐蔽。它的表现是刚配好时一切正常过了几天切换处又变回「自定义」。原因就是auth.json里的凭据有有效期过期后 UI 层不再放行自定义模型。解决办法很简单重新登录一次官方账号即可不需要重配 CC-Switch。另一个常见误区是把 TaoToken 的 Key 填到了 Codex 的官方配置段里。Codex 侧只需要认 CC-Switch 的本地路由Key 由 CC-Switch 统一携带。如果你在config.toml里同时写了官方 Key 和 TaoToken Key容易出现请求走错通道的情况。保持「Codex 指向 CC-SwitchCC-Switch 携带 TaoToken Key」这条链路清晰问题会少很多。如果你在排查过程中需要确认接入文档里的参数细节可以查阅 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有 Base URL、鉴权方式等说明对照着检查配置项能更快定位。6. 长期编码场景下的 Key 与配置管理如果你不只是临时切一次模型而是长期用 Codex 做编码、跑 Agent 任务那 Key 和配置的管理方式值得再优化一下。频繁手动改config.toml容易出错尤其是多模型来回切换时。一个实用的做法是把 CC-Switch 当作「配置中枢」所有供应商的 Base URL 和 Key 都在 CC-Switch 里维护Codex 的config.toml只保留指向本地路由的最小配置。这样新增或更换模型时只动 CC-Switch 一处Codex 侧不用反复改。TaoToken 的统一 Key 正好适配这种模式一份 Key 覆盖多个模型供应商CC-Switch 里配置一次即可。对于需要长时间运行编码任务的场景可以了解一下 Coding Plan地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 它面向的就是这类持续编码和 Agent 工作流。配合 CC-Switch 的路由接管Codex 发出的请求会稳定地经过统一入口切换模型时 UI 层也能正常展示模型名不会退化成「自定义」。最后提醒一个操作习惯每次改完config.toml或 CC-Switch 配置后先跑codex debug models确认模型列表再彻底重启 Codex 桌面端。这个顺序能帮你把「配置问题」和「UI 问题」分开排查效率会高很多。