The 'gpt-6.1-sol' model is not supported when using Codex with a ChatGPT account 怎么解决：同一账号 CLI 0.158.0 被拒、0.159.0 正常

这句 HTTP 400 的意思是：用 ChatGPT 账号登录的 Codex 服务端拒绝了这次请求里的模型 ID，但它没有说原因是套餐、灰度，还是发请求的客户端太旧。它不能证明 Plus 用不了 GPT-6.1 Sol。截至 2026 年 11 月 11 日，OpenAI 帮助中心写的是 GPT-6.1 Sol 正在向符合条件的付费套餐灰度推出，可用性取决于套餐、工作区设置和灰度进度；而同一句话还会原样出现在已退役的 gpt-5.5、拼错的 ID 和大写的 GPT-6.1-Sol 上。

所以先看引号里的 ID。它是已退役的 gpt-5.5、拼错或带大写字母的 ID，改 ID 就行；它是 gpt-6.1-sol，或 gpt-6.1-terra、gpt-6-sol 这类现行 ID，就把真正发请求的程序更新到最新。Codex CLI 用 npm install -g @openai/codex@latest 更新（截至 11 月 11 日最新是 0.167.1），再用 codex app-server daemon update --from-cli --yes 更新后台服务；经 CC Switch 这类代理转发的，要升级的是代理本身。2026 年 11 月 11 日在同一个 Pro 账号上，Codex CLI 0.158.0 收到这句报错，0.159.0 和 0.166.0 都正常回复。更新之前可以先切到 gpt-6-sol 继续工作，它在同一账号的 0.158.0 上也能用；Free 和 Go 账号用 gpt-6-luna。

例外是客户端已经最新，codex debug models 里仍然没有 gpt-6.1-sol（这是按服务端随客户端版本下发目录的现象做的推断，不是 OpenAI 给的诊断方法）。Plus 和 Business Premium 用户各报告过 CLI 0.163.0 上仍被拒的案例，至今没有解法。这时原因在账号一侧，例如套餐到期、刚改过套餐、Enterprise 或 Edu 管理员没有开启、灰度还没轮到；重装、重新登录、删缓存都没用，先换模型，再找 OpenAI 支持或工作区管理员。

gpt-6.1-sol 这句 400 说明了什么：服务端拒绝了 ID，没说为什么

这句话是服务端的固定模板，被拒的是哪个 ID，它就把哪个 ID 填进引号。2026 年 11 月 11 日用 Codex CLI 0.166.0 和一个 Pro 账号试过：已退役的 gpt-5.5、随手编的 gpt-6.1-sol-typo、大小写写错的 GPT-6.1-Sol，得到的都是同一句话，只有引号里的 ID 不同；作为对照的 gpt-5.6-sol 正常回复。所以单看这句话，分不出是模型没开放给你，还是 ID 本身就不对。

不同客户端打印出来的样子不一样，判断时只看引号里的 ID 和 400 状态码。CLI 0.166.0 在 ERROR: 后面只打印这一句；0.157.1 和 0.158.0 打印整段 JSON，里面带 "code":"model_not_found"；经代理转发时还会看到 {"detail":"The 'gpt-6.1-sol' model is not supported when using Codex with a ChatGPT account."} 这种写法。几种写法说的是同一件事。

OpenAI 的 Codex 工作区模型可用性文档把 ChatGPT 登录的桌面 App、CLI 和 IDE 扩展能用哪些模型归结为两个条件：所用客户端支持这个模型，以及登录的 ChatGPT 身份有权限。这句报错两种情况都会出现，却不告诉你是哪一种。截至 2026 年 11 月 11 日，OpenAI 帮助中心的 ChatGPT Work and Codex 文章、GPT-6 模型说明和 Codex 模型文档都没有解释这句话，也没有公布 GPT-6.1 Sol 的最低 CLI 版本；openai/codex 仓库里与这句报错相关的 36 个 issue（共 158 条评论）中，也没有一条来自 OpenAI 成员的回复。最接近的官方数字是同期其他模型的门槛：GPT-6.1 Terra 要求 Codex CLI 0.159.0 或更新，GPT-6 Astra 要求 0.153.0，GPT-5.6 要求 0.144.0。

先判断是哪种情况：看引号里的 ID、发请求的程序和版本

大多数情况用三样东西就能分开：引号里的 ID；实际发请求的是哪个程序（终端里的 codex、后台服务、桌面 App、IDE 扩展、CC Switch 之类的代理）以及它的版本；同一账号换个程序能不能用。从上往下对照，命中哪一行就先做那一行的事，每一行的依据在后面对应的小节。

