奇 奇连 AI
学习路线图课程工具计算器企业服务关于加入会员

Codex 接第三方模型怎么选：`model_providers` 与 `wire_api` 只支持 responses 这一关

2026-08-09

「Codex（OpenAI Codex）能不能接我自己的模型？」这个问题问出来的时候，八成人心里已经打算去搜一段 model_providers 配置贴进 ~/.codex/config.toml 了。但真正决定成败的不是那几行 TOML，而是官方在配置文档里对 wire_api 写的一句话：默认值是 responses，并且只支持 responses。这一句会直接筛掉一大批候选。

所以先别急着抄配置。下面按你的实际处境倒推，走到哪条路是哪条路。

一、先回答三个问题，再决定要不要碰 model_providers

问题一：模型账单从哪里出？

官方给的认证方式只有两种（《Authentication》页口径）：一种是 ChatGPT 登录，用 ChatGPT workspace 凭据、走浏览器完成认证，遵循 workspace 权限、RBAC 与企业留存设置；另一种是 API Key，需要 OpenAI 控制台的 key，按标准 API 费率通过 OpenAI Platform 账户计费。定价页上 API Key 这一档写的就是「按 token 用量计费」，而订阅档（Plus $20/month、Pro Starting at $100/month）的用量口径是 messages 数、5 小时滚动窗口（ChatGPT 官方定价页，2026-08-09 核对，以官方为准）。

这两条路都不需要自定义 model_providers。公司统一发席位的，直接 codex login；要按 token 走 Platform 账单的，官方给的命令是：

printenv OPENAI_API_KEY | codex login --with-api-key

本机在 codex-cli 0.147.0（Windows 11）上跑 codex login status，输出就一行 Logged in using ChatGPT——这条只读命令是你确认「当前到底在用哪种认证」的最短路径，比翻配置快。

问题二：这台机器允许出网到官方端点吗？

如果只是公司网络做了 TLS 代理或用私有根 CA，那不是「换模型」的问题，是证书的问题。官方给的做法是登录前设置环境变量 CODEX_CA_CERTIFICATE；登录失败的诊断信息会写进日志目录下的 codex-login.log。这类情况改 model_providers 完全是南辕北辙。

如果是真的不出公网、要在本地跑模型，Codex 有一条现成的路，不用你手写提供方：CLI 的 --oss 表示使用开源提供方，--local-provider <OSS_PROVIDER> 指定本地提供方，取值只有 lmstudio 和 ollama 两个；配置侧对应 oss_provider，同样是这两个取值。不带 --oss 单独指定时，走配置默认或弹选择。

问题三：你要接的那个端点，说得清自己讲的是哪套协议吗？

只有走到这一步，model_providers 才轮得上场。而这一步的门槛就是下面这条。

二、wire_api 这一关：不是「OpenAI 兼容」就能接

官方《Configuration Reference》里，model_providers.<id>.wire_api 的默认值是 responses，并且明确写了只支持 responses。这句话的分量在于：Codex 这里要的是 responses，所以对方自称「OpenAI 兼容」这句话本身不足以判断能不能接，必须去对方文档确认有没有 Responses 协议兼容端点。能不能接，取决于对方有没有提供 Responses 协议兼容的端点，而不是它自称不自称 OpenAI 兼容。

这一条也是我要提醒的边界：官方文档给的只有「只支持 responses」这个事实，至于某个具体的第三方服务、某个中转端点行不行，我们没有验证过任何一家，这里不做任何推断。你自己的判断标准应该是去问对方的文档：有没有 Responses 协议端点、base_url 该填到哪一层。这个问题问不清楚，配置写得再漂亮也白搭。

顺带一个容易被忽略的连带影响：model_providers.<id>.supports_standalone_web_search 默认是 false。也就是说，换到自定义提供方之后，能力面不是自动等价的，得逐项确认。另外本机在 codex-cli 0.147.0（Windows 11）上跑 codex features list，standalone_web_search 显示的阶段是 under development，生效值 false——这类还在开发中的特性，本来也不该当稳定能力去依赖。

三、真要写，这些键是官方给的

《Configuration Reference》里 model_providers.<id>. 下的键，挑与接入直接相关的几个。先说清一件事：这一节官方大部分只给了键名和默认值、没给释义，下表如实照搬，没释义的地方我不替官方补——这类键该怎么用，只能以官方文档为准，别照着名字猜。

键默认官方给的说明
name—官方未给释义
base_url—官方未给释义
env_key—放 API key 的环境变量名
env_key_instructions—官方未给释义
experimental_bearer_token—官方标注不建议，应改用 env_key
requires_openai_authfalse官方未给释义，只给了默认值
wire_apiresponses官方明确只支持 responses
query_params / http_headers / env_http_headers—官方未给释义
request_max_retries4官方未给释义，只给了默认值
stream_max_retries5官方未给释义，只给了默认值
stream_idle_timeout_ms300000官方未给释义，只给了默认值
supports_websockets—官方未给释义
supports_standalone_web_searchfalse官方未给释义，只给了默认值
auth.command / auth.args / auth.cwd—官方未给释义
auth.timeout_ms5000官方未给释义，只给了默认值
auth.refresh_interval_ms300000官方未给释义，只给了默认值

