# The 'gpt-6.1-sol' model is not supported when using Codex with a ChatGPT account 怎么解决：同一账号 CLI 0.158.0 被拒、0.159.0 正常 > 这句 400 不等于套餐不含 GPT-6.1 Sol：同一 Pro 账号上 CLI 0.158.0 被拒、0.159.0 正常。先核对 ID，再更新 CLI 和后台服务。 - URL: https://blog.laozhang.ai/zh/posts/gpt-6-1-sol-not-showing - Published: 2026-11-11 - Updated: 2026-11-11 - Author: LaoZhang AI Team (https://blog.laozhang.ai/zh/about) - Topic: 开发工具与智能体 - Tags: Codex, GPT-6.1 Sol, gpt-6.1-sol, Codex CLI, ChatGPT 账号, model_not_found, app-server daemon, CC Switch, 报错 --- 这句 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 工作区模型可用性文档](https://learn.chatgpt.com/docs/enterprise/workspace-model-availability)把 ChatGPT 登录的桌面 App、CLI 和 IDE 扩展能用哪些模型归结为两个条件：所用客户端支持这个模型，以及登录的 ChatGPT 身份有权限。这句报错两种情况都会出现，却不告诉你是哪一种。截至 2026 年 11 月 11 日，[OpenAI 帮助中心的 ChatGPT Work and Codex 文章](https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex)、GPT-6 模型说明和 [Codex 模型文档](https://learn.chatgpt.com/docs/models)都没有解释这句话，也没有公布 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 之类的代理）以及它的版本；同一账号换个程序能不能用。从上往下对照，命中哪一行就先做那一行的事，每一行的依据在后面对应的小节。 | 情况 | 一分钟内能看到什么 | 先做什么 | | --- | --- | --- | | ID 已退役、拼错或带大写 | 引号里是 `gpt-5.5`、`GPT-6.1-Sol`、`sol` 这类 ID | 改成小写的现行 ID；`gpt-5.5` 已退役，换模型 | | 现行的其他模型被拒 | 引号里是 `gpt-6.1-terra`、`gpt-6-sol`、`gpt-6-astra` | 不是 ID 写错，按下面几行查版本、后台服务和账号 | | 独立 CLI 太旧 | `codex --version` 是 0.158.0 或更早 | 更新 CLI | | 后台服务比 CLI 旧 | `codex app-server daemon version` 里两个版本不同；`codex exec` 或 `codex --no-daemon` 能用，直接运行 `codex` 不行 | 更新并重启后台服务 | | 桌面 App 或 IDE 扩展太旧 | 同一账号在终端 CLI 里能用，只有 App 或扩展报 | 手动更新 App 或扩展 | | 经 CC Switch、反代或中转 | 报错是 `{"detail":…}` 或代理日志行；同一账号在官方 Codex CLI 里能用 | 升级代理工具，模型映射用小写 ID | | MCP、子代理或第三方客户端 | 主会话正常，只有这一路报 | 改这一路的模型设置，或换成主会话的模型 | | 账号一侧 | 客户端全是最新，`codex debug models` 里仍没有 `gpt-6.1-sol` | 查套餐和工作区设置，先换模型，再联系支持 | 表里“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 退役](https://blog.laozhang.ai/zh/posts/codex-gpt-5-5-model-not-found)。 第二类是现行的有效 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： ```bash codex exec -m gpt-6.1-sol --skip-git-repo-check -s read-only "Reply with exactly: OK" < /dev/null ``` | CLI 版本（2026 年发布日期） | 请求的模型和条件 | 结果 | | --- | --- | --- | | 0.157.1（9 月 26 日） | `gpt-6.1-sol` | HTTP 400，这句报错 | | 0.158.0（9 月 28 日） | `gpt-6.1-sol` | HTTP 400，这句报错 | | 0.158.0 | `gpt-6.1-sol`，模型缓存刚由 0.166.0 写入且列有该模型 | HTTP 400，缓存随后被改写回 0.158.0 的内容 | | 0.158.0 | `gpt-6.1-terra` | HTTP 400，同一句话，引号里是 `gpt-6.1-terra` | | 0.158.0 | `gpt-6-sol` | 正常回复 `OK` | | 0.159.0（9 月 29 日） | `gpt-6.1-sol` | 正常回复 `OK` | | 0.166.0（10 月 29 日） | `gpt-6.1-sol` | 正常回复 `OK` | 两个失败的版本输出完全一样： ```text 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 照样被拒，还把缓存改写回了自己的版本。 ![同一 Pro 账号只换 Codex CLI 版本：0.157.1 和 0.158.0 返回 HTTP 400，0.159.0 和 0.166.0 正常回复；codex debug models 的目录从 8 条变成 10 条，多出 gpt-6.1-sol 和 gpt-6.1-terra](https://blog.laozhang.ai/posts/zh/gpt-6-1-sol-not-showing/img/codex-cli-version-boundary.webp) 这组结果只有一台 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 一次跑通](https://blog.laozhang.ai/zh/posts/codex-cli-install)。 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 修法](https://blog.laozhang.ai/zh/posts/codex-account-read-failed-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](https://blog.laozhang.ai/zh/posts/cc-switch-codex-model-not-showing)。其他中转或账号池工具道理相同：要看的是它自报的客户端版本，而不是你本机的。 ## 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 用量设置页](https://chatgpt.com/codex/settings/usage)。刚通过 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 怎么选](https://blog.laozhang.ai/zh/posts/gpt-6-1-sol-vs-gpt-6-astra-vs-gpt-6-sol)。个人套餐联系 OpenAI 支持，2026 年 7 月 27 日 OpenAI 支持账号在[开发者论坛的 gpt-5.6-sol 报错帖](https://community.openai.com/t/1387833)里对同一句报错的建议，是发邮件到 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 报错帖](https://community.openai.com/t/1389502)里回复一位 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 账号的任何地方。前两行不是故障，其余每一行对应一个检查。 | 在哪里看不到 | 同时能看到什么 | 原因 | 怎么办 | | --- | --- | --- | --- | | 普通 ChatGPT 对话 | Work 和 Codex 里有 | GPT-6.1 Sol 只用于 ChatGPT Work 和 Codex，普通对话里不提供 | 切到 Work 或 Codex | | 任何位置 | 账号是 Free 或 Go | GPT-6.1 Sol 面向符合条件的付费套餐 | 用 `gpt-6-luna`，见[GPT-6 免费吗？ChatGPT 免费版给的是 Luna，Sol 与 Astra 仍要付费](https://blog.laozhang.ai/zh/posts/is-gpt-6-free) | | 终端 `/model` | `-m gpt-6.1-sol` 返回这句 400 | CLI 或后台服务太旧 | 按上文更新 CLI 和后台服务 | | 终端 `/model` | `codex exec -m gpt-6.1-sol` 能回复 | 只是选择器没列出 | 用 `-m gpt-6.1-sol`，或在 config.toml 写 `model = "gpt-6.1-sol"` | | 桌面 App 和 CLI 都没有 | config.toml 里有 `model_catalog_json` | 加载了模型上线前保存的旧目录 | 删掉这一行，完全退出后重开 | | Windows 桌面 App 只有 GPT-5.6 系列 | 网页版 Work 里有；设置了 `CODEX_CLI_PATH` | 桌面 App 启动了旧的 codex.exe | 清除这个环境变量 | | 桌面 App | 同一账号在网页 Work、手机或 CLI 里有，本地查不出原因 | 桌面端的模型目录没有同步 | 更新桌面 App，仍缺就在 App 里提交反馈 | ![选择器里没有 GPT-6.1 Sol 时，按看不到的位置对应原因和处理办法：普通对话、Free 或 Go 账号、终端 /model、model_catalog_json、CODEX_CLI_PATH 和桌面 App 目录未同步](https://blog.laozhang.ai/posts/zh/gpt-6-1-sol-not-showing/img/model-picker-missing-map.webp) 只在终端 `/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 里先查用户级和当前进程里的值： ```powershell [Environment]::GetEnvironmentVariable('CODEX_CLI_PATH', 'User') [Environment]::GetEnvironmentVariable('CODEX_CLI_PATH', 'Process') ``` 有值且指向旧版本，就清掉，然后完全退出 ChatGPT 桌面 App 并重启 Windows： ```powershell [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 文章](https://help.openai.com/en/articles/20001275-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 按美元算](https://blog.laozhang.ai/zh/posts/codex-api-key-vs-subscription)；GPT-6.1 Sol 的 API 价格见[GPT-6.1 Sol 怎么用：价格变化、迁移改动与可用入口](https://blog.laozhang.ai/zh/posts/gpt-6-1-sol)。 ## 参考来源 本文引用的外部页面，按正文出现顺序排列。最后更新于 2026-11-11。 - [OpenAI 的 Codex 工作区模型可用性文档](https://learn.chatgpt.com/docs/enterprise/workspace-model-availability) (learn.chatgpt.com) - [OpenAI 帮助中心的 ChatGPT Work and Codex 文章](https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex) (help.openai.com) - [Codex 模型文档](https://learn.chatgpt.com/docs/models) (learn.chatgpt.com) - [ChatGPT 的 Codex 用量设置页](https://chatgpt.com/codex/settings/usage) (chatgpt.com) - [开发者论坛的 gpt-5.6-sol 报错帖](https://community.openai.com/t/1387833) (community.openai.com) - [开发者论坛另一个 gpt-5.6-sol 报错帖](https://community.openai.com/t/1389502) (community.openai.com)