Codex 串接其他模型：config.toml 供應商設定、接成工具與本機 Ollama 完整教學

想讓 Codex 接其他模型，答案先講：要它整段接管，就走「換主模型」，改本機設定檔裡的 model provider；只要它當顧問，就走「接成工具」，主模型不動，用一條終端機指令或 MCP 工具把外部模型叫進來。還沒走上這兩條路的團隊，畫面通常是這樣：左邊開 Codex、右邊開另一個模型，中間靠複製貼上搬家，文字剪過去請對方看看，建議再貼回來讓 Codex 參考，來回幾次之後，上下文散落兩邊，誰改過什麼說不清，一個下午過去，真正完成的工作沒幾件。

會走到這一步，通常出自兩種動機。一種是成本：ChatGPT 訂閱的用量有上限，吃重的任務想換到按量計費的 API 或自己機器上的模型。另一種是能力：某個模型寫中文特別順、某個模型看程式碼特別準，團隊希望 Codex 的工作流程裡也能借到這些長處。這兩種動機都合理，但它們不直接指路：真正決定路線的，是你要新模型扮演的工作角色，動機只是評估時的背景條件，同一種動機可能走向任一條路。

這兩條主路線，再加上 Ollama 與 LM Studio 的本機執行選項，就是本文的完整地圖：設定語法全部對照 OpenAI 官方文件寫成，涵蓋逐欄解讀、驗收方法、相容性陷阱與成本歸屬。還沒裝好環境的人，Codex 安裝教學可以先把前置作業補齊；對 Codex 的整體定位還不熟悉的人，OpenAI Codex 完整指南有完整的介面比較。

先給一個具體情境當參照：一家做專案管理工具的台灣 SaaS 公司，技術寫手要把英文文件轉成中文知識庫，Codex 負責讀原始碼與起草，但她希望語氣與流暢度能借另一個模型的長處，也想知道能不能把夜間的批次整理交給本機模型跑。她的疑問正好對應本文的展開順序：先分清路線，再讀懂設定，然後驗收、算錢、避開陷阱。

快速重點：Codex 接其他模型有兩條主路線。「換主模型」是在本機 config.toml 用頂層的 model 填模型 ID、model_provider 指向自訂 provider，服務網址、金鑰環境變數與 wire_api 這些連線欄位另寫在 model_providers 區塊，讓另一個模型接管整段任務；「接成工具」是主模型不動，用終端機指令或 MCP 把外部模型當顧問呼叫。wire_api 只支援 responses 這個值，所以「OpenAI 相容」不等於能接：Claude 原生端點是 /v1/messages，Gemini 相容層示範的是 chat/completions，介面不同就不能只改模型名稱。驗收順序是先一句短回覆、再一個小檔案的工具任務，確認串流與重試行為後才上正式工作。

想讓 Codex 用別的模型，先分清兩條完全不同的路

先把 Codex 的工作方式用角色分工來看：每一段被完成的工作，背後都有兩種角色在輪替。一種角色負責想，讀你的指示、盤算步驟、把下一步寫出來；另一種角色負責做，開檔案、敲終端機、拉起各種工具，而且每個動作都先過你設下的權限這一關。「接其他模型」因此要拆成兩個問題來問：你想讓新來的模型當主持人，從頭到尾主持這件工作，還是當顧問，只在主模型開口的時候給意見？主持人的功課重心在設定檔，顧問的功課重心在指令與工具，先認清自己要解的是哪一個，才不會白忙。

給一個快速的判斷法：問自己「這個模型要參與多少」。如果答案是「整段工作都交給它」，從任務理解到檔案修改都要它負責，那是在換主模型；如果答案是「只在某個步驟聽它的意見」，例如複查、翻譯、分類，其他流程照舊，那是把它接成工具。判斷錯的代價不小：把顧問需求當成換將需求，你會去改動設定檔、重新驗證整條工作流；把換將需求當成顧問需求，就算一次性借用接得再順，也達不成「讓另一個模型主持整段任務」的目的，最初的問題其實一直沒有被解掉。

路線一：換主模型，讓另一個模型接管整段任務

路線一的起點，是官方文件裡一個具體的名詞：model provider（模型提供者）。官方進階設定文件給它的界定，是一份說明「Codex 怎麼連到某個模型」的連線資料，攤開來有四件事：服務的基底網址、雙方通訊用的協定、身分驗證的方式，需要時再加上自訂的 HTTP 標頭。你在 config.toml 把這份資料寫妥、指名採用，等於把主持工作的位子交給它背後的模型：之後你下的每一道指令都由這個模型解讀，讀檔、規劃、改碼的每一步也都由它拍板。走這條路的團隊，通常已經做過某種採購或評估決定，例如公司統一簽了某個 API 服務，或實測後認定某個模型在自家任務上表現更穩。

有一個期待要先降下來：把對話接上，不等於把能力搬過來。連線通了的證據，是它順利回了你一句話；但代理工作倚賴的工具呼叫、串流輸出、長任務續航，每一項都是獨立的能力，分別繫於 Codex 這一端的支援、服務這一端的放行、模型這一端的本領，三邊都到位才算數。所以本文把驗收獨立成一節，而且要求逐關過，不走「能回話就上線」的捷徑。

