---
title: "Codex用什麼模型？工作分派、推理強度與成本實戰"
description: "用Luna執行做法明確的工作、Terra當日常開發起點、Sol留給需要判斷的問題、Astra處理最難的整體任務；推理強度另外調，成本要算到可驗收為止。"
canonical_url: https://www.datum.page/zh-tw/docs/models/choosing-codex-model
site: "Datum"
author: "CJ Mario"
author_url: https://www.datum.page/zh-tw/about
language: zh-TW
published: 2026-09-05
last_updated: 2026-09-05
topic: "模型與選型"
kind: concept # 概念
level: intermediate # 中級
tags: [models, openai, codex, cost]
cite_as: https://www.datum.page/zh-tw/docs/models/choosing-codex-model
---

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

> 用Luna執行做法明確的工作、Terra當日常開發起點、Sol留給需要判斷的問題、Astra處理最難的整體任務；推理強度另外調，成本要算到可驗收為止。

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

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

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

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

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

*金額以美元表示。實際可用模型仍會受到方案、登入方式、用戶端版本與推出進度影響（[GPT-5.6 in ChatGPT](https://help.openai.com/en/articles/20001354-gpt-56-in-chatgpt)，擷取2026-09-05）。以下工作配置是實務建議，不是保證適用於每個專案的效能排名。*

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

先看兩個例子。

第一個任務是：

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

第二個任務是：

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

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

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

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

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

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

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

以下模型定位皆出自[官方models頁](https://developers.openai.com/api/docs/models)與[Codex models文件](https://learn.chatgpt.com/docs/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厲害在哪裡](https://www.datum.page/zh-tw/docs/models/gpt-6-astra)。

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

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

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

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

GPT-5.3-Codex-Spark是另一種定位。官方在[speed文件](https://learn.chatgpt.com/codex/agent-configuration/speed)（擷取2026-09-05）明確寫它是**獨立的快速、能力較有限的Codex模型**，為接近即時的程式互動最佳化——不是Sol或Astra開啟加速後的名稱，也有自己的用量限制。

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

目前Spark是ChatGPT Pro使用者的文字限定研究預覽（[Codex models文件](https://learn.chatgpt.com/docs/models)，擷取2026-09-05）；不能把它理解成免費、無限制的旗艦替代品。

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

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

模型決定你使用哪一種能力；推理強度則控制它在任務上投入多少推理。官方的說法很直接：較高的推理投入可能改善複雜任務的結果，但需要更久、用更多token（[Codex models文件](https://learn.chatgpt.com/docs/models)，擷取2026-09-05）。API側這個參數叫 `reasoning.effort`，怎麼選另見[GPT的推理強度怎麼選](https://www.datum.page/zh-tw/docs/models/choosing-gpt-effort)。

實作時，我會這樣設定：

| 推理強度 | 我會優先用在哪裡 |
| --- | --- |
| Low | 局部修改、清楚的問答、簡單文件工作 |
| Medium | 一般功能開發、日常除錯，作為起始設定 |
| High | 困難除錯、架構規劃、重要邏輯審查 |
| Extra High／xhigh | High仍有不足，而且更深入分析確實可能帶來幫助的任務 |
| Max | 少數非常困難、深度比速度更重要的問題 |

這不是把所有工作往右調就會更好的選單。官方建議從預設開始，工作需要更深的規劃、分析或檢查時才提高；不同模型支援的選項也不完全相同（[reasoning指南](https://developers.openai.com/api/docs/guides/reasoning)，擷取2026-09-05）。

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

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

依[Codex models文件](https://learn.chatgpt.com/docs/models)（擷取2026-09-05）：Max是讓選定的模型對單一任務投入更多推理時間；Ultra則使用子代理（subagents），把複雜工作拆給多個agent並行處理。官方直接寫：**多數任務不需要Max或Ultra。**

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

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

Fast mode是加速同一個受支援模型，不是把模型換成更聰明的版本。依[speed文件](https://learn.chatgpt.com/codex/agent-configuration/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頁](https://developers.openai.com/api/docs/models/gpt-6-astra)，擷取2026-09-05）。

我的原則很簡單：人在等結果、速度直接影響工作時，再考慮開Fast。正在跑一個不需要即時互動的任務，就先用一般模式。各模型的倍率速查與換算，另見[Codex開Fast：2.5倍額度，多花150%不是50%](https://www.datum.page/zh-tw/docs/models/codex-fast-mode-cost)。

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

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

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

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

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

可以這樣下指令：

```text
請先閱讀訂單列表、查詢API，以及相關測試，暫時不要修改程式。

目標是新增訂單狀態與日期區間篩選。
請整理最小修改方案、會影響的檔案，以及需要先確認的行為。

特別注意日期邊界、分頁，以及既有權限限制。
區分已從程式確認的事實與尚未確認的假設。
不要加入與這次需求無關的重構。
```

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

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

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

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

```text
請依照剛才確認的方案實作，不擴大修改範圍。

保留既有API的相容性與權限限制，
補上正常篩選、空結果、日期邊界及分頁的測試。

完成後執行專案既有的相關檢查，
回報修改檔案、實際執行的命令與結果。
沒有執行的檢查請明確標示，不要當成已通過。
```

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

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

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

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

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

```text
請審查這次變更，集中找出會影響正確性、權限或相容性的問題。

每個問題都要指出相關檔案、觸發條件與可能後果。
不要只提出命名或排版偏好，也不要為了湊數推測不存在的問題。

請區分已有證據的問題與仍需驗證的疑慮，
並說明現有測試還缺少哪些關鍵情境。
```

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

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

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

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

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

用ChatGPT帳號登入Codex，使用的是方案內含額度，符合資格的Plus、Pro帳號還可以加購點數繼續工作（[Codex pricing文件](https://learn.chatgpt.com/docs/pricing)，擷取2026-09-05）。用自己的API key，則依API用量另外計費——訂閱與API是分開的帳務（[Plus說明頁](https://help.openai.com/en/articles/6950777-what-is-chatgpt-plus)，擷取2026-09-05）。

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

目前個人方案的美元標價為Free免費、Go每月US$8、Plus每月US$20；Pro分為每月US$100與US$200，標示用量分別是Plus的5倍與20倍（[Codex pricing文件](https://learn.chatgpt.com/docs/pricing)與[Pro tiers說明](https://help.openai.com/en/articles/9793128-about-chatgpt-pro-tiers)，皆擷取2026-09-05）。這不代表Codex任務無限量。方案與Chat側額度的細節，另見[ChatGPT怎麼選](https://www.datum.page/zh-tw/docs/models/choosing-chatgpt-model)。

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

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

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

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

計費不只看最後回答多長。推理模型使用的推理token，即使沒有顯示在回答裡，也會按照輸出token計費（[reasoning指南](https://developers.openai.com/api/docs/guides/reasoning)，擷取2026-09-05）。

以下是目前四個主流模型在**Standard、短context級距**下的API單價，每100萬token計費（[官方費率頁](https://developers.openai.com/api/docs/pricing)，擷取2026-09-05）：

| 模型 | 一般輸入 | 快取讀取 | 輸出 |
| --- | ---: | ---: | ---: |
| Luna | US$0.20 | US$0.02 | US$1.20 |
| Terra | US$2.00 | US$0.20 | US$12.00 |
| Sol | US$4.00 | US$0.40 | US$20.00 |
| Astra | US$10.00 | US$1.00 | US$50.00 |

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

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

假設一項工作累計使用：

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

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

| 模型 | 這份假設用量的費用 |
| --- | ---: |
| Luna | **US$0.032** |
| Terra | **US$0.32** |
| Sol | **US$0.60** |
| Astra | **US$1.50** |

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

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

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

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

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

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

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

以Terra為例，單次請求輸入超過272K token時，**整筆請求**的輸入價格為2倍、輸出價格為1.5倍，不是只替超出的部分加價（[Terra model頁](https://developers.openai.com/api/docs/models/gpt-5.6-terra)，擷取2026-09-05）。

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

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

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

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

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

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

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

官方的用量建議也包括：指令精確但移除不必要的context、只提供相關檔案與來源、定義輸出的受眾與長度、精簡 `AGENTS.md`，以及停用用不到的MCP伺服器（[Codex pricing文件](https://learn.chatgpt.com/docs/pricing)，擷取2026-09-05）。

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

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

可以改問：

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

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

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

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

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

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

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

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

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

在Codex CLI的互動介面，可以用 `/model` 選擇模型與推理強度（[Codex models文件](https://learn.chatgpt.com/docs/models)，擷取2026-09-05）；用 `/fast on`、`/fast off`、`/fast status` 控制與檢查加速（[speed文件](https://learn.chatgpt.com/codex/agent-configuration/speed)，擷取2026-09-05）；用 `/status` 查看剩餘用量（[Codex pricing文件](https://learn.chatgpt.com/docs/pricing)，擷取2026-09-05）。

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

幾個邊界要知道（皆出自[Codex models文件](https://learn.chatgpt.com/docs/models)與[ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275-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處理最困難的整體任務。

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

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

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

---

## 本文引用來源

- [GPT-5.6 in ChatGPT](https://help.openai.com/en/articles/20001354-gpt-56-in-chatgpt)
- [官方models頁](https://developers.openai.com/api/docs/models)
- [Codex models文件](https://learn.chatgpt.com/docs/models)
- [speed文件](https://learn.chatgpt.com/codex/agent-configuration/speed)
- [reasoning指南](https://developers.openai.com/api/docs/guides/reasoning)
- [Astra model頁](https://developers.openai.com/api/docs/models/gpt-6-astra)
- [Codex pricing文件](https://learn.chatgpt.com/docs/pricing)
- [Plus說明頁](https://help.openai.com/en/articles/6950777-what-is-chatgpt-plus)
- [Pro tiers說明](https://help.openai.com/en/articles/9793128-about-chatgpt-pro-tiers)
- [官方費率頁](https://developers.openai.com/api/docs/pricing)
- [Terra model頁](https://developers.openai.com/api/docs/models/gpt-5.6-terra)
- [ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex)
