OpenAI Codex“最开放”之举引发关注有人欢呼这是OpenAI「最开放」的一次。给Codex装上能随便换模型的插座等于亲手填平自己模型的护城河。它图什么一夜之间OpenAI的编程智能体Codex不再只认自家的GPT而是面向所有开源模型开放了。最先察觉这一信号的是开发者社区。开源模型接入Codex的发现与尝试有开发者在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 CLIv0.92.0用--oss调用本地模型右侧LM Studio在本机1234端口加载openai/gpt - oss - 20b12.11GB对外提供服务全程本地离线。也就是说通过本地模型服务和网络权限配置可以让Codex在本机完成代码生成与推理并在一定程度上实现离线运行与本地化处理。Codex CLI界面启动信息里model一行标着当前模型gpt - 5.2 - codex后面跟着「/model to change」一句命令就能切换模型整套智能体就跑在本机。不过插座装上了不代表什么电器插上都能转。接进来的模型通常得兼容对话补全Chat Completions这套接口格式至于工具调用function calling这类更复杂的能力能不能完整跑通官方没打包票得一个个试。也正因为协议常对不齐社区还得自己写路由工具在中间转译而这些都是目前社区尝试出来的解法OpenAI官方还没有为此背书。GPT与开源模型混搭的实践与优势当GPT与开源模型混搭在Codex里一起干活OpenAI官方这边刚开了个口社区那边已经玩得热闹起来。原因很简单Codex好用但用OpenAI的模型按token计费太贵。于是许多开发者都把眼光投向了开源模型。DeepSeek是很多中文开发者最熟悉的开源模型之一一个自然的问题是Codex能不能直接用上DeepSeekCC 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、还能本地离线。但越用得顺手越用得深入也就越离不开这个入口。