換主模型也不見得是全有或全無。config.toml 支援同時定義多個 provider，你可以在設定檔裡保留內建的 OpenAI 設定，再新增一個公司採購的服務、一個本機的 Ollama，按需求用不同的設定檔或指令切換。這種「多套並存、按任務選用」的用法，比一次把所有工作都搬到新模型穩健：先用小流量試營運，觀察幾週的產出品質與成本，再決定要不要把主要工作遷移過去。

路線二：主模型不動，把外部模型當顧問呼叫

多數人想要的可能不是換掉主模型，只是多一雙眼睛。文章寫完想請另一個模型挑毛病、翻譯想比對兩種譯法、分類結果想二次確認，這些都是「特定步驟借力」的需求。此時主模型繼續主持工作流程，只在需要的時候把整理好的問題交給對外的工具去送，收回意見後由主模型核對、採用或追問。主模型的工作脈絡沒有中斷；不過「對方實際看到多少」不能想當然：外送內容由工具的實作、它帶上的上下文與你授予的權限共同決定，有時會比那一句提問多，這點在後面「資料流向」一節會攤開核對。

這條路還有一個容易被低估的好處：改動面小。換主模型是結構性的改動，設定、驗證、習慣都要跟著調；接成工具不必動設定檔，借用的那一步不需要了，就停掉後續呼叫。但「停用」的限度要說清楚：已經送出去的內容、已經產生的費用、已經改動的檔案，都不會因為停用而回復；借用的若是一個會自動載入設定的工具（像預設會載入 hooks 與 MCP 設定的 claude -p），它在停用前做過的事也一樣留在紀錄裡。對還在評估「另一個模型到底有沒有比較好」的團隊，先用工具路線收集真實使用經驗再考慮升級，價值在於把實驗範圍縮小、隨時能停止後續呼叫；零風險它給不了。

這條路的實作有兩個層次：一次性的借用走終端機指令或 API 呼叫，反覆使用的需求可以做成 MCP 工具掛進來。兩種做法後面會展開，先把觀念立在這裡：借力不必換將，很多團隊卡在「要不要換主模型」的決策太久，其實第一個實驗從一條指令就能開始。

拿前面 SaaS 寫手的例子說：文件草稿完成後，她只需要請另一個模型把指定那一節從頭讀一遍，回報一份「讀到哪一句時停下來重看了第二次」的清單，只要句子編號，其他都不用給。這個需求不需要動主模型、不需要改設定檔，只要 Codex 能執行一條終端機指令，把段落送出去、把意見收回來。整個流程的進入門檻很低，試過幾輪再決定要不要把它做成常駐的 MCP 工具。

子代理是分工，不是串接

這裡有個容易混淆的名詞：子代理（subagent）。Codex 支援把一部分工作委派給子代理執行，聽起來很像「已經接了別的模型」，但官方文件寫得很明白：沒有為子代理分開設定模型或推理強度時，子代理會直接繼承父代理的模型與推理強度。換句話說，開十個子代理，用的可能還是同一個模型。要讓子代理跑在不同的模型上，官方文件列出三種做法：直接在提示裡指定模型或推理強度、在 config.toml 的 [agents] 區塊設預設值，或在自訂 agent 檔案裡明寫 model 與 model_reasoning_effort。

還有一個成本面的提醒，同樣來自官方文件：子代理各自做自己的模型與工具工作，token 消耗會高於相當的單代理流程。把「多開幾個子代理」當成免費的平行運算，帳單會給你答案。還不熟悉怎麼把工作拆給 Codex 的人，可以先把Codex 新手提問框架練熟，再來碰多模型的主題。

換主模型的設定：讀懂 config.toml 的 model_providers

接下來的設定全部發生在本機 CLI 的範圍：設定檔是本機檔案，指令是終端機指令，桌面 App 與雲端環境適不適用同一套設定，要看該介面自己的支援。動手前先把既有設定檔備份一份，改壞了至少回得去。TOML 是這個設定檔的格式，可以把它想成「欄位名稱等於設定值」的純文字，用文字編輯器就能改。

動手前先拿到三項資料

動手前，先跟服務商或公司裡管系統的人把三件事問到手：API 要打去哪個網址、有哪些模型 ID 能用、身分驗證走哪一條路。其中模型 ID 值得多看一眼：那是 API 端認模型的代號，常和官網行銷頁上的名稱對不起來，抄錯一個字，服務就會回你找不到模型。三項裡最需要追問的是「相容」兩個字的實際範圍，這個問題留到相容性專節拆開講。

模型 ID 的查法因服務而異，原則只有一條：向提供者本人索取，或查該服務的官方文件，不要從官網行銷頁的名稱推測。Ollama 有官方字樣可循，終端機輸入 ollama ls，列出的是本機已拉取的模型；LM Studio 的開發者文件則是在請求範例裡示範模型 ID 的寫法，實際有哪些 ID 可用，以它的文件與應用程式呈現的資訊為準。把 ID 抄下來時順手確認大小寫與冒號後綴，例如 gpt-oss:20b 與 gpt-oss:120b 是兩個不同的模型，抄錯一個數字，跑的就是另一個東西。

四個關鍵欄位各在做什麼

自訂 provider 的設定寫在 config.toml 的 model_providers 區塊裡，每個 provider 有四個關鍵欄位：

