boluoji · 11月13日

Codex CLI第三方模型設定實測：API測試與Profile啟動

把Provider寫進config.toml之後，Codex CLI不一定已經能完成工作。我在2026年11月13日用Windows PowerShell、Codex CLI 0.168.0與deepseek-v4.1-flash重跑一次，結果是兩種API都拿到OK，Profile也能啟動，但讀取README.md的指令被本機策略拒絕。

這份筆記適合已經裝好Codex CLI、準備接OpenAI相容API的工程師。如果只使用官方模型，或只需要單次API呼叫，不必建立獨立Profile。

驗收層次	本次結果	可以確認什麼
模型目錄	HTTP 200，170個模型	目前金鑰看得到哪些Model ID
API回應	Responses與Chat Completions皆回傳`OK`	鑑權、路由與文字輸出正常
Profile任務	Profile已載入，但4條指令被拒絕	模型進入工具流程，檔案任務尚未完成

先確認Codex CLI版本，不沿用舊模型清單

我先執行codex --version，PowerShell回傳codex-cli 0.168.0。版本差異可能影響設定欄位，先記下版本，比出錯後再猜快得多。

Windows PowerShell中的Codex CLI 0.168.0版本

接著呼叫GET /v1/models。這次回傳HTTP 200，共170個模型。我把舊筆記中的12個ID拿來比對，只找到7個：

DeepSeek：deepseek-v4-pro、deepseek-v4-flash、deepseek-v4.1-flash
Kimi：kimi-k2.8-preview、kimi-k2.7-code
GLM：glm-5.3、glm-5.3-flash

沒有匹配到的是doubao-seed-2.1-pro、doubao-seed-2.1-lite、doubao-seed-2.0-mini、doubao-seed-evolving與minimax-m3。

目前模型目錄與舊清單的比對結果

模型目錄的用途不是列出所有理論上存在的模型，而是確認目前金鑰實際能看到的ID。換帳號、權限或上架狀態後都可能不同，因此我會在建立Profile前重新查一次。需要人工核對名稱時，也可以查看目前的模型目錄，但最後仍以自己的/v1/models回應為準。

Codex CLI的Provider與Profile分開設定

共用連線資料放在config.toml，模型選擇放在獨立Profile。這樣切換模型時，只需增加一個小檔案，不必重複修改Base URL與環境變數名稱。

本文使用的Base URL如下：

https://api.crazyrouter.com/v1

config.toml的核心欄位是：

位置	欄位	本次設定
頂層	`model`	`"deepseek-v4.1-flash"`
頂層	`model_provider`	`"crazyrouter"`
頂層	`forced_login_method`	`"api"`
Provider	`base_url`	`"https://api.crazyrouter.com/v1"`
Provider	`wire_api`	`"responses"`
Provider	`env_key`	`"CRAZYROUTER_API_KEY"`

ds41-flash.config.toml只保留model與model_provider兩項覆寫值，啟動時使用codex --profile ds41-flash。

config.toml與ds41-flash Profile的分工

API Key放在Windows使用者環境變數CRAZYROUTER_API_KEY，沒有寫進設定檔或公開截圖。儲存後要關閉原本的PowerShell，再開新視窗。檢查時只判斷變數是否為空，不直接輸出完整金鑰。

先跑最小API測試，再啟動Codex CLI

我用「只回覆OK」做冒煙測試，分別呼叫Responses API與Chat Completions API。

API	HTTP	耗時	輸入Token	輸出Token	可見內容
`/v1/responses`	200	2249ms	35	30	`OK`
`/v1/chat/completions`	200	2394ms	35	38	`OK`

Responses與Chat Completions的實際回傳結果

這兩次結果表示deepseek-v4.1-flash在本次條件下能回傳可見文字。若要重新確認目前模型與價格資料，可在操作段落中查看模型與API資訊，但是否能呼叫仍要以自己的API測試為準。

HTTP 200本身還不夠。我也測了glm-5.3-flash：輸出上限設為16與64個Token時都回傳200，卻沒有可見的最終答案。這代表鑑權與路由已經發生，不能寫成工作完成。

Token量也分成兩個級別。兩次短API測試的輸入都只有35個Token；進入Codex完整會話後，Profile記錄為輸入91,635、輸出850個Token。要測多個模型時，先用短請求排除空回覆，再挑少數模型進Codex，比直接批次啟動Profile省得多。

Profile啟動成功，檔案讀取仍然失敗

我在專案目錄執行codex --profile ds41-flash，要求它讀取README.md並說明專案用途。Profile載入後，模型顯示為deepseek-v4.1-flash，thread與turn也開始執行。

模型先後嘗試：

Get-Content -LiteralPath README.md -TotalCount 60
cmd /c dir
echo hi
Get-Content README.md

四條指令都被目前的命令策略拒絕，檔案內容沒有讀到。

這張圖是從真實Codex會話事件整理出的脫敏摘要，不是原始互動介面截圖。可以確認的是Profile、模型請求與工具呼叫流程已經發生；不能確認Codex已完成檔案任務。

執行時另有Model metadata not found; using fallback metadata警告。第三方模型沒有對應內建資料時，Codex會使用回退資訊。在警告仍存在的情況下，我不會直接假設上下文視窗、Token估算或功能開關完全符合模型原始規格。

依照症狀分層排錯

症狀	先看哪一層	處理方式
`401 Unauthorized`	環境變數與金鑰	重開PowerShell，只檢查變數狀態，再核對金鑰
`model not found`	模型目錄	從目前`/v1/models`複製原始ID
HTTP 200但回應為空	API輸出	查看最終文字與輸出上限，不把200當完成
啟動後模型不對	Profile	核對檔名、`model`與`model_provider`
命令被拒絕	本機執行政策	檢查沙箱、核准與命令規則後重跑同一任務
設定修改沒有生效	工作階段	關閉Codex與PowerShell，再開新工作階段