Codex 提示 model not supported / model not found 怎么解决

今天准备继续写 Codex 的小问题记录。

说一个很容易遇到的问题：

model not supported

或者：

model not found

有时候报错会更长一点，大概意思是：

The model is not supported when using Codex with a ChatGPT account

这个错误已经提示的很明显了
第一个错误就是:你的模型没有找到
第二个错误就是:你的模型暂时不支持在codex中使用;

这个情况并不是 Codex 坏了，而是“你当前的登录方式、接口地址、模型名”这三件事没对上。

如果你遇到下面这些情况，可以继续看：

• Codex 能打开，但一发消息就报错
• 配了 model，但是提示 model not found
• 用 ChatGPT 账号登录，提示某个模型不支持
• 用 API_KEY 接入，结果模型名不认
• 配了 API 网关，但不知道 base_url 和模型名怎么填

如果你还没安装 Codex，可以先看前面的
Codex 在 Windows 上运行的保姆级教程
Codex 在 Mac 上运行的从零到一保姆级教程
Codex桌面版配置使用教程
这篇默认你已经能在终端里运行：

codex

先别急着改一堆东西

看到这个报错，先别急着，别乱改配置。

先按这个顺序看：

1. 你现在是 ChatGPT 账号登录，还是 API_KEY 接入
2. 你填的模型名是不是真的能用
3. 你的 base_url 有没有写对
4. 你的接口是不是支持 Responses API

第一种情况：ChatGPT 账号登录，但模型名不支持

有些朋友是直接用 ChatGPT 账号登录 Codex 的。

这种方式本身没问题，但要注意：你能不能用某个模型，不完全取决于你在配置里写了什么，还和账号、套餐、当前可用模型有关。

比如你在配置里写了一个模型名：

model = "gpt-5-codex"

但当前账号不支持这个模型，就可能出现类似：

The model is not supported when using Codex with a ChatGPT account

先做一件事：把配置里的模型名换成你当前账号确认能用的模型。

如果你不知道哪个能用，可以先去掉自己乱填的 model 配置，让 Codex 用默认模型跑一次，这个前提是你的是ChatGPT的账号登录，Codex会
自己去找可用的默认模型

很多新手容易犯的错误是：看到网上有人写了某个 Codex 模型名，就直接复制到自己的配置里。结果别人能用，不代表你这个账号也能用。
不同模型适配的是不同的套餐

第二种情况：API_KEY 接入，但模型名写错

如果你走的是 API_KEY，那就更要注意模型名。

这里的模型名不是随便写的，也不是看别人文章里写什么就复制什么。

你要去自己使用的站点后台，找到“模型列表”或者“可用模型”，复制里面真实存在的模型名。

比如配置里这行：

model = "这里填你能用的模型名"

一定要改成你自己能用的模型，一般中转站上都有自己的模型名称，每个站点的名称可能不一样哦…这点尤其要注意;
我截图的是我自己使用的站点https://cdn.yunaicode.com/

不要写成：

model = "我猜的模型名"

也不要看见 codex、gpt、claude 这些关键词就自己拼一个。

如果模型名错了，最常见的结果报错，我随意写了一个

这类问题其实很好排，复制正确的模型名称就好了。

第三种情况：base_url 少了 /v1

这个也是新手很容易漏的地方。

Codex 配置里通常会有一行：

base_url = "https://cdn.yunaicode.com/v1"

很多接口地址如果少了 /v1，就可能出现 404、接口不支持、请求路径不对之类的问题。

一般各个站点也都会有不同的模型，不同的请求方式不同的base_url，你到站点的模型广场去看你想要的模型详情就可以找到

所以如果你看到：

404

或者类似接口不存在的报错，先看 base_url。

别一上来就改 API_KEY，也别重装 Codex。

第四种情况：接口不支持 Responses API

这个稍微绕一点，但也不难理解。

Codex 现在很多调用走的是 Responses API，不是老的 Chat Completions。

配置里一般会写：

wire_api = "responses"

这句话的意思可以简单理解成：Codex 会按 Responses API 的方式去请求接口。

所以如果你的接口只支持传统的 /chat/completions，不支持 /responses，就可能出现：

unsupported endpoint

或者 400、404 之类的问题。

我自己一开始也容易把这两个搞混。后来就记住一句话：

Codex 用的接口形态，最好确认支持 Responses API。

如果你用的是 API 网关，也要确认它给 Codex 的入口支持这种调用方式。

我自己使用的站点截图：https://cdn.yunaicode.com基本上都支持两种模式，各位看官按需处理。

我现在常用的配置模板

下面这个模板比较通用。

不要直接复制完就不改，里面有两个地方必须换成你自己的。

model = "这里填你能用的模型名"
model_provider = "custom"

[model_providers.custom]
name = "Custom API"
base_url = "https://cdn.yunaicode.com/v1"
env_key = "API_KEY"
wire_api = "responses"

approval_policy = "on-request"
sandbox_mode = "workspace-write"

Windows 用户如果用原生环境，可以加：

[windows]
sandbox = "elevated"

这里重点看三行。

第一行：

## 模型名称一定要正确,要和你用的站点支持的名称一样
model = "这里填你能用的模型名"
## 地址一定要注意站点告诉你的api地址是多少
base_url = "https://cdn.yunaicode.com/v1"
## 这里写的是环境变量名，不是直接写你的 Key
env_key = "API_KEY"

去后台复制，不要自己猜或者手输。

Windows 下怎么检查 API_KEY

如果你是 Windows，打开 PowerShell：

echo $env:API_KEY

如果能看到你的 Key，说明环境变量生效了。

如果什么都没有，重新设置：

setx API_KEY "你的 API Key"

然后关闭 PowerShell，重新打开，再检查一次：

echo $env:API_KEY

setx 这个地方很多人会踩坑。它设置完后，当前窗口不一定马上生效，重新打开 PowerShell 很重要。

Mac 下怎么检查 API_KEY

Mac 打开终端：

echo $API_KEY

如果没有输出，先看你用的是不是 zsh：

echo $SHELL

一般现在 Mac 默认是 zsh，可以这样写：

echo 'export API_KEY="你的 API Key"' >> ~/.zshrc
source ~/.zshrc

再检查：

echo $API_KEY

能看到就行。

我的排查顺序

如果你懒得看前面那么多，可以直接按这个顺序来：

1. 先看自己是 ChatGPT 登录，还是 API_KEY 接入
2. 如果是 ChatGPT 登录，先别乱填最新模型名
3. 如果是 API_KEY 接入，去后台复制真实模型名
4. 检查 base_url 最后有没有 /v1
5. 检查 API_KEY 环境变量有没有生效
6. 检查接口是否支持 Responses API
7. 改完配置后，重新打开终端再试

这个顺序基本能排掉大多数 model not found 和 model not supported。

成功是什么样子

配置没问题的话，进入项目目录：

codex

然后问一句：

请用中文回复。先不要修改文件，帮我看一下当前目录里有哪些文件。

如果 Codex 正常回复，并且能读到当前目录，就说明基本跑通了。

如果它还是报模型问题，就回到上面的几个点继续查。

最后说一下

这类报错看着吓人，其实大多数不是大问题，先查配置。