Codex用什麼模型？工作分派、推理強度與成本實戰

用Codex寫程式，很容易走向兩個極端。

一種是所有工作都交給最強模型，推理強度（reasoning effort）一路開到最高，覺得這樣最保險。另一種是只挑最便宜的模型，遇到問題就反覆要求它「再試一次」，直到自己忍不住接手。

我比較建議第三種做法：依照工作需要，把錢花在真正需要判斷的地方。

修改一段文案，和追查一個偶爾發生的資料錯誤，不應該使用同一套配置。前者的重點是快速完成，後者的重點是找到原因、避免改錯。兩件事都叫「寫程式」，需要的能力卻差很多。

這篇文章會從實際開發情境出發，說明Luna、Terra、Sol、Astra和Spark怎麼分工，什麼時候該提高推理強度，以及怎麼判斷模型到底有沒有幫你省錢。

金額以美元表示。實際可用模型仍會受到方案、登入方式、用戶端版本與推出進度影響（GPT-5.6 in ChatGPT（於新分頁開啟），擷取2026-09-05）。以下工作配置是實務建議，不是保證適用於每個專案的效能排名。

一、選模型之前，先判斷這份工作有多不確定#

先看兩個例子。

第一個任務是：

參考現有測試，替另外二十個相同格式的欄位補上驗證案例。

第二個任務是：

使用者偶爾會看到別人的訂單，但目前找不到穩定的重現方式。

第一個任務可能要修改很多行，第二個任務最後可能只改三行。但我會把更強的模型留給第二個任務。

原因不在程式碼長度，而在於：你是否已經知道正確做法，以及做錯之後有多難發現。

選模型時，可以先問自己三個問題：需求是否明確？結果是否容易驗證？出錯的代價高不高？

需求清楚、範圍局部、測試容易寫的工作，可以從便宜模型開始。需求模糊、牽涉多個模組、錯誤不容易被測試抓到的工作，就值得提早使用較強模型。

這也代表，「先用便宜模型，失敗再升級」不是永遠正確。對於權限、資料遷移、重要交易邏輯，我會直接投入更多分析與審查，而不是等出問題才補救。

二、目前這幾個模型，我會怎麼分工？#

以下模型定位皆出自官方models頁（於新分頁開啟）與Codex models文件（於新分頁開啟）（皆擷取2026-09-05）。

Luna：做法已經清楚，就讓它負責執行#

GPT-5.6 Luna的官方定位是為成本敏感的工作負載最佳化；Codex文件給它的工作範圍是清楚、可重複的任務，例如擷取與分類。

我會優先拿它處理規格明確、容易檢查的工作，例如整理文件、修改註解、依照範例補測試，以及小範圍的規則化修改。

假設你已經知道某個函式需要補上空值處理，也知道預期結果，可以直接交代：

請替這個函式加入空值檢查，維持既有回傳格式，並補上正常輸入、空字串與未傳入參數的測試。不修改其他功能。

這類任務需要的是正確執行，不是重新設計整個系統，我會先試Luna。

但「補測試」也有不同難度。照著已知規格補案例，和找出整個系統缺少哪些重要測試，是兩件不同的事。後者需要推導風險，不應該只因為最後產物都是測試，就一律交給便宜模型。

Terra：日常開發的合理起點#

GPT-5.6 Terra的官方定位是平衡智力與成本，適合需要紮實推理、但不必開到全深度的日常工作。

如果要替一般開發工作選一套起始配置，我會用Terra搭配Medium。

新增表單、串接API、調整分頁、修正有明確重現步驟的錯誤，或依照既有架構完成一項功能，都可以先從這裡開始。

這不是說Terra對所有人都最划算，而是先建立一個基準：它能不能在合理的修改範圍內完成工作？測試是否通過？你需要花多少時間收尾？

如果大部分任務都能順利完成，就沒有必要為每個小功能支付旗艦模型的費用。反過來，如果它經常忽略限制、改錯模組，或需要你反覆補充同樣的前提，就該調整模型，而不是只增加重試次數。

Sol：當你需要它判斷「應該怎麼做」#

GPT-5.6 Sol是GPT-5.6家族的旗艦，定位於複雜的專業工作。

我會把Sol用在需要取捨的任務：架構設計、跨模組重構、難以定位的bug，以及重要程式碼審查。

例如，需求不再是「新增一個欄位」，而是：

這項功能應該放在既有服務裡，還是拆成獨立模組？不同做法會怎麼影響測試、部署與後續維護？

這時候需要的不只是產生程式碼，還要理解限制、比較方案，並指出每個選擇的代價。

我的起點通常會是Sol／Medium；如果問題牽涉很多互相影響的條件，再提高到High。與其讓便宜模型先猜一套架構、做完才發現方向不對，我更傾向在這個階段先把判斷做好。