表里“0.158.0 或更早”来自下文同一账号的实测，不是 OpenAI 公布的数字。

引号里的 ID 不是 gpt-6.1-sol：退役、拼错、大写才要改 ID

引号里的 ID 不是 gpt-6.1-sol 时，先分清它属于哪一类，两类的去向不同。第一类是要改 ID 的：已退役的 ID、拼错或简写的 ID、带大写字母的 ID，换什么客户端版本、什么套餐都会被拒。大写多出现在代理的模型映射里：CC Switch 作者 farion1231 在 2026 年 10 月 16 日解释过，ChatGPT 的 Codex 接口按模型 ID 原样匹配，官方 ID 全是小写；那位用户把模型映射里的 GPT-6.1-Sol 改成 gpt-6.1-sol 后确认可用（farion1231/cc-switch #7916）。把 gpt-6-astra 简写成 astra 也会得到同一句话（openai/codex #46410）。

引号里是 gpt-5.5 也属于第一类：GPT-5.5 已于 2026 年 10 月 14 日 19:00 UTC 从 ChatGPT 登录的 Codex 退役，要换模型，配置里残留的旧 ID 怎么清理，见ChatGPT 显示 Model not found 怎么办：浏览器排查与 Codex GPT-5.5 退役。

第二类是现行的有效 ID，例如 gpt-6.1-terra、gpt-6-sol、gpt-6-astra。它们不是写错，改 ID 没有用；被拒的原因和 Sol 一样，只是每个模型有自己的客户端版本门槛，所以按后面版本、后台服务和账号几节处理。gpt-6.1-terra 在同一账号的 CLI 0.158.0 上被拒，和 Sol 的分界相同，它和 GPT-6 Astra 的官方最低版本见上文。gpt-6-sol 的门槛更低：它在同一账号的 0.158.0 上可以用，而 CC Switch 的一份第三方报告里，同一账号只改自报版本，0.153.4 和 0.154.0 时返回 400，0.155.0 时放行（farion1231/cc-switch #7651）。

哪些 Codex 版本会报：同一账号 CLI 0.158.0 被拒，0.159.0 起正常

2026 年 11 月 11 日 10:43–10:45 UTC，在一台 macOS 电脑上用同一个 ChatGPT Pro 账号、同一条 codex exec 命令，只换 Codex CLI 版本：0.157.1 和 0.158.0 收到这句 400，0.159.0 和 0.166.0 回复 OK。账号的登录令牌里套餐字段为 pro；几个版本都是 npm 上的官方构建，旧版本装在临时目录里，用一个只放了登录信息的空 CODEX_HOME 运行，没有配置文件，也没有模型缓存。codex exec 不经过后台服务，所以每次测到的就是命令里那个版本。命令如下，每次只换可执行文件和模型 ID：

codex exec -m gpt-6.1-sol --skip-git-repo-check -s read-only "Reply with exactly: OK" < /dev/null

两个失败的版本输出完全一样：

warning: Model metadata for `gpt-6.1-sol` not found. Defaulting to fallback metadata; this can degrade performance and cause issues.
ERROR: {"type":"error","status":400,"error":{"type":"invalid_request_error","message":"The 'gpt-6.1-sol' model is not supported when using Codex with a ChatGPT account.","code":"model_not_found"}}

第一行的 Model metadata for gpt-6.1-sol not found 警告，意思是客户端在自己拿到的模型目录里找不到这个 ID，只好用默认参数继续。它常和这句 400 一起出现，单独出现不代表请求失败；后面跟着 400 时，按本页处理即可。

codex debug models 打印的是服务端发给这个客户端的模型目录。同一账号下，0.158.0 拿到 8 个条目，没有 gpt-6.1-sol 和 gpt-6.1-terra；0.159.0 拿到 10 个，多出来的正是这两个。0.159.0 自带的内置目录（codex debug models --bundled）里其实没有 gpt-6.1-sol，它能用，是因为服务端把这个模型发给了它。服务端看的是客户端自报的版本，所以把新版本写好的 models_cache.json 拷给旧客户端也没用：0.158.0 照样被拒，还把缓存改写回了自己的版本。

