【新智元導讀】有人歡呼，這是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、還能本地離線。
但越用得順手，越用得深入，也就越離不開這個入口。 (新智元)