这张表最该被读出来的信息其实是「哪些格子是空的」：真正有官方明文口径的只有三处——env_key 是放 API key 的环境变量名、experimental_bearer_token 官方自己标不建议、wire_api 只支持 responses。其余的键，你能拿到的确定信息就是那个默认值。

跑在 AWS 上的另有 Bedrock 专属两键：model_providers.amazon-bedrock.aws.profile 与 .aws.region。

按官方键位组合出来大致长这样：

model_provider = "myprovider"
model = "<提供方给你的模型名>"

[model_providers.myprovider]
name = "My Provider"
base_url = "https://<你的端点>"
env_key = "MY_PROVIDER_API_KEY"
wire_api = "responses"
request_max_retries = 4
stream_max_retries = 5
stream_idle_timeout_ms = 300000

以上为按官方文档键位组合的示例，未逐项实测，以官方文档为准。

两处最容易写错的地方：

第一，env_key 填的是环境变量的名字，不是密钥本身。也就是说文件里应该出现 MY_PROVIDER_API_KEY 这样的名字，真正的 <YOUR_API_KEY> 留在环境变量里，别落进 config.toml。官方还给了 experimental_bearer_token 这个键，但自己就标注了不建议、应改用 env_key——既然厂商都这么说了，就别图省事。

第二，model_provider 是顶层键（默认 openai），它的取值要对上你在 model_providers 表里起的那个 id。光定义了提供方而不改 model_provider，等于白定义。想临时试一把不改文件，CLI 的 -c, --config <key=value> 可以覆盖，点号路径表示嵌套，官方给的例子形如 -c model="o3"、-c shell_environment_policy.inherit=all。

关于那三个默认值，官方只给了数字、没给释义，但数字本身在排查时就有用：request_max_retries 默认 4、stream_max_retries 默认 5、stream_idle_timeout_ms 默认 300000。这三个量级摆在一起，至少说明一件事——接自定义端点时「等了很久才报错」不等于「完全连不上」，默认配置本身就允许等得久、并且失败后还会再试几轮。具体语义以官方文档为准，别照名字往下推。

四、配完怎么验收

改完配置，第一件事不是发对话，是跑只读命令。

本机在 codex-cli 0.147.0（Windows 11）上做过一个故意构造的实验：执行 codex -c 'features=[unclosed' doctor --summary，命令没有崩溃退出，doctor 照常跑完，但 Notes 区多了一行：

✗ config       config could not be loaded - Fix the reported config error, then rerun codex doctor.

这条结论很实用——配置写坏了 Codex 不一定当场报错，但 doctor 会明确告诉你配置没加载成功。所以「我明明改了 config，怎么一点变化没有」，第一步就该看这一行。

codex doctor --summary 的输出里还有几组是这次要盯的：Configuration 组的 config（loaded）和 auth（auth is configured），Connectivity 组的 network 与 reachability（active provider endpoints are reachable over HTTP）。最后一行是统计，形如 17 ok · 1 idle · 1 notes · 0 warn · 0 fail。要贴给别人看的话，codex doctor --json 官方说明是「Emit a redacted machine-readable report」，是脱敏的。

还有一个别指望错了的选项：--strict-config 的说明是「config.toml 里出现本版本不认识的字段时直接报错退出」，听上去像个拼写检查器。但本机在 codex-cli 0.147.0（Windows 11）上执行 codex -c model_reasoning_effortt=high --strict-config exec --help，正常打印 help，没有报未知字段错误。说明校验发生在真正加载配置去跑会话的时候，--help 这类不进入会话的路径不触发。所以它能兜住拼错的键，但不是「任何情况下都会拦住」。

五、什么情况别走这条路

  • 只是想换官方模型或调推理强度：那是 model、model_reasoning_effort（取值 minimal / low / medium / high / xhigh）的事，跟提供方无关。
  • 公司有受管配置：forced_login_method（取值 chatgpt 或 api）、forced_chatgpt_workspace_id、chatgpt_base_url 这几个键存在，说明登录方式可能被上游锁定。自己在本地写一套 provider 未必生效，先问管理员。
  • 对方端点讲的不是 Responses 协议：回到第二节，这条过不去就别往下走了。
  • 想在本地跑开源模型：用 --oss 与 --local-provider（lmstudio / ollama）那条路，比手写提供方省事。

最后一句实在话：这块配置属于「一次配对、长期不动」的类型，配的时候慢一点、每一步用只读命令验一下，比配完直接甩个大任务过去然后对着报错猜要划算得多。

相关阅读

本文依据 Codex 官方文档（learn.chatgpt.com/docs/ 的《Configuration Reference》《Authentication》《Codex CLI》《Pricing》页面）整理，核对日 2026-08-09；文中标注「本机实测」的部分基于 codex-cli 0.147.0 / Windows 11 环境下的只读命令输出。产品功能、模型与价格以官方最新说明为准。价格与活动随时可能调整，下单前请以官方页面为准。桌面应用与云端部分为官方文档口径，非本机实测。

想系统学会用 AI？报名体系课或加入会员，照着学、照着用。

浏览课程 加入会员