Codex 提示 `gpt-image-2` 模型不存在：先查状态、API 路线和供应商边界

如果 Codex 显示 The model 'gpt-image-2' does not exist，或者中文界面把它说成“gpt-image-2 模型不存在”，不要先改模型名。先判断报错来自哪个 surface：OpenAI 文档已经列出 gpt-image-2，但 Codex 会话、直接 Image API、Responses 工具、第三方 provider、组织或项目权限，都可能各自失败。

先按这张表分流：

停止规则：如果只有 Codex 在事故窗口里失败，先看状态、重开会话、刷新登录；不要把一个有效模型名改成另一个名字来“试试看”。

快速答案

这条错误不是一个单一结论。它可能表示 Codex surface 暂时无法路由图像工具，也可能表示你的直接 API 请求 shape、项目权限或 provider 模型映射有问题。先分清报错 owner，再做最小验证，才能避免把服务事故误修成代码变更。

截至 2026-06-03 本轮检查，OpenAI 图像生成文档列出 gpt-image-2。这就是核心边界：模型被官方文档列出，并不等于每一个 Codex 会话、第三方网关或项目 key 都能立刻访问它。相反，报错 surface 才决定你下一步该等、该重试、该验证 key，还是该找 provider。

为什么 Codex 会提示模型不存在

Codex 是一个工作 surface，不等于你自己的 curl https://api.openai.com/v1/images/generations。它有自己的会话、鉴权、工具路由、版本和服务健康状态。只要其中一层无法把图像任务路由到可用后端，就可能显示类 似 model-not-found 的错误，即使 OpenAI 文档里已经有这个模型名。

这就是它和普通 API bug 的差别。普通 API bug 往往能落到请求本身：endpoint 错了、key 属于另一个 project、组织没有验证、provider 不支持这个模型、Responses 工具 shape 写错，或者 base URL 指向了代理。Codex-only 失败可能在你的代码之前就发生。你的仓库如果根本没有调用 Image API，第一步就改应用代码，通常是在增加第二个变量。

2026 年 6 月的中文开发者讨论里，GitHub issue、Linux.do 讨论、Codex 图像工具文章和 provider 文档同时出现。这个局面说明本地读者不是只问“模型真假”，而是在问“Codex、网关、OpenAI direct 和 provider 到底谁负责”。正文必须把这个分流说清楚。

先查 OpenAI Status 和 Codex 会话

如果报错只发生在 Codex，请按这个顺序做，不要跳步：

1. 打开 OpenAI Status，查 Codex 或相关服务在同一时间段有没有 degraded performance 或 incident。
2. 等状态进入 monitoring 或 resolved 后，再用同一个 Codex 任务重试一次。
3. 新开 Codex 会话，刷新登录，如果是 CLI 或桌面 app，再确认版本是否过旧。
4. 记录报错时间、完整错误、Codex 正在执行的任务、是否调用 imagegen 或图片工具。
5. 只有当错误在状态稳定后仍然复现，或者直接 API 也失败时，才进入 API/provider 排查。

这个顺序的价值在于减少误修。很多人看到 “does not exist” 会马上把 gpt-image-2 改掉，结果把一个服务路由问题写进业务代码，后续日志、计费和回放都更难解释。

用 OpenAI Image API 做最小验证

如果你要证明自己的 OpenAI API route 能否访问 gpt-image-2，用官方 base URL、同一个组织和同一个 project 发最小请求。不要在这个测试里混入 provider、缓存层、复杂 prompt 或业务封装。

bash
curl https://api.openai.com/v1/images/generations \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-image-2",
    "prompt": "A small lighthouse on a cliff, simple test image",
    "size": "1024x1024"
  }'

完整 Image API 语法、参数和 provider 边界可以接着看：GPT-Image-2 API 指南。

不要混淆 Image API 和 Responses

Image API 和 Responses API 的图像工具不是同一个请求形状。直接图片任务使用 Image API，并在请求里设置 model: "gpt-image-2"。如果图片生成是 assistant、agent 或多步对话的一部分，通常是主模型加 tools: [{ type: "image_generation" }]。

错误常出现在搬代码时：把 Image API 的 model 字段复制到 Responses 的主模型位置，或把 Responses 的 tool 写法拿去调用 /images/generations。这两种错都会让日志看起来像“模型不存在”，但 owner 完全不同。

