夜雨聆风Codex 的模型入口开始变了：不是靠插件，而是通过原生 model_provider / model_providers 配置，让国内模型有机会进入同一个 Agent 工作台。
以前想在 Codex 里接国内大模型，很多人的第一反应是：找插件、改代理、套一层兼容服务。
现在这个逻辑变了。
Codex 官方配置里已经出现 model_provider 和 model_providers，官方模型页也明确说，Codex 可以指向支持 Chat Completions 或 Responses API 的模型和 Provider。
重点不是“第三方模型能不能跑”。
重点是：这不是插件能力，而是 Codex 自己的模型 Provider 配置。
非插件，差别很大
插件解决的是“额外能力”：接 GitHub、接浏览器、接 MCP、接某个外部工具。
模型 Provider 配置解决的是“谁来驱动 Codex 这个 Agent”。
这两个不是一个层级。
如果你靠插件接模型，Codex 更像在外面绕了一圈；如果你通过 model_provider 接模型，模型就进入了 Codex 原生工作流：读文件、改代码、跑命令、审批、保留上下文、看 diff、做 review。
这就是为什么我觉得这次变化值得写。
它不是又多了一个国产模型入口，而是 Codex 开始把“模型”变成可替换组件。
具体怎么配
Codex 用户级配置在这里：
~/.codex/config.toml注意，是用户级配置。
官方文档明确说，项目里的 .codex/config.toml 不能覆盖 model_provider 和 model_providers 这类机器本地 Provider 配置。原因也好理解：模型供应商、鉴权、Base URL 都属于你机器上的账号和安全边界，不应该被某个项目仓库随便改掉。
一个最小配置长这样：
model_provider = "domestic-gateway"model = "your-model-name"[model_providers.domestic-gateway]name = "Domestic Model Gateway"base_url = "https://your-provider.example.com/v1"env_key = "DOMESTIC_MODEL_API_KEY"wire_api = "responses"然后在本机环境变量里放 Key：
export DOMESTIC_MODEL_API_KEY="你的 API Key"这里最重要的是四个字段。
model_provider 决定 Codex 当前用哪个供应商。
model 写这个供应商里的模型名，比如你网关里配置的 GLM、Qwen、Kimi、DeepSeek 等模型别名。
base_url 指向你的模型服务地址。
env_key 不是固定变量名，而是告诉 Codex：去读哪个环境变量当 API Key。
怎么自由切换
如果只改 config.toml，当然也能切。
但更舒服的方式是做多个 profile。
官方文档里提到，profile 配置文件放在 $CODEX_HOME 下，文件名类似：
~/.codex/glm.config.toml~/.codex/qwen.config.toml~/.codex/kimi.config.toml比如 glm.config.toml：
model_provider = "glm"model = "glm-5.2"[model_providers.glm]name = "GLM Gateway"base_url = "https://your-glm-compatible-endpoint.example.com/v1"env_key = "GLM_API_KEY"wire_api = "responses"再来一个 qwen.config.toml：
model_provider = "qwen"model = "qwen-coder"[model_providers.qwen]name = "Qwen Gateway"base_url = "https://your-qwen-compatible-endpoint.example.com/v1"env_key = "QWEN_API_KEY"wire_api = "responses"启动时直接切：
codex --profile glmcodex --profile qwen这才是我说的“非插件自由切换”。
不是在 Codex 外面挂一个插件，而是把不同国内模型入口做成 Codex 自己的配置预设。
但有一个现实限制
这里要说严谨一点。
官方模型页说 Codex 可以指向支持 Chat Completions 或 Responses API 的模型和 Provider，但同时也说 Chat Completions 支持已经 deprecated，未来会移除。
而当前配置文档里，wire_api 写的是 responses。
所以如果某个国内平台只提供传统 OpenAI Chat Completions 兼容接口，短期可能还有办法，但长期不值得押。
更稳的路线是：让你的模型供应商、团队网关，或者中间层直接暴露 Responses API 兼容入口。
换句话说，Codex 不是突然保证所有国内模型都能无脑直连。
它真正打开的是一条更干净的路：只要模型入口和协议跟上，就不用靠插件把模型塞进来。
我的判断
Codex 这次最有意思的，不是 CLI 多了几个命令，也不是桌面端继续补功能。
而是 OpenAI 开始承认一个现实：未来 Coding Agent 不会只跑一种模型。
国内开发者更关心的是：我能不能在同一个 Agent 工作流里切 GLM、Qwen、Kimi、DeepSeek，而不是每换一个模型就换一套工具。
Codex 如果把终端、文件修改、审批、diff、review、worktree、MCP、插件生态都做好，模型反而可以变成插拔件。
这对 OpenAI 是好事。
对国内模型也是好事。
真正被改变的是开发者的习惯：以后你换的可能不是工具，而只是 model_provider。
