1. Codex 桌面端模型名显示「自定义」到底卡在哪如果你正在用 Codex 桌面端接 DeepSeek命令行里/model一切正常、请求也确实打到了正确的模型但桌面端「切换模型」下拉框里死活只显示「自定义Custom」那这篇就是写给你的。我自己在 Windows 11 上折腾过一轮Codex 桌面端 26.812.11052内部版本约 0.147、cc-switch v3.19.2模型是 DeepSeek V4 Flash / V4 Pro全程纯 API-Key 模式没有官方 ChatGPT 账号。现象很典型CLI 正常桌面端模型名不显示推理档位选择器也是空的。核心检索词先摆出来Codex、DeepSeek、cc-switch、model_catalog_json、camelCase。问题不在网络、不在 Key、也不在 base_url而是卡在配置层的一个字段命名契约上——Codex ≥ 0.144 读取模型目录时只认 camelCase 字段而 cc-switch 导出的model_catalog_json是 snake_case。字段对不上桌面端解析不出模型列表于是统一回退成「自定义」。这篇会给你一份可复制的config.toml骨架、一份手工转好的 camelCase catalog 模板、逐步验证动作以及几个高频报错的排查路径。适合谁本地用 Codex 桌面端 cc-switch 接第三方模型、遇到模型名不显示或推理档位异常的人。下面按「问题定位 → 前置准备 → 配置骨架 → 验证 → 排错 → 长期方案」的顺序走你可以直接跳到需要的段落。2. 前置TaoToken 统一 Key 与本地通道的关系在动手改 catalog 之前先把通道这层理清楚否则后面排查会分不清是「配置字段错」还是「请求根本没发出去」。我用的思路是Codex 桌面端只负责读config.toml和 catalog 文件真正的模型请求走本地路由再由本地路由转发到统一的 API 通道。TaoToken 在这里扮演的就是那个统一 Key / API 通道的角色官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。为什么强调「统一通道」因为 Codex 桌面端 cc-switch 的组合里最容易出问题的不是转发本身而是桌面端对模型元数据的解析。只要通道层能正常返回CLI 就能跑通桌面端额外多读了一层 catalog字段命名不对就显示异常。所以你要先把 Key 和通道准备好再去调 catalog。拿 Key 的路径很直接进控制台创建 API Key然后按接入文档把 base_url 指到统一入口。控制台地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite API Keys 管理在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。如果你后面要长期跑编码或 Agent 任务可以看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。注意本地路由地址比如http://127.0.0.1:15721/v1是 cc-switch 在你机器上起的转发端口和 TaoToken 的 API 入口是两层。config.toml里的base_url填本地路由本地路由再指向统一通道别把这两层写混。3. 可复制的 config.toml 骨架与 camelCase catalog 模板这一节是重点直接给能用的片段。先看~/.codex/config.toml的骨架字段含义我用注释标了你按自己的模型名替换即可。# ~/.codex/config.toml model_provider custom model deepseek-v4-flash # 关键指向手工转好的 camelCase catalog 文件 model_catalog_json cc-switch-model-catalog.json model_reasoning_effort high disable_response_storage true [model_providers.custom] name deepseek # 本地路由地址由 cc-switch 提供 base_url http://127.0.0.1:15721/v1 wire_api responses requires_openai_auth true然后是核心~/.codex/cc-switch-model-catalog.json。cc-switch v3.19.2 生成的是 snake_case桌面端读不出来所以你要手工转成 camelCase。下面这份模板可以直接抄两个模型都给了{ models: [ { displayName: DeepSeek V4 Flash, slug: deepseek-v4-flash, contextWindow: 1048576, maxContextWindow: 1048576, additionalSpeedTiers: [deepseek-v4-flash], serviceTiers: [], supportedReasoningEfforts: [ { effort: none }, { effort: high } ], defaultReasoningEffort: high, supportedInApi: true, visibility: list, priority: 1000 }, { displayName: DeepSeek V4 Pro, slug: deepseek-v4-pro, contextWindow: 1048576, maxContextWindow: 1048576, additionalSpeedTiers: [deepseek-v4-pro], serviceTiers: [], supportedReasoningEfforts: [ { effort: none }, { effort: high } ], defaultReasoningEffort: high, supportedInApi: true, visibility: list, priority: 1000 } ] }字段对照表放这里方便你逐项核对这是最容易踩坑的地方snake_casecc-switch 导出camelCaseCodex ≥ 0.144 契约说明display_namedisplayName下拉框显示的名字supported_reasoning_levelssupportedReasoningEfforts推理档位列表default_reasoning_leveldefaultReasoningEffort默认档位context_windowcontextWindow上下文窗口max_context_windowmaxContextWindow最大上下文窗口additional_speed_tiersadditionalSpeedTiers影响模型是否进切换菜单supported_in_apisupportedInApi是否在 API 中可用关于additionalSpeedTiers填什么这是很多人卡住的点。官方 schema 里它标注为Arraystring且已 Deprecated建议改用serviceTiers。但实测下来桌面端模型切换 UI 仍然依赖additionalSpeedTiers判断「这个模型是否可切换」空数组时模型不会进切换菜单。所以我的做法是把模型自己的 slug 塞进去同时保留serviceTiers为空数组两个字段都写上兼容新旧解析逻辑。提示手工改完 catalog 后一定要完全退出 Codex 桌面端再重启并新开一个线程。桌面端有缓存只关窗口不退出进程改动不生效。4. 验证请求与成功结果配置改完别急着看界面先用命令行确认通道层是通的这样能把「配置字段问题」和「请求发不出去」分开。第一步确认本地路由活着curl -s http://127.0.0.1:15721/v1/models如果返回里有deepseek-v4-flash和deepseek-v4-pro说明 cc-switch 的转发层正常。第二步直接打一次对话请求确认 Key 和通道没问题curl -s http://127.0.0.1:15721/v1/responses \ -H Content-Type: application/json \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -d { model: deepseek-v4-flash, input: 用一句话说明你是什么模型 }返回里能看到模型正常回复就说明通道层完全 OK。第三步才是看桌面端重启 Codex 桌面端打开「切换模型」下拉框正常情况下应该能看到DeepSeek V4 Flash和DeepSeek V4 Pro两个名字推理档位选择器也能在none/high之间切。如果这一步还是「自定义」回到第 5 节排查。我实测下来手工转 camelCase 之后模型名能正常显示推理档位也能切换。但有一个前提桌面端的登录门控。Codex 桌面端会按登录身份OAuth决定是否放行自定义模型官方已经把「桌面 GUI 暴露自定义供应商模型」标记为 not planned。也就是说没有官方账号时界面显示这块可能仍然受限具体表现因版本而异。如果界面死活不显示但 CLI 正常那大概率是撞到了这个门控不是你配置写错了。5. 本篇常见报错排查这一节按报错现象分类你对号入座。现象一下拉框只有「自定义Custom」模型名不显示。九成是 catalog 字段还是 snake_case。打开cc-switch-model-catalog.json搜一下有没有display_name这种下划线命名有就说明没转成功。cc-switch 重新生成会覆盖你的手工修改所以每次在 cc-switch 里保存供应商后都要重新检查一遍字段命名。现象二模型名显示了但推理档位选择器是空的。检查supportedReasoningEfforts是不是写成了supported_reasoning_levels以及defaultReasoningEffort有没有漏。档位列表里每个元素是对象形如{ effort: high }别写成纯字符串数组。现象三模型名显示了但切换菜单里点不动。这是additionalSpeedTiers为空导致的。把它填成模型自己的 slug比如[deepseek-v4-flash]再重启。现象四改了 catalog 完全没反应。先确认config.toml里model_catalog_json的路径对不对。它可以是相对路径相对于~/.codex/也可以是绝对路径。如果你把文件放在了别处写相对路径会找不到。其次确认 Codex 桌面端进程真的退干净了任务管理器里看一眼有没有残留。现象五CLI 正常但桌面端请求失败。这种多半是wire_api或requires_openai_auth和你的通道不匹配。wire_api responses对应 Responses 接口如果你的通道只支持 chat completions就要改。requires_openai_auth true在纯 API-Key 模式下通常要保留具体看接入文档的说明。注意cc-switch 每次重新生成 catalog 都会把字段打回 snake_case这是 issue #5182 的直接原因。在官方修复前手工转 camelCase 是临时 workaround记得在 cc-switch 升级后重新验证。6. 长期方案与 CTA如果你只是偶尔切模型手工维护 catalog 还能忍但如果你要长期跑编码或 Agent 任务每次 cc-switch 重新生成都要手工转字段迟早会烦。这时候更省事的做法是把模型对话、编码计划这些能力走统一入口减少本地这层 catalog 的依赖。验证模型是否可用可以直接用模型对话页面试https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 。长期编码或 Agent 场景看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。如果你在配 Claude Code 这类工具Anthropic 兼容入口在 https://taotoken.net/claudecode-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecode-anthropicutm_campaignrewrite 。回到 Codex 桌面端这件事我的建议是把config.toml和 camelCase catalog 当成一份「本地补丁」维护单独存一份模板cc-switch 每次重新生成后直接覆盖。字段对照表存好下次升级 Codex 或 cc-switch 时先核对displayName、supportedReasoningEfforts、additionalSpeedTiers这三个最容易变的字段。桌面端登录门控那块短期内没有官方账号确实绕不开能接受就用 CLI不能接受就等官方放开别在这上面耗太多时间。