Astra：把最難、最需要整體判斷的工作交給它#

GPT-6 Astra是OpenAI目前最有能力的模型，面向最難的端到端工作；Codex文件強調它適合跨多個步驟與工具、需要持續推理並顧住原始目標與限制的任務。它是什麼、強在哪，另見Astra厲害在哪裡。

我會考慮用它處理大型系統遷移、跨多個模組的重構、長時間找不到根因的問題，以及限制很多、不能只顧局部正確的任務。

例如，一次資料遷移不只要「把資料搬過去」，還可能需要考慮舊版本相容、失敗回復、分批執行，以及遷移期間系統是否仍能運作。這種工作值得投入更強的整體分析能力。

不過，Astra不是免驗收的通行證。我的做法仍然是要求它提出測試、驗證結果與未確認事項，而不是因為用了最強模型，就接受一句「已完成」。

Spark：適合你坐在旁邊，快速來回修改#

GPT-5.3-Codex-Spark是另一種定位。官方在speed文件（於新分頁開啟）（擷取2026-09-05）明確寫它是獨立的快速、能力較有限的Codex模型，為接近即時的程式互動最佳化——不是Sol或Astra開啟加速後的名稱，也有自己的用量限制。

我會拿它做局部修改與快速試驗，例如改一個元件的程式結構、調整小段邏輯，再立刻看結果。

目前Spark是ChatGPT Pro使用者的文字限定研究預覽（Codex models文件（於新分頁開啟），擷取2026-09-05）；不能把它理解成免費、無限制的旗艦替代品。

三、模型選對之後，才決定要讓它想多久#

選模型和調整推理強度，是兩個不同的決定。

模型決定你使用哪一種能力；推理強度則控制它在任務上投入多少推理。官方的說法很直接：較高的推理投入可能改善複雜任務的結果，但需要更久、用更多token（Codex models文件（於新分頁開啟），擷取2026-09-05）。API側這個參數叫 reasoning.effort，怎麼選另見GPT的推理強度怎麼選。

實作時，我會這樣設定：

這不是把所有工作往右調就會更好的選單。官方建議從預設開始，工作需要更深的規劃、分析或檢查時才提高；不同模型支援的選項也不完全相同（reasoning指南（於新分頁開啟），擷取2026-09-05）。

我不會預設「Luna開Max」就等於「Sol開Medium」。前者是讓較便宜的模型投入更多推理，後者則是換了模型；哪一種更適合，需要拿實際任務比較。

Ultra不是單純比Max再多想一點#

依Codex models文件（於新分頁開啟）（擷取2026-09-05）：Max是讓選定的模型對單一任務投入更多推理時間；Ultra則使用子代理（subagents），把複雜工作拆給多個agent並行處理。官方直接寫：多數任務不需要Max或Ultra。

例如，同時檢查不同模組的相容性，再整合結果，就有分工的空間。反過來，一個只有幾十行、前後緊密相依的函式，我不會為了「更強」就開啟多代理流程。

Fast mode買的是速度，不是更深的分析#

Fast mode是加速同一個受支援模型，不是把模型換成更聰明的版本。依speed文件（於新分頁開啟）（擷取2026-09-05）：GPT-5.6與Astra的Fast mode在適用時以2.5倍的點數速率消耗；API側的priority處理另有計價，GPT-5.6為Standard單價的2倍（Astra的Fast mode同為2倍，見Astra model頁（於新分頁開啟），擷取2026-09-05）。

我的原則很簡單：人在等結果、速度直接影響工作時，再考慮開Fast。正在跑一個不需要即時互動的任務，就先用一般模式。各模型的倍率速查與換算，另見Codex開Fast：2.5倍額度，多花150%不是50%。

而且模型生成速度變快，不代表整項工作一定等比例縮短。若大部分時間花在測試、建置或外部服務回應，我會先量測瓶頸，再決定是否付費加速。

四、實際做一次：替後台訂單列表加入篩選功能#

假設現在要新增「訂單狀態」與「日期區間」篩選。這是一個示範情境，下面的prompt可以依專案調整。

先釐清設計，不急著改程式#

如果專案已經有幾乎相同的功能，直接從Terra開始即可。但若牽涉前後端契約、權限或日期定義，我會先用Sol／Medium或High釐清。

可以這樣下指令：

請先閱讀訂單列表、查詢API，以及相關測試，暫時不要修改程式。
 
目標是新增訂單狀態與日期區間篩選。
請整理最小修改方案、會影響的檔案，以及需要先確認的行為。
 
特別注意日期邊界、分頁，以及既有權限限制。
區分已從程式確認的事實與尚未確認的假設。
不要加入與這次需求無關的重構。