• name：這個 provider 的顯示名稱，給人看的，中文英文都可以。
• base_url：這個 provider 的服務入口，所有請求都往這裡送。
• env_key：供應 API 金鑰的環境變數名稱。注意，這欄填的是變數的名字，不是金鑰本身。
• wire_api：provider 使用的通訊協定。官方設定參考明寫 responses 是唯一支援的值，省略時也是以它為預設。

四個欄位裡最容易輕忽的是 wire_api。它決定 Codex 用哪種協定跟服務說話，而官方設定參考寫得斬釘截鐵：responses 是唯一支援的值，省略時也以它為預設。有人會想把這欄換成 chat 之類的其他格式來「硬接」只提供 Chat Completions 的服務，這條路在目前的官方文件裡不存在，填了不在支援範圍內的值，結果就是連不上或行為無法預期。服務不講 Responses 介面時，正確的動作是換服務、加轉接層，或改走工具路線，不是改這個欄位。

一份可以直接對照的設定範例

接下來這份範例從頭到尾都是占位值，服務位址、模型 ID、變數名稱一概要換成你自己的資料，照抄上去是跑不動的：

model = "REPLACE_WITH_MODEL_ID"
model_provider = "my_gateway"

[model_providers.my_gateway]
name = "My compatible gateway"
base_url = "https://gateway.example.net/v1"
env_key = "MY_GATEWAY_API_KEY"
wire_api = "responses"

逐行拆解。最上面兩行是全組的開關：model 這欄填的就是模型 ID；model_provider 填 provider 的 ID，要跟下面中括號裡那個名字一字不差，範例中是 my_gateway。走進區塊，name 只是給人看的標籤；base_url 決定請求送達的服務入口；env_key 指名讓 Codex 去哪個環境變數裡撈金鑰；wire_api 沒有第二個選項，就是 responses。

這個寫法不是猜出來的。官方的進階設定文件本身就給了三個範例：一個經過代理伺服器連 OpenAI 的 provider、一個指向本機 Ollama（服務網址 http://localhost:11434/v1）的 provider、一個連 Mistral API（網址 https://api.mistral.ai/v1，搭配名為 MISTRAL_API_KEY 的金鑰變數）的 provider，範例原文可以在官方進階設定文件看到。各欄位的語義說明，再以Codex 官方設定參考逐欄對照。

env_key 填的是變數名，不是金鑰

把金鑰直接寫進設定檔是很常見的直覺，官方也確實提供了直接填 bearer token 的欄位，但設定參考在同一行標註了不建議，請改用 env_key。整理起來，金鑰有三種給法：環境變數（官方建議）、直接填寫 bearer token（官方明確標註不建議）、外部指令取 token 的 command-backed 認證。照這條官方建議的路走，範例設定檔裡不會出現金鑰實值；不過 env_key 只處理金鑰這一項，設定檔裡其他欄位（例如直接填寫的 token 或自訂 HTTP 標頭）仍可能含敏感值，要進版本庫或分享給同事前，逐欄再檢查一遍。

環境變數要在終端機裡設。macOS 與 Linux 用 bash 或 zsh：

export MY_GATEWAY_API_KEY="換成你的金鑰"
codex

Windows PowerShell 則是：

$env:MY_GATEWAY_API_KEY = "換成你的金鑰"
codex

變數名稱必須與 env_key 那欄完全相同，而且這種設法只對目前的終端機視窗有效，視窗關掉就要重設。金鑰是照顧帳單的鑰匙，不要貼進對話、文章或公開的程式庫裡。

設定檔在哪：預設位置與 CODEX_HOME

預設的設定檔位置是家目錄下的 .codex 資料夾裡的 config.toml。如果你設過 CODEX_HOME 環境變數，狀態根目錄會跟著搬：設定檔、對話紀錄、skills 這類所屬狀態改放到新路徑下。官方文件提醒，這個變數指向的目錄必須已經存在。也要留意「搬走」不等於「切斷」：官方進階設定文件點出，登入資訊可能存成檔案，也可能放在作業系統的鑰匙圈裡；日誌目錄與 SQLite 狀態資料庫另有各自的獨立路徑設定，不必然跟著根目錄走。想在同一台機器上分開兩套用法（例如一套用公司 API、一套用本機模型），改 CODEX_HOME 是主要手段，但隔離的邊界在哪，要按上面幾項逐一確認。

實際的分法長這樣：預設環境留給日常的 ChatGPT 登入，再用 CODEX_HOME 指到 ~/.codex-work，裡面放一份接公司 API 的 config.toml，寫個小腳本啟動時先設好環境變數再進 CLI。這樣分開的是主要使用者設定與多數狀態；不過官方文件的設定優先序同時顯示，其他設定層也會參與決定最終值，而且各層能蓋掉的欄位並不相同。provider 相關的 model_provider、model_providers，官方明定專案層的 .codex/config.toml 不能覆寫（讀到還會印啟動警告），要設就設在使用者層；model 之類的欄位則仍可能被啟動旗標、--config 覆寫、專案層或 profile 蓋過，系統層的優先序又低於使用者層。認證若存放在鑰匙圈，更不隨這個變數搬走。所以測試新的 provider 設定時，按欄位分開想：provider 鍵看使用者層這一份，其他鍵把啟動方式與各層設定一起看，確認完再動手跑。唯一要記得的是新路徑下的目錄要先建好，否則啟動會直接失敗。