这组结果只有一台 macOS、一个 Pro 账号、一天的数据，没有覆盖 Plus、Business、Enterprise、Edu 的门槛，也没有测桌面 App 和 IDE 扩展。0.159.0 是这次测出的分界，不是 OpenAI 公布的最低版本，只是恰好与官方给 GPT-6.1 Terra 公布的最低版本相同。GitHub 上几位 Plus 用户的前后对照指向同一方向：Windows 上 0.153.4 升到 0.163.0（#55028）、0.157.1 换成 0.162.1（#49396），Nobara Linux 上 0.153.4 升到 0.167.0（#51308），都是账号和配置不变，只换版本后恢复。

更新 Codex CLI 和后台服务（app-server daemon）

CLI 升级了还报，最常见的原因是后台服务没跟着升级。交互式运行的 codex 会连到一个常驻的后台服务（app-server daemon），请求经它发出；CLI 升级后它可能还停在旧版本，服务端就按旧版本处理。这个原因来自 GitHub 上的用户报告：openai/codex #49396 和 #49418 里至少有 7 位用户（Windows 和 Linux，套餐有 Plus 也有 Pro）报告，更新后台服务后同一账号恢复正常。codex exec 不经过后台服务，所以上一节的实测没有覆盖这种情况。按下面的顺序做：

1. 查看版本。codex --version 显示 CLI 版本，codex app-server daemon version 会以 JSON 列出本地 CLI 和正在运行的后台服务的版本。

2. 按原来的安装方式更新 CLI。npm 安装的执行 npm install -g @openai/codex@latest；Homebrew、独立安装包等其他渠道，见Codex CLI 安装与配置：Windows、macOS、Linux 一次跑通。

3. 让后台服务换成新 CLI 的版本并重启，最后一条输出里 CLI 和后台服务的版本应当一致：

   bash复制

   codex app-server daemon update --from-cli --yes
   codex app-server daemon restart
   codex app-server daemon version

4. 先用不经过后台服务的方式验证，再试平常的启动方式。第一条会真实发出一次请求，计入套餐用量：

   bash复制

   codex exec -m gpt-6.1-sol --skip-git-repo-check "Reply with exactly: OK"
   codex -m gpt-6.1-sol

   第一条收到 OK、第二条仍报 400，说明后台服务还是旧的。

这一步常见三个卡点。只执行 codex app-server daemon restart 不够，它会把同一个旧版本再启动一次。提示 Error: app server is running but is not managed by codex app-server daemon 时，说明有一个旧的 app-server 进程脱离了管理，要先结束它再更新（#49396）。Windows 上更新可能报 host Job Object prevents daemon detachment；2026 年 11 月 5 日的 #59646 里，CLI 已是 0.166.0，删掉 %USERPROFILE%\.codex\app-server-daemon 目录后后台服务仍停在 0.158.0，至今无人回复。遇到这两种情况，先用 codex --no-daemon 启动，它直接用当前 CLI，不经过后台服务。

桌面 App 和 IDE 扩展各自带着一份 Codex，要分别更新。桌面 App 在菜单 Menu > Check for Updates 手动检查，OpenAI 帮助中心针对 GPT-6 Astra 也要求这样做，即使刚自动更新过。VS Code 扩展关了自动更新的要手动更新：一位 Ubuntu 上的 Plus 用户把扩展更新到 26.1007.21434 后，包括 gpt-6.1-sol 在内的几个模型的 400 都消失了（#55259）。CLI 和后台服务版本不一致还会引起启动时的 account/read 报错，见Codex workspace routing discovery failed / timed out：account/read failed during TUI bootstrap 修法。

经 CC Switch、反代或中转报这句：要升级的是代理

经 CC Switch 这类本地代理、反代或中转复用 ChatGPT 登录时，向 OpenAI 自报 Codex 版本的是代理，不是你本机的 Codex CLI，所以本机 CLI 再新也不影响结果。CC Switch 3.20.4 在代码里把这个版本写死为 0.153.4。2026 年 10 月 1 日，CC Switch 的一位贡献者用同一账号、只改版本号请求模型目录：0.153.4 和 0.158.0 拿到的目录里没有 gpt-6.1-sol，0.159.0 和 0.159.2 有，和上面实测的分界一致。CC Switch 随后在 v4.0.4 把自报版本提到 0.159.0（farion1231/cc-switch #7797）；那次上游返回的正是 {"detail":…} 写法的这句话。

所以经代理时的处理顺序是：先把代理工具升级到修过版本门槛的版本，再检查它的模型映射里填的是不是小写 ID。同一账号在官方 Codex CLI 里能用、只有代理报错，就属于这一类；升级后目录里看得到、请求仍 400，CC Switch 的贡献者判断那是上游对该模型或账号的限制，代理侧修不了。CC Switch 各模式下看不到新模型或被拒的排查，见CC Switch 下 Codex 看不到 GPT-6.1 Terra：回直连或升 0.165.0。其他中转或账号池工具道理相同：要看的是它自报的客户端版本，而不是你本机的。

