新智元报道

有人欢呼，这是OpenAI「最开放」的一次。给Codex装上能随便换模型的插座，等于亲手填平自己模型的护城河。它图什么？

一夜之间，OpenAI的编程智能体Codex不再只认自家的GPT，而是面向所有开源模型开放了。

最先察觉这一信号的，是开发者社区。

有开发者在Codex的命令行（CLI）和软件开发工具包（SDK）配置里，翻出一个陌生的开源模式（OSS mode），官方也叫它本地提供方（local providers）。

在命令行里加一个--oss，它就能在本地跑起开源模型；想接别的，改一个字段就行。

要知道，OpenAI在过去几乎就是「闭源」的代名词，Codex只认OpenAI自家的GPT。

但现在不一样了，仅仅一行配置，就能切换到本地的Ollama、LM Studio等模型服务。

这事很快便在开发者圈里炸了。

OpenAI Codex团队负责人Tibo还不忘亲自在X上提醒道：

Codex的App、CLI和SDK，可以搭配任意开源模型使用，并非只能用OpenAI自家的。

这条提醒，很快被Hugging Face联合创始人Thomas Wolf转发，还加上一句感叹：今天才知道，Codex里居然能用开源模型了。

有网友直呼，这可能是OpenAI有史以来最「开放」的一次，是件了不起的大事。

社区的动作更快。

官方文档一出，开发者立刻尝试把一些开源模型接进去，还顺手讨论起更省token的混搭方案。

但也有人很快就撞上了墙。

开发者Filip Baturan想在Codex里搭一套混合方案：让GPT做规划，再让开源模型当执行者。

可试下来他发现，Codex要求接进来的模型也用同一套工具调用协议，而开源模型未必有。

一边是「史上最开放」的欢呼，一边是接不进去的协议。

这一回，OpenAI到底开放到了哪一步？

开源模型是如何接入Codex的？

OpenAI这次对Codex的开放，本质上并不是开放模型本身，而是开放了「模型接入层」。

换句话说，它没有开放GPT模型，而是给Codex加了一个「可插拔模型接口层」。

这个能力通过一个叫模型提供方（model_providers）的配置来完成的。

开发者可以在配置文件中注册多个「模型提供方」，每个提供方包含四类信息：

访问地址（base_url）、通信协议（wire_api）、鉴权方式（env_key），以及模型映射关系（model）。

Codex启动时会根据配置选择对应模型提供方，从而将请求路由到不同模型服务，包括OpenAI自身模型、本地Ollama模型或DeepSeek等第三方API。

Codex的model_providers配置示例。base_url是模型地址，而协议字段wire_api只认responses一个值。

Mistral、企业自建的代理、第三方中转站，都能这么接入Codex。

有网友把这套能力的亮点总结为：不被一家厂商绑死，按需切换，隐私和成本自己说了算。

更省事的是，你还能把这些设置都保存为「配置档案」，调试时想用哪个，命令行里点它的名字就能切过去。

比起上面的手动配置，还有一个更直接的开关：--oss。加上这个参数，Codex就直接去连本地的开源模型服务。

默认就这两个：Ollama和LM Studio。前者是本地跑大模型最流行的工具，后者是带图形界面的桌面平替。

Codex --oss连本地模型实战截图：左侧Codex CLI（v0.92.0）用--oss调用本地模型，右侧LM Studio在本机1234端口加载openai/gpt-oss-20b（12.11GB）对外提供服务，全程本地离线。

也就是说，通过本地模型服务和网络权限配置，你可以让Codex在本机完成代码生成与推理，并在一定程度上实现离线运行与本地化处理。

Codex CLI界面：启动信息里model一行标着当前模型（gpt-5.2-codex），后面跟着「/model to change」，一句命令就能切换模型，整套智能体就跑在本机。

不过，插座装上了，不代表什么电器插上都能转。

接进来的模型，通常得兼容对话补全（Chat Completions）这套接口格式；至于工具调用（function calling）这类更复杂的能力能不能完整跑通，官方没打包票，得一个个试。