三個保留 ID 不要碰

自訂 provider 的 ID 有三個是內建保留字：openai、ollama、lmstudio。設定參考明確寫著這三個 ID 不可被覆寫，自訂的 provider 要取別的名字。取一個描述用途的名字，例如 my_gateway、company_proxy，日後打開設定檔一眼就懂誰是誰。

串接後的驗收：三個關卡依序過

設定寫完只是把線插上，能不能用要靠驗收。把驗收拆成三個關卡，每一關都有明確的通過標準，出問題時才知道斷在哪一層。

三個關卡整理成表，驗收時照著走：

↔ 左右捲動檢視完整表格

關卡	做什麼	通過標準	沒過時先查什麼
第一關：短回覆	要 Codex 回一句打招呼的短句	一句話完整回來，沒有錯誤訊息	金鑰變數名稱、模型 ID、服務網址三項依序檢查
第二關：小檔案	請它讀幾行文字檔並回報指定那一行	回報內容與檔案實際內容一致	工具權限、工作目錄、模型是否支援工具呼叫
第三關：失敗行為	觀察串流、重試與長一點的任務	回覆持續完整，失敗時行為可預期	重試與逾時設定、上下文長度、可取得的伺服器端用量資料

第一關：一句短回覆，先排除連線與認證

開一個丟了也不心疼的沙盒資料夾，從那裡把 Codex 叫起來，出的第一道題越簡單越好：要它回一句打招呼的短句就收工。這一步會撞上的錯誤大致三類：認證失敗（金鑰變數沒設好、名稱對不上）、找不到模型（模型 ID 填錯）、通訊格式錯誤（服務不講要求的協定）。哪一類就修哪一類，正式的專案資料先按住不動；連一句招呼都要不到的階段，是你除錯變數最少的黃金期。

這一關還有個隱藏價值：確認回覆真的來自你的新 provider。做法是把可對應到這次測試的證據湊齊：這次用的模型 ID、發出的時間、客戶端留下的對話與執行紀錄，然後到伺服器端你拿得到的用量頁面，看有沒有時間與模型都對得上的項目。對上了，證據才算扎實；一時對不上，先列為待查，因為用量頁面未必即時更新，也不一定把每一筆都攤開給你看，而同時段的其他工作同樣會產生新請求，單看「有沒有多一筆」就往任一方向下結論都太早。驗收從第一關就要養成這種核對習慣，別等到月底帳單來了才發現跑了半個月的都是舊模型。

第二關：一個小檔案，確認工具真的能動

文字回來之後，換一個能證明「手」也聽話的任務：自己先建一個五行左右的純文字檔，在其中一行寫一句你當場編的、任何文件都查不到的句子，然後請 Codex 讀這個檔案，說出那句話在第幾行。判讀時手上有兩份證據可以交叉：工具執行紀錄會寫下它實際打開了哪個路徑、送進了什麼；模型回報的行號對不對，則顯示它有沒有把讀到的內容用對。但兩種觀察都只是線索，不是判決。紀錄一片空白卻冒出答案，尚不能證明它真的讀了檔，模型也可能憑猜測給出答案，先確認你看到的紀錄是否涵蓋它真正的執行路徑；紀錄正常而行號錯了，也不能就此把問題鎖定在模型，因為工具輸出進入流程時另有 token 預算（官方設定參考列有 tool_output_token_limit，規範個別工具輸出存入紀錄的預算），送達模型的內容可能比工具實際看到的短。逐層查下去：先看工具實際輸出什麼，再看傳進模型的是哪些，最後看模型怎麼答，錯在哪一層就修哪一層。會聊天與會用工具是兩種能力，這一關把兩者拆開，各自打分數。

第三關：看清失敗行為與長任務表現

上正式工作前，把失敗情境的參數看清楚。Codex 對 provider 的請求有明確的重試與逾時設定：HTTP 請求失敗最多重試四次、串流中斷最多重試五次、串流閒置超過五分鐘視為逾時，這些都是預設值，可以調。知道預設行為，服務不穩時你才能判斷是「還在重試」還是「已經放棄」。另有三個規格要逐一向提供者確認：上下文視窗、工具呼叫與串流輸出。上下文視窗指的是單次請求裝得下的對話、檔案與工具回傳總量，模型宣稱的數字、服務實際放行的上限、Codex 真正用到的大小，三者不必然相同。

實際觀察有幾個動作。挑一個要讀三、四個檔案才動筆的任務讓它跑，眼睛顧三件事：輸出是持續流出，還是停頓很久才一次吐完；中途斷線時，畫面上重試了幾次、隔了多久才再來；任務拉長之後，它還記不記得開頭交代的事。同一時間把你拿得到的伺服器端用量資料放在旁邊，用模型 ID 與時間過濾出屬於這次測試的請求，再跟客戶端的畫面交叉核對，看畫面顯示的重試有沒有對應得到的項目。要說清楚的是，官方文件保證的是重試參數本身（HTTP 重試與串流重試的上限都可設定），並不保證每個服務的用量頁面都即時、完整地呈現每一次請求，請求若根本沒抵達伺服器，伺服器端自然也不會有紀錄；紀錄取不到或對不上時維持待查，不要硬推論。這一關看的不只是「能不能動」，更是「壞掉的時候怎麼壞」，後者才是上線之後會天天遇到的真實情境。