codex mcp-server、子代理和 OpenCode 报错：主会话能用也会被拒

主会话正常、只有某一路报这句时，问题出在这一路自己的客户端身份或模型设置上，更新 Codex CLI 不一定能改变它。2026 年 10 月 2 日，一位用户在 CLI 0.160.0 上发现 codex exec -m gpt-6.1-sol 可用，codex mcp-server 的工具调用却拒绝 gpt-6.1-sol 和 gpt-6-luna，只接受 gpt-5.6-luna（#49396，未解决）。10 月 23 日，一位自称 Pro 的 Windows 桌面用户把委派的子代理显式设为 gpt-6.1-sol 后被拒，主对话照常可用（#55902）。11 月 7 日，OpenCode 1.19.5 在 Plus 账号上被拒绝了 gpt-6.1-sol 和全部 GPT-6 模型，把 Codex CLI 和后台服务升到 0.167.0 也没有改善（#46304）。

这几种情况都没有确认的原因。能做的是把子代理或 MCP 调用里写死的模型改成主会话正在用的模型；第三方客户端复用 Codex 的 ChatGPT 登录时，发出去的是它自己的客户端标识，只能等这个客户端更新。

Codex 已是最新版仍报：账号一侧的原因和停手条件

CLI、后台服务和桌面 App 都是最新，codex debug models 里仍没有 gpt-6.1-sol，本地已经没有可改的东西。这条判断不是 OpenAI 给的诊断方法，而是推断：上文同一账号的对比里，服务端发给 0.158.0 和 0.159.0 的目录不同，能不能用跟着目录走；下面 #55617 的用户在最新版本上拿到的目录里也没有 Sol 模型。2026 年 10 月 20 日，一位 Windows 上的 Plus 用户 CLI 和后台服务都是 0.163.0，服务端给的目录只有 5 个条目、没有任何 Sol 模型，指定 gpt-6.1-sol 返回 400，更新后台服务时提示无可用更新（#55617）。10 月 21 日，一个 Business Premium 账号在 CLI 0.163.0 上原本能用的 gpt-6.1-sol 从 /model 里消失并开始报 400，其他 GPT-6 模型还在（#55902）。截至 11 月 11 日，这两个案例都没有解法，也没有 OpenAI 的回复。

账号一侧有据可查的原因有四种，证据强弱不同。套餐到期最明确：一位 Pro 用户的套餐周期在 2026 年 9 月 30 日结束，下一次请求就收到这句话（#49396）；他在同一条评论里给出的续费入口是 ChatGPT 的 Codex 用量设置页。刚通过 iOS App Store 改过套餐的，有一份单人报告称登录令牌里的套餐仍记为 free，所有付费模型都被拒，大约一天半后令牌刷新才恢复，打开 ChatGPT iOS App 能立刻刷新（#53020）。Enterprise 和 Edu 工作区的 GPT-6.1 Sol 默认关闭，要管理员开启，本地配置里选这个模型不会授予权限；OpenAI 文档没有对 Business 写这条规定。灰度还没轮到则只能等，OpenAI 帮助中心写明 GPT-6.1 Sol 仍在向符合条件的付费套餐推出。

单独退出再登录，在 gpt-6.1-sol 相关的 issue 里被多人报告无效；重装、删除 models_cache.json 也改变不了服务端发给你的目录。到这一步就停手：先换成目录里有的模型，怎么选见GPT-6.1 Sol、GPT-6 Sol、Astra 怎么选。个人套餐联系 OpenAI 支持，2026 年 7 月 27 日 OpenAI 支持账号在开发者论坛的 gpt-5.6-sol 报错帖里对同一句报错的建议，是发邮件到 support@openai.com 建工单，并附上报错原文、App 版本和设备信息；团队套餐则请工作区管理员确认模型权限。

和 2026 年夏天 gpt-5.6-sol 的同款报错是一回事吗

句子一字不差，原因不同。2026 年 7–8 月 gpt-5.6-sol 那一批，确认过的原因是发布当天的灰度（7 月 9 日报错的 Plus 用户次日就能用了）和订阅变化（未自动续费，或刚升级、续费后权益没同步）。8 月 7 日，OpenAI 支持账号在开发者论坛另一个 gpt-5.6-sol 报错帖里回复一位 Plus 用户：GPT-5.6 在 Codex 里不包含在那次面向 Plus 的推出范围内。那一批报告里没有人把原因追到后台服务或旧 CLI，而 gpt-6.1-sol 这一批多人确认的原因正是客户端版本。所以现在遇到，先查版本，再查账号。截至 2026 年 11 月 11 日，gpt-5.6-sol 在上文测试用的 Pro 账号上仍能正常回复。