這一步的驗收不是看它寫了幾頁分析，而是看它有沒有找對位置、發現真正需要確認的規則。

「日期區間」到底包不包含最後一天？清除篩選後是否回到第一頁？新條件是否仍保留原本的權限限制？這些才是接下來能不能做對的關鍵。

規格確定後，再交給Terra實作#

當修改方向已經清楚，就可以切回Terra／Medium：

請依照剛才確認的方案實作，不擴大修改範圍。
 
保留既有API的相容性與權限限制，
補上正常篩選、空結果、日期邊界及分頁的測試。
 
完成後執行專案既有的相關檢查，
回報修改檔案、實際執行的命令與結果。
沒有執行的檢查請明確標示，不要當成已通過。

這時候交付的不是一句模糊的「幫我做篩選」，而是已經整理過的工作。

如果後續只剩下依照既有測試格式補幾組資料、更新操作文件，就可以再交給Luna。但不必為了使用每一個模型，硬把任務切成很多段。切換模型本身也需要交接，只有分工帶來的好處大於交接成本時才值得。

換到新對話時，我會留下目標、已確認的規則、相關檔案與驗收方式，不要求下一個模型重新探索整個專案。

最後檢查關鍵風險，不是重新做一遍#

對這種涉及查詢與權限的功能，我會再用Sol審查：

請審查這次變更，集中找出會影響正確性、權限或相容性的問題。
 
每個問題都要指出相關檔案、觸發條件與可能後果。
不要只提出命名或排版偏好，也不要為了湊數推測不存在的問題。
 
請區分已有證據的問題與仍需驗證的疑慮，
並說明現有測試還缺少哪些關鍵情境。

我會特別檢查它提出的問題能不能重現，以及新增測試是否真的在驗證需求，而不只是配合目前的實作。

多跑一次模型審查，不等於完成獨立驗證。涉及重要資料與權限時，我仍會保留人工檢查與實際測試。

這套流程的重點是：在設計階段投入判斷能力，規格清楚後控制執行成本，最後把注意力集中在風險，而不是每個階段都開最強。

五、成本怎麼算？先分清楚訂閱額度和API帳單#

用ChatGPT登入Codex，和使用API key，是兩條計費路徑#

用ChatGPT帳號登入Codex，使用的是方案內含額度，符合資格的Plus、Pro帳號還可以加購點數繼續工作（Codex pricing文件（於新分頁開啟），擷取2026-09-05）。用自己的API key，則依API用量另外計費——訂閱與API是分開的帳務（Plus說明頁（於新分頁開啟），擷取2026-09-05）。

因此，不能用「我已經付了月費」推論API不會再收錢，也不能直接把API價目表換算成訂閱方案能做多少個功能。

目前個人方案的美元標價為Free免費、Go每月US$8、Plus每月US$20；Pro分為每月US$100與US$200，標示用量分別是Plus的5倍與20倍（Codex pricing文件（於新分頁開啟）與Pro tiers說明（於新分頁開啟），皆擷取2026-09-05）。這不代表Codex任務無限量。方案與Chat側額度的細節，另見ChatGPT怎麼選。

我的選擇方式會是：先記錄實際使用情況，再決定升級。

偶爾遇到專案高峰，可以比較額外點數；經常因為額度不足而中斷工作，再比較更高方案。US$200 Pro的月費是US$100 Pro的兩倍，標示額度則是四倍——這個比例只有在你用得到時才有價值；用不完的額度，不會自動變成節省。

使用API，才直接看token單價#

Token可以先理解成模型處理文字的計量單位，不等於字數，也不等於程式碼行數。

計費不只看最後回答多長。推理模型使用的推理token，即使沒有顯示在回答裡，也會按照輸出token計費（reasoning指南（於新分頁開啟），擷取2026-09-05）。

以下是目前四個主流模型在Standard、短context級距下的API單價，每100萬token計費（官方費率頁（於新分頁開啟），擷取2026-09-05）：

這張表未包含快取寫入、工具、加速及其他適用費用。Sol的現行優惠價格，官方標示至少持續至2026-11-21。

用同一份用量，算一次給你看#

假設一項工作累計使用：

100,000個一般輸入token，加上10,000個輸出token；輸出數量已包含推理。

先只比較上述兩個計費項目，不計其他費用，並假設沒有長context或加速加價。計算結果如下：

這是依官方單價計算的固定用量比較，不是每個開發任務的報價，也不是宣稱四個模型完成同一件事會用掉相同token。

這個例子也說明了為什麼不能只看單價。

在完全相同的假設用量下，Terra跑兩輪是US$0.64，已經超過Sol跑一輪的US$0.60。這不代表Sol一定一次成功，而是提醒你：返工會改變成本比較。