不換主模型：把另一個模型接成工具

需求如果只是「偶爾請另一個模型看看某段文字」，換主模型是殺雞用牛刀。工具路線的分工是：主模型把要問的事打包好，對外連線這件事交給一條指令或一支小程式去執行，對方回話之後，判讀與採用仍然由主模型收尾。以下從一次性借用講到正式的 MCP 工具化。

一次性借用：claude -p 的非互動模式

假設電腦上已經裝好並登入 Claude Code，它就有一個現成的非互動模式：加上 -p（或 --print）旗標，它就收下一段提示、給出結果、然後退出，全程不需要人盯著。再搭配 --output-format json，回傳的內容會變成程式可以讀的欄位，官方文件說明這種輸出還包含總成本與每個模型的成本拆解，正好適合被另一個程式呼叫，不過同一份文件也講明，這兩個數字是客戶端的估算值，可能與實際帳單有出入；續接先前的對話時，回報的更是整段對話的累計（先前幾次的花費也計入），不要直接當成這一次跑掉的實付金額。語法細節在Claude Code 官方文件的非互動執行段落。

claude -p "把這句話換個說法，一句話就好：新款的報表功能下個月上線。" --output-format json

下一步，把這條指令交給已開放終端機執行權限的 Codex 去跑，跑完讀回輸出、消化成建議。要記得帳是分開的：你動用的是 Claude Code 自己的登入、額度與環境，Codex 這邊一切就緒，不代表那一邊也登好了，兩套要分頭打理。不想靠別家 CLI 吃飯的話，另一個選擇是繞過現成工具、自己寫幾行程式去敲模型服務的 API，例如透過 OpenAI SDK 連 Ollama，把 base_url 指到它的相容端點 http://localhost:11434/v1，api_key 這欄照規定必填，填 ollama 這個占位值即可（實際不會用到）。自寫程式換到的是輸出格式的完整主導權，代價則是認證、重試、錯誤處理全落到自己肩上，等於把 CLI 原本代勞的雜務一項項搬回自己桌上。還沒用過 Claude Code 的人，Claude Code 上手指南從安裝到交辦觀念有一整套。

反覆使用：用 codex mcp add 掛上現成的 MCP server

同一種借用做到第五次，就該讓它變成固定編制。MCP 的用途，是替 AI 應用訂出一套掛載外部工具與資料來源的共同規格；把「請外部模型複查稿子」做成一個 MCP server 之後，主模型每次要複查就直接呼叫，不必每一輪重新交代流程。動手指令之前，先把一個常見誤解拆掉：codex mcp add 做的是「登記」，不是「製造」：它把一個已經存在、你有辦法啟動的 server 寫進 Codex 的設定，並不會幫你把那個 server 生出來。server 的來源一種是取現成的（官方文件的範例就是用套件執行器直接啟動一個現有 server），另一種是你自己照 MCP 規格開發，這兩條取得路徑不在本文範圍；本文示範的是「掛載」這一步。指令的形狀：先給 server 命名，需要環境變數就用 --env 一個個接上，-- 之後放這個 server 的啟動命令：

# -- 後面換成你那個 server 的實際啟動指令（占位示意，照抄不可執行）
codex mcp add my-reviewer -- REPLACE_WITH_SERVER_COMMAND
codex mcp list

官方的 MCP 說明給了完整的指令格式與以現成 server 示範的啟動命令；server 掛好之後，打開 Codex 在介面裡輸入 /mcp，就能檢視目前掛上的清單，詳細說明在Codex 的 MCP 設定文件。兩件事先記住：清單列得出來，只證明設定被讀到了，要真的叫得動工具、拿回正確結果，這條線才算通；而且 MCP 這層規格本身不附帶模型：工具後面接誰家 API、外送哪些資料、費用怎麼算，全看實作的人怎麼寫。工具設計的原則與邊界，Claude Code 接 WordPress 的 MCP 實例有很好的示範，Codex 進階操作則把 CLI 的進階用法整理齊了。

資料流向：外送範圍由工具與設定決定

把工具路線的資料動線攤開看：你先提出需求，主模型把要問的東西整理成一份提問，負責對外聯絡的程式帶著它去敲外部模型的門，對方回話之後，主模型再驗收、消化、併回手邊的工作。但要說清楚：外送範圍不是這條路天然附贈的保證，而是由三件事共同決定，工具怎麼實作、當下帶了哪些上下文、你給了它什麼權限。以本文示範的 Claude Code 非互動模式為例，官方文件寫明，不加 --bare 的 claude -p 會像互動模式一樣載入 hooks、skills、MCP servers、記憶與 CLAUDE.md 等設定，也能視權限讀取檔案，因此實際送出的內容可能比那一句提示多。所以送什麼、不送什麼，不能靠想像，要靠證據核對：看該工具留下的執行紀錄、看伺服器端拿得到的請求與用量紀錄；機密文件要跨出內部環境之前，合約與資料政策也先看過一遍。

