这篇解决一个最容易让国内模型配置“看起来正确、实际报 404”的问题：服务商写着“OpenAI 兼容”，不代表它一定兼容 Codex.
> 官方依据：OpenAI Codex Manual 的 Custom model providers 与 wire_api 配置说明。当前官方配置只支持 responses。
完成后你能判断一个模型服务是否可以直接配置为 Codex 自定义 provider，还是需要协议转换层。
准备服务商当前官方文档中的三项信息：
- Base URL.
- 是否明确提供 /responses 或等价的 Responses API。
- 可以直接配置 Codex provider；
- 需要协议转换层；
- 暂时不能确认。
- 等服务商提供 Responses API.
- 使用可信、可审查的协议转换层。
- 使用服务商 or 工具提供的专用集成，但先做供应链 and 密钥风险检查。
- base_url` 能访问，不等于协议兼容。
- 能列出模型，不等于能完成 Codex 工具调用。
- 普通对话能回复，不等于读文件、执行工具 and 流式输出都正常。
- 第三方转换工具能跑通，不等于模型服务商原生支持 Codex.
- 你能指出服务商提供的是 Responses 还是 Chat Completions.
2. 实际请求路径，例如 /v1/responses 或 /v1/chat/completions。
3. 官方请求示例 and 模型名。
不要只看“兼容 OpenAI”这句宣传文案。
| 检查项 | Responses API | Chat Completions |
| ----------------------- | ------------- | -------------------- |
| 常见路径 | /v1/responses | /v1/chat/completions |
| 常见输入字段 | input | messages |
| Codex 自定义 provider 当前支持 | 支持 | 不可直接配置 |
两者都可能被称为“OpenAI 兼容接口”，但请求 and 响应结构不同。
把服务商文档地址发给 Codex, 先让它只读判断：
``
请只读检查这个模型服务商的官方 API 文档，不要修改任何配置。
请分别确认：
2. 是否只提供 /chat/completions。
3. 请求字段使用 input 还是 messages。
4. 是否有官方依据证明能作为 Codex 自定义 provider 使用。
5. 如果证据不足，明确写“不能确认”，不要猜。
最后给出结论：
`
预期结果是得到协议证据 and 明确结论，而不是只得到一段 config.toml。
明确支持 Responses API
Section titled “明确支持 Responses API”
可以继续准备 model、model_provider、base_url and env_key. 仍要先生成草稿、备份旧配置，再做最小请求验证。
只支持 Chat Completions
Section titled “只支持 Chat Completions”
不要添加 wire_api = "chat". 当前 Codex 官方配置没有把它列为支持值。
可选路线是：
暂停写配置，向服务商确认。不要用“试试看”替代兼容性结论，因为失败可能表现为 404、字段错误、流式响应错误 or 工具调用异常。
你做到这里，如果看到下面 3 个结果，就说明本篇完成：
2. 你没有给只支持 Chat Completions 的地址直接写入 Codex 原生 provider.
3. 你知道使用转换层前还要检查来源、权限、密钥 and 回滚方式。
下一篇看：使用第三方 Codex 工具前的安全检查。