也正因为协议常对不齐，社区还得自己写路由工具在中间转译，而这些，都是目前社区尝试出来的解法，OpenAI官方还没有为此背书。

当GPT与开源模型混搭

在Codex里一起干活

OpenAI官方这边刚开了个口，社区那边已经玩得热闹起来。

原因很简单：Codex好用，但用OpenAI的模型按token计费，太贵。

于是许多开发者都把眼光投向了开源模型。

DeepSeek是很多中文开发者最熟悉的开源模型之一，一个自然的问题是：Codex能不能直接用上DeepSeek？

CC Switch给出的答案是：可以，但不能直接接，需要多一层「中转」。

CC Switch社区教程：《在Codex里用本地路由跑DeepSeek》

其社区教程《在Codex里用本地路由跑DeepSeek》指出，原因在于新版Codex主要基于OpenAI的Responses API，而DeepSeek以及大多数开源模型接口仍以Chat Completions为主。

两套接口在请求结构、流式输出方式、以及工具调用机制上都不完全一致。

所以如果直接把DeepSeek的地址填进Codex，并不能顺利工作，常见情况是请求参数不匹配或返回结果无法被解析，导致调用失败或输出异常，而不是简单的「连不上」。

社区的解法，是在中间加一层本地「路由层」或「协议转换器」。

基本流程如下：

1.Codex按Responses API 发请求；

2.路由层把它转换成Chat Completions格式；

3.转发给DeepSeek等开源模型；

4.再把返回结果转换回Codex能识别的Responses格式。

类似的能力并不只有CC Switch提供。

LiteLLM、claude-code-router，以及开发者自建的各种代理服务，本质上都在解决同一个问题：让不同模型通过统一接口规范进行交互。

OpenAI这次开了道口子，但真正落地，还需要社区自己「添砖加瓦」。

这一切背后，是一套混合路由的玩法。

比如让GPT负责规划：拆解任务、设计架构、想清楚要干什么。让开源模型负责执行：把方案变成能跑的代码、批量改文件。

通过这样的混搭，同样一个任务，成本可能砍掉一大半。

除了更省钱，把Codex配上本地的开源模型，代码一行都不出你自己的电脑。

对那些不想把私人项目传上云、也不想一直给API交钱的个人开发者来说，这诱惑一点也不小。

模型战争结束了

接口战争开始了

过去几年，所有人都以为护城河是模型。谁的模型参数大、跑分高、回答聪明，谁就能赢。

但这一次，OpenAI把Codex这一层做成了一个可插拔的接口，它提供的价值也开始向生态入口转移。

OpenAI的算盘，很可能是从一个卖模型的厂商，向一个卖平台和框架的玩家转身：模型随你换，工具得是我的。

谁占住了开发者每天打开的那个入口，谁就握住了分发，就能坐上生态的核心位置。

这也不是OpenAI头一回在开源生态上的布局。

虽然它自2019年推出GPT-2之后长期未再发布开放权重大语言模型，在开源生态（如Llama、DeepSeek等模型）快速发展下，它还是在2025年8月重新推出gpt-oss系列开放权重模型。

这些模型随后被社区工具链（如Ollama、LM Studio等）迅速集成支持，正是如今Codex --oss默认连接支持的。

配置层，OpenAI确实开放了模型接入能力，通过模型提供方抽象层允许第三方模型接入，但并不是任意模型都能直接使用，必须符合其接口协议或通过适配层进行转换。

在协议层，它保留了一道关键约束：以Responses API作为主要交互标准，同时允许通过兼容层支持Chat Completions等其他模型接口。

也就是说，无论接入哪种模型，都需要对齐到OpenAI定义的请求与响应结构，它最终想要做的是把接口标准攥在自己手里。

从这个角度看，这层过去容易被忽视的接口协议，正在成为新的竞争焦点。

也许，这次OpenAI是想用一个不起眼的配置开关，发动一场AI编程的入口之战，这使得它与Anthropic下一阶段的较量，已经不在模型上。

对每天打开Codex的开发者来说，这更是实打实的便利：能跑开源模型、能省下token、还能本地离线。

但越用得顺手，越用得深入，也就越离不开这个入口。