要請 Codex 幫你把這條路搭起來，第一次交辦就把邊界寫死，比事後喊停有效。一種寫法：「我要一個能隨時問另一個模型的窗口。先別動手——把你打算走的做法、這條路會動到我機器上的哪些東西、花費會記在誰頭上，寫成十行以內的計畫給我；我回覆『去做』之前，你只讀不寫。」計畫審過再放行，代理工具才不會在你看不到的地方先把東西裝好。輪到真正派工，題目要收斂到可以驗收：別問「這段寫得好不好」，要問「這一節有八個句子，標出哪些句子裡出現兩個以上的動作，只要編號，不要改字」。前者收回來的是感想，後者收回來的清單你能逐條核對。意見多了一個來源，不等於正確多了一分，主模型對照原文判斷的責任沒有減少。

意見收回來之後的使用紀律，比「有沒有接到」更影響產出。好的做法是把外部意見當成待辦清單的輸入，逐條對照原文決定採用、修改或駁回，並留下為什麼；不好的做法是把整包意見直接套用，等於把編輯權讓渡給一個只看過部分上下文的模型。多模型協作的價值來自不同意見的碰撞，而不是來自多數決，這個觀念在換主模型的情境一樣成立。

本機執行：Ollama 與 LM Studio 兩條本機路線

--oss 與 --local-provider：官方的本機模式

Codex 有官方的本機路線：加上 --oss 旗標，就可以對本機的開源模型 provider 執行，支援 Ollama 與 LM Studio 兩種。單次執行要指定哪一個，用 --local-provider；想設成預設，在 config 裡寫 oss_provider。兩個都沒設的話，互動式 CLI 會跳出提示讓你選，但 codex exec 這種非互動執行會直接報錯，自動化腳本要特別注意。

這個細節值得展開：互動模式遇到沒設 provider 會停下來問你，是非工程師的緩衝墊；codex exec 沒有人可以問，直接以錯誤結束。所以任何寫進 CI、排程或批次的 --oss 指令，都要嘛帶 --local-provider，要嘛確認 config 裡已經設了 oss_provider，兩者至少其一。除錯時先看這一項，再去看服務本身有沒有起來。

codex --oss --local-provider ollama
codex --oss --local-provider lmstudio

Ollama 實戰：預設模型、換模型與 64k 上下文

Ollama 在 2026 年 1 月 15 日的官方部落格直接示範了這條路：裝好 Codex CLI 之後用 codex --oss 啟動，預設使用本機的 gpt-oss:20b 模型；要換模型就用 -m 旗標指定，例如較大的 gpt-oss:120b；雲端版的模型也能配 Codex，例如完整模型 ID gpt-oss:120b-cloud；實際有哪些雲端版模型可用，以 Ollama 伺服器端提供的清單為準。這代表「本機跑小的、雲端跑大的」可以用同一套指令切換。

把前置補齊再上路，缺一樣指令就會在半路停下來：Codex CLI 要先裝好（Ollama 文件引用的官方安裝命令是 npm install -g @openai/codex）；Ollama 服務要在本機跑著，桌面版通常常駐，純命令列環境用 ollama serve 起服務；模型要提前拉好，ollama pull 後面接模型 ID，拉了哪些用 ollama ls 核對。

接著看啟動與切換。Ollama 的 Codex 整合文件給了一條快速通道：在終端機輸入 ollama launch codex，Ollama 會為這個 session 建立專屬的 Codex profile 並刷新模型目錄；session 起來之後在 Codex 裡輸入 /model，就能在「已安裝、支援工具呼叫」的本機模型之間切換，不必重開；想放進選單的模型，先用 ollama pull 拉下來才有。不想先起 session，用 ollama launch codex --config 可以直接調這個 profile 的設定，每個模型在此保有自己的上下文視窗、視覺與思考參數。同一份文件也給了手動路線的 profile 範例：base_url 指向 http://localhost:11434/v1/，wire_api 填 responses，與前面自訂 provider 的寫法同一套邏輯。

上下文長度是這條路的關鍵規格，Ollama 官方整合文件對此給的建議是：給 Codex 用的上下文視窗至少 64k tokens，設定的位置就在前一段 --config 打開的模型參數裡。為什麼水位要抓這麼高，值得用白話講一遍。代理工具的工作方式，是把任務說明、讀進來的檔案內容、工具回傳，加上先前來回對話保留或壓縮後的版本，一起放進同一個上下文裡送給模型；官方設定參考也明列自動的對話壓縮機制與工具輸出的 token 上限，所以任務越長、讀的檔案越多，佔用的水位就越高。64k 是官方給的建議值而非硬門檻：實際會不會漏，取決於任務長度、伺服器端實際放行的上限，以及你自己實測的結果。模型開始忘記前面說過什麼、重複做已經做過的事、或直接截斷，這些現象可以列為上下文吃緊的排查線索，但別據症狀直接歸因，官方文件並沒有為它們建立確定的診斷關係，下判斷前先核對實際的 token 用量、壓縮設定與伺服器端放行的上限。這裡還要把兩件事分開：上下文長度是模型與服務的規格，和模型本身的參數大小是不同的數字，官網列的上下文上限、服務實際放行的值、任務真正需要的量，三個要分開查。選本機模型時，先按官方建議把水位設到 64k 以上，再拿自己真實的任務實測，比只看模型名稱可靠。