js
const response = await client.responses.create({
  model: "gpt-5.5",
  input: "Create a simple test image and explain the composition.",
  tools: [{ type: "image_generation" }]
});

把这段当作 shape 示例，不要把主模型写成永久推荐。主模型会随账号和文档更新而变；稳定规则是 route split：直接图片产物用 Image API，多步助手工作流用 Responses tool。

Provider 或自定义 base URL 报错

很多“OpenAI-compatible” provider 会暴露相同或相似的模型名，但 provider 自己拥有模型映射、计费、区域、失败重试、缓存和上游账户。provider 返回 The model 'gpt-image-2' does not exist，并不等于 OpenAI direct route 不存在。

先检查这些点：

• base URL 真的是 https://api.openai.com/v1，还 是 provider/proxy URL？
• provider 当前模型列表是否逐字包含 gpt-image-2？
• provider 是否要求另一种图片 endpoint、route name 或 mode？
• 你是否把 provider key 搭配 OpenAI 文档，或把 OpenAI key 搭配 provider 文档？
• provider 价格、失败扣费、可用性、速度、额度是否在本轮被验证？

对 laozhang.ai 也要这样写。它可以作为 OpenAI 兼容 provider route 帮开发者完成 API 接入、支付或网关场景，但 provider 价格和 model coverage 必须标为 provider-owned，不是 OpenAI 官方价格。

项目、组织和访问门槛

官方文档列出模型，不代表每个 key、project 或组织状态都拥有同一访问权。图像模型可能受组织验证、项目配置、地区、账户状态或 key scope 影响。ChatGPT/Codex 产品权限也不等于 Platform API 权限。

当 direct OpenAI 也失败时，先收集一包可路由证据：

• endpoint 和 base URL
• model name
• request id 或 response headers
• organization 和 project
• 组织验证状态
• timestamp 和 timezone
• 区域、代理、网络路径
• 最小可复现请求

这包证据比只截一张错误图有用得多。它能告诉支持或团队 owner 是 Codex、OpenAI API、provider、网络，还是 access gate。

状态恢复后的排查顺序

如果 OpenAI Status 已经 resolved，但 Codex 还提示模型不存在，用短梯子排查：

1. 同一个 Codex 任务只重试一次。
2. 新建 Codex 会话或刷新登录。
3. 更新 Codex CLI / app。
4. 从同一网络跑 direct Image API 最小请求。
5. 如果用 provider，单独查 provider 模型列表、base URL、endpoint。
6. 带 request id、时间、org/project、最小复现再开 support/provider ticket。

只要某个 surface 通过，就停止扩大问题。如果 direct OpenAI 通过而 provider 失败，provider 才是下一步 owner。如果 Codex 新会话通过，问题可能是 session 或 route state。如果 direct OpenAI 返回 access error，就回到组织和项目权限。

常见问题

gpt-image-2 是真实 OpenAI 模型吗？

是。OpenAI 图像生成文档在本轮检查中列出了 gpt-image-2。所以 Codex 的 model-not-found 消息不能单独证明模型不存在。

看到这个错误要不要改成别的模型？

不要作为第一步。只有当你实际使用的 route 文档明确要求另一个模型或别名时，才改模型名。事故窗口里乱改会隐藏真实 owner。

直接 API 成功，但 Codex 仍失败怎么办？

保留 direct API 成功证据，然后刷新 Codex 会话、重试、更新 Codex surface。你的产品 API route 不是第一嫌疑人。

provider 返回 HTTP 400 或 model_not_found 怎么办？

查 provider 模型列表、base URL、endpoint 和上游账户。OpenAI direct 成功但 provider 失败时，按 provider coverage/mapping/billing 处理。

ChatGPT 或 Codex 计划能保证 Image API 权限吗？

不能。ChatGPT 产品、Codex 工具、Platform API key 是不同 surface。你要看拥有 API key 的组织和项目。

应该保存哪些证据？

保存完整错误、surface、model name、base URL、endpoint、org/project、timestamp、request id、status 状态和最小复现。这样后续不会把 Codex、OpenAI API、provider 和权限问题混在一起。