很多人以為 Codex 是「問一次，扣一次」。
其實不是。
真正影響 Codex 額度的，是它讀了多少資料、用了什麼模型、思考多久、呼叫多少工具，以及最後產生多少內容。
同樣一句「幫我把這個網站做好」，如果只讓 Codex 讀三個檔案，可能很快完成；但如果它同時讀了整個專案、數十個錯誤紀錄、很多工具說明，再用高階模型反覆修改，消耗量可能差好幾倍。
所以，想用 Codex 做網站、做產品，真正要學的不是「怎麼少問幾句」，而是：
怎麼讓 AI 每一次工作，都更接近完成，而不是一直重來。
先講結論：最划算的 Codex 用法
如果你是一般創作者、小型工作者，或正在用 AI 做網站和產品，我建議：
- 日常開發使用 Terra。
- 資料整理、分類、重複測試使用 Luna。
- 架構、資安、複雜除錯才使用 Sol。
- Fast mode 平常關閉。
- 同一個目標留在同一個任務，不同目標就開新任務。
- 只提供必要的檔案和資料。
- 要求精簡過程，避免 AI 產生一大篇沒有用的說明。
AGENTS.md要短，而且只放真正需要長期遵守的規則。
這些做法，比單純把提示詞從 100 字縮成 50 字更有效。
Codex 裡的 token 到底是什麼？
Token 可以理解成 AI 讀取和產生內容時使用的基本單位。
它不只包括你打出去的文字，還包括：
- 你的提示詞
- 對話歷史
- 上傳的檔案
AGENTS.md和專案規則- 工具說明
- MCP server 的內容
- 終端機輸出
- 搜尋結果
- Codex 產生的程式碼與回答
- 部分模型的推理內容
OpenAI 現在將 Codex 的使用量換算成 credits，並區分成輸入 token、快取輸入 token 和輸出 token。因此，Codex 不是用「訊息數」這麼簡單的方式計算。
一個簡單的修改，和一個需要掃描整個專案、修改檔案、執行測試、修正錯誤的任務，消耗量當然不同。OpenAI 官方方案說明
不同模型的成本差多少？
目前 Codex 的 GPT-5.6 系列，大致是這樣：
| 模型 | 輸入 token | 快取輸入 | 輸出 token |
|---|---|---|---|
| Sol | 125 credits／百萬 | 12.5 | 750 |
| Terra | 62.5 | 6.25 | 375 |
| Luna | 25 | 2.5 | 150 |
換句話說，在相同工作量下，Terra 約是 Sol 的一半成本，Luna 約是 Sol 的五分之一；輸出 token 的價格則約是輸入 token 的六倍。
這代表一件很容易被忽略的事：
要求 Codex 不要產生不必要的長篇回覆，通常比少打一點提示詞更省。
例如同樣是 10 萬輸入 token，加上 1 萬輸出 token，簡化估算後，Sol 約 20 credits、Terra 約 10 credits、Luna 約 4 credits。
但最便宜不代表一定最好。如果 Luna 做錯後重做三次，最後可能比 Terra 一次完成還貴。因此正確的原則不是「永遠使用最便宜的模型」，而是：
使用能一次完成工作的最低模型。
我該怎麼選模型？
Luna：適合大量、簡單、可重複的工作
例如整理資料、分類連結、提取重點、格式轉換、簡單文字修改、重複執行的 QA，以及檢查網址、欄位或格式。
Terra：適合日常工作
例如一般網站開發、修改前端畫面、撰寫內容、串接簡單功能、執行測試，以及修正一般錯誤。
Sol：適合高價值、不能出錯的工作
例如整體架構設計、複雜錯誤診斷、資安檢查、權限和資料流程、多個系統之間的整合，以及上線前的最後審查。
如果只是把一個按鈕改成另一個顏色，沒有必要使用最高階模型。
Fast mode 真的划算嗎？
Fast mode 約可讓支援的模型快 1.5 倍，但 GPT-5.6 和 GPT-5.5 會消耗 Standard mode 的 2.5 倍 credits。Fast mode 官方說明
所以它的價格效率其實不高。
適合開 Fast mode 的情況，是你正在等一個很短的結果、臨時趕著交付，或等待時間比 credits 更有價值。研究資料、大型網站開發、長時間 QA，通常可以保持 Standard mode。
一般使用者最好的預設值，通常是：
Standard mode + Terra + Medium reasoning。
長對話不一定比較有效率
很多人會把所有事情都放在同一個對話裡，覺得這樣 Codex 比較了解背景。
但對話太長，會出現兩個問題：舊資料會增加上下文負擔，真正重要的資訊也可能被大量無關內容淹沒。
「Lost in the Middle」研究發現，當重要資訊被放在長上下文中間時，語言模型的表現可能明顯下降。Lost in the Middle 研究
Chroma 對多個模型的長上下文測試，也發現輸入內容越長，模型的可靠度往往會下降，甚至在還沒有接近最大上下文限制前，就開始出現問題。Context Rot 研究
所以不要把「能塞進去」誤以為「應該全部塞進去」。
比較好的做法是：
- 同一個目標，留在同一個任務。
- 換了完全不同的目標，就開新任務。
- 長任務可以使用
/compact整理上下文。 - 不要貼整份錯誤紀錄，只提供相關檔案和錯誤位置。
- 讓 Codex 自己先定位需要讀取的檔案。
簡單判斷方式：同一個問題繼續做，就保留上下文；問題換了，就不要捨不得開新任務。
快取輸入可以省很多嗎？
可以。
OpenAI 的 Prompt Caching 規則是：1024 token 以上的 prompt 可以進入快取，必須是完全相同的前綴，固定指令和範例放前面，每次變動的使用者資料放後面；快取輸入的價格通常只有一般輸入的十分之一。Prompt Caching 官方說明
對 Codex 使用者來說，快取通常由系統自動處理，不能像 API 一樣精細指定。但仍然可以做三件事：
- 把穩定的專案規則放進精簡的
AGENTS.md。 - 同一個專案不要每次都改寫一套完全不同的背景說明。
- 不要為了快取，把無關的舊內容一直留在同一個對話。
快取的正確觀念是：重複使用真正需要的固定內容，而不是把所有內容都永久留下來。
為什麼 AGENTS.md 太長也會浪費？
AGENTS.md 很有用，但它不是越長越好。
如果裡面放了已經失效的策略、和目前任務無關的品牌故事、太多重複規則、大量歷史紀錄，就會增加上下文負擔，也可能讓 Codex 更難判斷現在真正重要的事。
比較好的做法是：根目錄放共同規則，特定資料夾放特定規則，已失效內容移出主要指令。每一條規則都問一次：「如果刪掉它，Codex 會不會常常做錯？」如果答案是否定的，就不需要放在每次都會讀到的地方。
中文提示詞真的比較省 token 嗎？
不能這樣簡單判斷。
國際研究發現，同一段內容翻成不同語言後，token 數量可能出現很大的差異，部分語言甚至可能相差 15 倍。多語言 tokenizer 研究
但這不代表「中文一定比較省」或「英文一定比較省」。2026 年一份針對中文 vibe coding 的初步研究，沒有發現中文穩定的 token 成本優勢，而且在測試模型中，中文提示的任務成功率反而較低；研究作者也強調，結果會依模型而異。中文 vibe coding 研究
台灣近期也有研究專門設計適合台灣語境的 tokenizer，確實能改善特定系統的 token 效率；但那是台灣口音 TTS 系統，不等於 Codex 使用的模型。BlueMagpie-TTS 研究
所以最實際的做法是：用自己最精確的語言描述需求，中文說明可以用繁體中文，程式碼、變數、錯誤訊息保留原文。不必為了猜測 token 便宜，就把整段內容硬翻成英文。
真正便宜的是「一次說清楚、一次做對」，而不是某一種語言本身。
Plus、Pro 還是 API？
目前 ChatGPT Plus 約為每月 20 美元，Pro 從每月 100 美元起，提供約 5 倍或 20 倍的使用量；超過方案額度後，Plus 和 Pro 也可以購買額外 credits。ChatGPT 方案說明
我的建議是：偶爾使用就用 Plus，偶爾超量就加 credits，每週多次撞上限才考慮 Pro；要跑自動化、排程或大量批次任務，再考慮 API。
Pro 的價值主要是更高的使用量和較少的中斷，不代表每一個 token 都一定更便宜。
我會怎麼安排一個網站專案？
第一階段研究與整理，使用 Luna，整理需求、參考網站、內容架構、使用者流程和技術選項。
第二階段實作，使用 Terra，建立頁面、修改元件、串接資料、執行測試和修正錯誤。
第三階段高風險檢查，使用 Sol，檢查權限、輸入驗證、敏感資料、依賴套件、錯誤處理、部署風險和維護問題。
第四階段重複 QA，使用 Luna 或 Terra，執行連結檢查、格式檢查、基本互動測試、回歸測試，並產生簡短測試報告。
這樣的分工，通常比整個專案從頭到尾都使用 Sol 更划算。
最後的使用原則
Codex 的成本，不是由你問了幾句決定，而是由每一個任務的上下文、模型、推理、工具和輸出共同決定。
最值得記住的是這五句話：
- 不要用高階模型處理低價值工作。
- 不要把無關資料塞進同一個任務。
- 不要讓 Codex 產生沒有用途的長篇回覆。
- 不要為了省 token 而犧牲一次完成率。
- 不要只追求便宜，要追求「完成一個可用成果」的成本最低。
對大多數人來說，最好的預設組合是：
Luna 做整理，Terra 做日常，Sol 做關鍵判斷；Standard mode，短指令，明確完成標準。
你不是在省 token。
你是在降低每一個網站、內容和產品的交付成本。