LM Studio：本機的 Responses 端點

LM Studio 走的是相容層路線。LM Studio 開發者文件載明，它的 OpenAI 相容層在本機 1234 埠提供 Responses 端點，支援串流、推理內容、以 previous_response_id 續接前一次回應，也支援遠端 MCP 工具。對 Codex 來說，這正是 wire_api 要求的介面形狀，所以它能列入 --oss 的支援名單。對照之下，Ollama 的相容層是在 11434 埠，它自己的 OpenAI 相容性說明以 chat completions 示範，Python SDK 連它時 base_url 指到 http://localhost:11434/v1，api_key 一定要填但實際不會用到；不過這份相容性示範不是 Codex 的接法，前一段已提過，Ollama 給 Codex 的官方 profile 同樣用 responses 介面。所以兩個服務要分清的是兩件事：預設埠號不同（LM Studio 在 1234、Ollama 在 11434），以及網路上舊教學示範的端點未必是 Codex 需要的那一種，抄設定前先確認手上的範例講的是哪種介面。

本機不等於免費離線

「模型在自己機器上跑」常被簡化成「免費又離線」，實際上有三個但書。第一，本機推論的第一道門檻是硬體：模型常駐時吃記憶體，檔案先占磁碟，跑起來再燒運算力，模型越大、任務越長，機器的負擔越重。第二，模型下載本身需要網路，檔案大小與占用的頻寬、磁碟空間依模型而定，模型越大越可觀。第三，雲端版的模型（例如名稱帶 -cloud 的選項）推論仍然發生在雲端，走的是 Ollama 的雲端服務。看不見第三方 API 的帳單，不等於總成本是零，它只是換了一種形式出現。

資料隱私則要說得精確一點。本機路線確實改變了一件事：推論這一步發生在自己的機器上，產生結果不需要把推論的輸入送往雲端 API，對於受合約限制不能把客戶資料丟上雲端的顧問與開發團隊，這常是選本機的第一理由。但「推論在本機」不等於「內容不外送」。工作流程裡的其他環節仍可能把內容送出去，而且有官方文件可查的例子：Ollama 的整合文件明載，經它的 profile 送出的網頁搜尋請求，本機與雲端模型都由 Ollama 的服務執行，要登入才能使用。搜尋、下載模型、外部工具各自會送出什麼、有沒有停用設定，部署前逐一查清楚，「推論在本機」與「全程離線」之間的差距才會縮小。

「OpenAI 相容」四個字的陷阱

wire_api 只認 responses

市面上大量服務掛著「OpenAI 相容」的招牌，但這四個字通常指相容 Chat Completions 這套常見介面，而 Codex 的 wire_api 唯一支援的值是 responses，兩者是不同的介面。這個差距就是「會聊天但不能接 Codex」的主要來源：服務能讓你用 OpenAI SDK 呼叫成功，不代表它回應 Codex 發出的那種請求。

採購或評估時，把問題問對：不要問「你們相容 OpenAI 嗎」，要問「你們有沒有提供 Responses 端點」。前者會得到業務員標準答案的「有」，後者才會逼出工程事實。追問三件事更保險：串流回覆（SSE）支不支援、工具呼叫（function calling）支不支援、上下文長度上限是多少。這三項恰好就是代理工具最依賴的能力，也是「會聊天」與「能幹活」的分水嶺。答案有任何一項含糊，就先按不能接處理，用小實驗驗證再說。

三家介面對照：一張表看清差別

↔ 左右捲動檢視完整表格

服務	對話介面	與 Codex provider 的關係
OpenAI	Responses API（wire_api 支援的協定）	Codex 原生使用的介面，自訂 provider 的 wire_api 也只認這個值
Claude	原生 Messages API（/v1/messages）	原生對話端點是 /v1/messages，與 Responses 是不同介面
Gemini	OpenAI 相容層，官方範例走 chat/completions	相容層示範的介面與 Codex 要求的不同，不能只改模型名稱就接上

對照的依據都出自官方文件：Claude API 概覽把對話功能放在 /v1/messages 這個端點，Gemini 的 OpenAI 相容層說明則以 chat completions 示範呼叫。把幾份文件並排看，結論很清楚：聽到廠商自稱 OpenAI 相容，先追問相容的到底是哪一套介面；一旦對方拿不出 Codex 說得通的那種端點，剩下兩條路：中間補一層會翻譯的轉接服務，或者退回工具路線，讓你自己的程式去處理認證與格式。

轉接程式做的事情不神祕：在本機或伺服器上跑一個小小的服務，一邊講 Codex 聽得懂的 Responses 介面，一邊把請求翻譯成目標服務的格式，回應再翻回來。市面上有現成的閘道專案，也有團隊選擇自行實作。要意識到的是，轉接層等於在你與模型之間多放一個經手人：它看得到你送出的全部內容，它的穩定性變成你工作流程的單點失敗，它的計費（如果是付費服務）是第三本帳。能用原生相容服務就優先用，轉接是不得已的工具，不是炫技的場合。