Codex 选择器里没有 GPT-6.1 Sol：按出现位置找原因

选择器里看不到 GPT-6.1 Sol，先看是在哪里看不到：普通 ChatGPT 对话、终端的 /model、桌面 App，还是 Free 或 Go 账号的任何地方。前两行不是故障，其余每一行对应一个检查。

只在终端 /model 里缺、codex exec 能用的情况，2026 年 10 月 16 日有 Windows 上的 CLI 0.163.0 用户报告过（#54571），按 ID 直接指定就能用。桌面端目录没同步的情况，多位用户在 openai/codex #51308 等 issue 里反映重新登录、重装都无效；其中一位 Windows 用户在 10 月 29 日报告，更新到桌面 App 26.1023.50603 后完整的模型列表回来了。

config.toml 里的 model_catalog_json 会藏起新模型

model_catalog_json 是 config.toml 里的可选键，指向启动时加载的一份 JSON 模型目录，profile 文件也能设置它。这份目录如果是在某个模型上线前保存的，新模型就会在桌面 App 和 CLI 的 /model 里一起消失。2026 年 10 月 19 日在 Codex CLI 0.163.0-alpha.10.2 上试过：让它指向一份删掉了 gpt-6.1-sol 的目录后，codex debug models 只列出这份旧目录，再指定 gpt-6.1-sol 时，客户端打印的正是上文那条 metadata 警告。一位 Windows 上的 Plus 用户 10 月 17 日删掉这一行、完全退出 App 再打开后，GPT-6.1 Sol 就出现了（#54293）；GPT-6 Astra 上线时也有同样的报告（#43052）。在 ~/.codex/config.toml 和正在用的 profile 文件里搜 model_catalog_json，有就删掉这一行，再完全退出 App 后重开。

Windows 上的 CODEX_CLI_PATH 指向旧 codex.exe

Windows 桌面 App 里只有 GPT-5.6 系列、网页版 Work 里却有 GPT-6.1 Sol 时，检查环境变量 CODEX_CLI_PATH。它指向旧的 %LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe（报告里是 0.149.1 或 0.150.1）时，桌面 App 会用这个旧程序启动后台服务，模型目录也按旧版本下发。2026 年 10 月 15 日到 24 日，openai/codex #51308 里有 4 位用户清除或改正这个变量后恢复。在 PowerShell 里先查用户级和当前进程里的值：

[Environment]::GetEnvironmentVariable('CODEX_CLI_PATH', 'User')
[Environment]::GetEnvironmentVariable('CODEX_CLI_PATH', 'Process')

有值且指向旧版本，就清掉，然后完全退出 ChatGPT 桌面 App 并重启 Windows：

[Environment]::SetEnvironmentVariable('CODEX_CLI_PATH', $null, 'User')
Remove-Item Env:CODEX_CLI_PATH -ErrorAction SilentlyContinue

终端里 codex --version 显示的版本可能和桌面 App 实际用的不同，有用户的终端已是新版，App 用的仍是 0.149.1，所以不能只看终端。两条查询都没有值，就是别的原因。

GPT-6.1 Sol 在 Codex 里的其他问题

选择器里有 GPT-6.1 Sol，为什么没有 Ultrafast？

这是套餐限制，不是报错或客户端故障。截至 2026 年 11 月 11 日，OpenAI 帮助中心的 ChatGPT Work and Codex 文章写明，Ultrafast 发布时只提供给 Pro $500 档和符合条件的 Enterprise、Edu 工作区，Plus、100 美元和 200 美元两档 Pro 以及 Business 都没有，买 credits 也不行。

改用 API key 登录 Codex，能避开这句报错吗？

能避开 ChatGPT 账号这一层的判断，但计费方式会变。用 API key 登录时，可用模型跟随 key 所属的 API 组织和项目；按 OpenAI 帮助中心截至 2026 年 11 月 11 日的说明，这时按 API 价格计费，不再消耗 ChatGPT 套餐的用量。两种方式的额度和成本怎么比，见Codex API Key 和 ChatGPT 订阅怎么选？额度与 credits 按美元算；GPT-6.1 Sol 的 API 价格见GPT-6.1 Sol 怎么用：价格变化、迁移改动与可用入口。