對開發工作，我會用下面這個方式評估：

完成成本＝模型費用＋等待時間＋人工檢查與修改時間＋錯誤造成的代價。

便宜模型一次做對，當然划算。較貴模型若能省掉大量人工除錯，也可能划算。反過來，簡單工作用了最強模型，卻沒有帶來可觀察的品質提升，就只是多花費用。

Context越長，也可能跨進更高的計價級距#

以Terra為例，單次請求輸入超過272K token時，整筆請求的輸入價格為2倍、輸出價格為1.5倍，不是只替超出的部分加價（Terra model頁（於新分頁開啟），擷取2026-09-05）。

所以我不會把「模型讀得下」當成「應該全部塞進去」的理由。

需要哪些資料，就讓它取得哪些資料。該看的相依模組不能省，但不相關的文件、歷史討論與大量日誌，也不必每次一起帶進去。

六、真正省錢的習慣，是控制無效工作#

先寫清楚完成條件，再叫它動手#

「幫我優化這個專案」很難驗收。

「修正這個重現步驟造成的錯誤，保留既有介面，不做無關重構，補上回歸測試」，才是能夠判斷有沒有完成的工作。

我會在任務開始前交代清楚：目標是什麼、哪些行為不能改、怎麼確認完成，以及哪些只是可選改善。

官方的用量建議也包括：指令精確但移除不必要的context、只提供相關檔案與來源、定義輸出的受眾與長度、精簡 AGENTS.md，以及停用用不到的MCP伺服器（Codex pricing文件（於新分頁開啟），擷取2026-09-05）。

卡關時，先整理證據，不要只說「再試一次」#

我會設定一個管理原則：連續兩輪沒有實質進展，就先停止盲目修改。

可以改問：

先不要繼續改程式。請整理已確認的事實、已排除的原因、尚未驗證的假設，以及下一個最有助於區分原因的測試。

「兩輪」不是技術限制，只是避免無止境消耗的起始門檻。

整理完之後，再判斷問題在哪裡。缺少重現資料，就補資料；測試環境有問題，就修環境；理解與推理明顯不足，再升級模型。

不是所有失敗，都能靠換更強的模型解決。

用一週的工作紀錄，建立自己的選模標準#

與其一直猜哪個模型最適合，我更建議挑幾種常做的任務，記錄模型、推理強度、是否通過驗收、人工修改時間與用量。

比較時不要只看回覆速度，也不要只看測試是否全綠。要看整項工作從交辦到可接受交付，總共花了多少時間。

對你常做的某類工作，Terra可能已經足夠；對另一類工作，Sol也許能明顯減少返工。這種來自實際專案的差異，比一張通用排名更值得拿來設定預設模型。

七、開工前，先把這幾個設定確認好#

在Codex CLI的互動介面，可以用 /model 選擇模型與推理強度（Codex models文件（於新分頁開啟），擷取2026-09-05）；用 /fast on、/fast off、/fast status 控制與檢查加速（speed文件（於新分頁開啟），擷取2026-09-05）；用 /status 查看剩餘用量（Codex pricing文件（於新分頁開啟），擷取2026-09-05）。

我的日常起始配置會是Terra／Medium，Fast關閉。規格非常清楚的小工作改用Luna，需要設計與困難除錯時用Sol，最複雜的任務再考慮Astra。

幾個邊界要知道（皆出自Codex models文件（於新分頁開啟）與ChatGPT Work and Codex（於新分頁開啟），擷取2026-09-05）：

• 這套手動切換主要適用於可選模型的本機工作介面；Codex雲端聊天目前不能自行更換預設模型。
• 在Codex使用Astra需要Codex CLI 0.153.0以上，桌面App也要更新到最新版。
• GPT-5.4與GPT-5.4 mini已於2026-08-31從ChatGPT登入的Codex退役，官方建議分別改用Terra、Luna；這次退役不影響API與使用自有API key的Codex。
• 一般GPT-5.3-Codex在ChatGPT登入的Codex中已標示棄用，不能和仍作為研究預覽的Spark混為一談。

結語：不要追求每次都用最強，追求每次都交付得了#

我的配置原則是：用Luna處理做法明確的工作，以Terra作為日常開發起點，把Sol留給需要判斷的問題，再用Astra處理最困難的整體任務。

這不是固定階級表。真正重要的是，你能不能辨認這份工作現在缺的是執行、判斷、資訊，還是驗證。

該省的是不必要的推理、重複讀取與無效嘗試；不該省的是需求釐清、重要測試與關鍵風險檢查。

最划算的模型，不是每次呼叫最便宜的那個，而是能以合理的總成本，把這份工作做到可以驗收的那個。