真要挑轉接層，四個問題先問完。誰在維護：這一題開源與閉源要用同一套標準檢驗，看維護者是誰、最近一次更新距離多久、問題回報有沒有人回、Codex 與模型兩邊的介面改版後它跟不跟得上；開源不代表有人持續盯著，閉源也不代表沒在更新，而介面一改、轉接層沒跟上，整條線就斷，這件事只有更新與問題回報紀錄能回答。看得到日誌嗎：你送出的內容它全數經手，它記了什麼、留存多久，要能回答。它壞掉時是什麼樣子：轉接層故障的那一刻，Codex 端看到的是重試再重試，還是直接放棄，先弄清楚才不會把環節問題誤判成模型出錯。費用怎麼算：按請求計費的閘道，把單位成本乘上代理工具自動重試的次數，月底的帳可能比預期肥一圈。

怎麼確認串接真的成功，錢又流向哪裡

別問模型「你是誰」

驗證串接時最不可靠的方法，就是問模型「你現在是不是某某模型」，再把它的回答當證據。模型對自己身分的回答來自提示與訓練資料，接錯模型也可能答出正確的名字。可靠的查證點有三個。第一個是把「此刻生效的設定」查清楚：設定檔只是其中一環，而且各欄位能被哪些層影響並不相同，provider 相關的 model_provider、model_providers 官方明定專案層不能覆寫，變數集中在使用者層設定與啟動方式，model 這類欄位則可能被啟動旗標、--config 覆寫、專案層或 profile 蓋過，所以要把這次怎麼啟動、套了哪層設定一起看，才能確定實際用的是哪個 provider、哪個模型 ID。第二個是調出工具執行的痕跡，確認呼叫真的發生過、送出與收回的內容各是什麼。第三個是到伺服器端，對著你拿得到的請求與用量紀錄核帳，對不上就維持待查。三個點都對上，串接才算被證明，而不是被猜中。

順帶回答一個常見疑問：Codex 桌面 App 裡那排模型選單，跟本機設定檔是什麼關係？官方文件對桌面介面的說明，是用訊息輸入區下方的模型控制項「挑選一個可用模型」；同一份文件也載明，桌面 App、CLI 與 IDE 擴充共用同一份 config.toml 設定檔，所以這套設定不是終端機專屬，你在設定檔指定的模型，桌面端讀的也是同一份。本文的逐步操作以 CLI 為示範情境；桌面選單實際列出哪些型號、怎麼挑，以該介面自己呈現的內容為準，不要把 CLI 的操作步驟照搬到桌面上按圖索驥。

成本要分三本帳

多模型工作流程的錢通常流向三個地方：Codex 原本的使用來源（訂閱或 OpenAI 帳號）、外部模型自己的 API 或方案費用，以及轉接層若屬於付費服務時多出來的第三筆。官方計費文件講得很直白：ChatGPT Work 與 Codex 共用量額，而 API 的 token 費用與訂閱用量是分開的，不要用 API 價格去估算訂閱內含多少任務。同理，你的 ChatGPT 訂閱不會自動涵蓋外部模型的 API 費用，外部服務依它們自己的帳號與方案計費。把三本帳分開記，月結時才不會出現「以為省錢結果加倍」的意外。

月結的實作也不複雜：把三種材料放在一起對照，也就是帳單與收費明細、你實際拿得到的用量資料、自己保存的工作日誌，然後把每筆大額消耗標上當天做了什麼事。訂閱方案實際提供哪些用量資訊，以官方計費文件與你後台看得到的內容為準，不要預設每個方案都有逐月任務明細可以下載。跑一、兩個月，這套流程真正的單位成本就會浮出來，你也會看清楚哪一類任務根本不值得送出外部，留給主模型或本機模型處理反而划算。

上場前的收尾檢查

把全文收斂成一張上場前的心智檢查表。路線選了嗎：整段接管走 provider、借力走工具、本機推論走 Ollama 或 LM Studio。資料備齊了嗎：服務網址、模型 ID、金鑰變數，三項都向提供者本人確認過。設定守規矩了嗎：env_key 填變數名、wire_api 填 responses、不用三個保留 ID。驗收三關排好了嗎：短回覆、小檔案、失敗行為。成本分帳了嗎：訂閱、外部 API、中介服務三本分開。五個問題都有答案，這套多模型流程才值得放進日常工作。

從一段三百字的文章開始

第一次做模型串接，別拿正式專案練手。挑一段三百字的文章，目標只有一個：讓另一個模型挑出讀起來卡住的地方。這個小實驗要走的步驟隨路線而異：走工具路線，一行終端機指令就能起跑，全程不碰設定檔，功夫都花在交辦與驗收回來的意見；走 provider 或本機路線，才會真的碰到備資料、寫 config.toml、把服務與模型準備到可用這些前置。不論挑哪條，把範圍縮小、每一步都能叫停後續呼叫，出狀況時的影響面就會可控；跑通一次之後，再放大資料量、再把工具常駐化、再考慮換主模型，節奏才穩。

兩條路線沒有優劣，只有對不對得上需求：要整段接管走 provider 設定，要借力走工具化，要留在自己機器上走 Ollama 或 LM Studio。把它們當成工具箱裡的三把扳手，而不是三選一的信仰。想把任務放到雲端環境執行的人，Codex 雲端環境指南整理了容器與沙箱的準備方法；多模型流程跑起來之後怎麼維持穩定，AI Agent 穩定使用指南有進一步的紀律建議。