GPT-6 Sol 與 Luna：Agent 成本、程式開發與快取

快速解答

OpenAI 於 2026 年 9 月 22 日推出 GPT-6 Sol 與 GPT-6 Luna。兩者均已透過 API 提供；OpenAI 表示，它們也正向 Plus、Pro、Business、Enterprise 與 Edu 使用者的 ChatGPT Work 和 Codex 推出。Free 與 Go 使用者可在桌面 App 使用 Luna。OpenAI 同時明確表示，這兩款模型目前尚未在 Chat 中提供。

真正值得注意的不只是 Benchmark 更新。API 價格下降、程式開發能力提升，加上 GPT-6 Prompt Caching 讓長時間運作的 Agent 能更有效重用昂貴 Context。對執行長時間 Coding 或知識工作 Agent 的團隊而言，模型選擇正在變成「每個通過審核成果的總成本」問題，而不只是單次 Prompt 的模型能力比較。

延伸閱讀可參考 Codex 工具頁、ChatGPT 工具頁與 AI Agent 最佳實務。

OpenAI 這次究竟推出了什麼？

GPT-6 Sol 與 Luna 將 GPT-6 家族延伸到 GPT-6 Astra 以下的不同成本層級。OpenAI 將 Astra 定位為最高能力選項；Sol 面向需要較強專業工作與 Coding 能力、但希望降低成本的場景；Luna 則更偏向成本敏感與大量工作負載。

對輸入不超過 272K tokens 的標準 API Prompt，OpenAI API changelog 列出的 GPT-6 Sol 價格為：每百萬 input tokens 2 美元、cached input 0.20 美元、output 10 美元。GPT-6 Luna 則分別為 0.10、0.01 與 0.50 美元。

OpenAI 將此描述為相較 GPT-5.6 對應 Sol 與 Luna 促銷價格降低 50%。這是 OpenAI 自己採用的價格比較基準，不代表每一種真實工作負載都一定能節省一半。

為什麼這對 Coding Agent 特別重要？

長時間運作的 Coding Agent 並不是一次 Prompt 加一次回答。它會在多次請求之間持續攜帶 Repository Instructions、工具定義、程式碼 Context、測試輸出與先前決策。

因此，即使 Benchmark 的提升幅度不是最大的新聞，只要模型能降低「讓 Agent 持續工作數小時」的成本，它仍可能產生很大的實際價值。

OpenAI 報告稱，GPT-6 Sol 在 FrontierCode 上相較 GPT-5.6 Sol 有明顯提升。FrontierCode 不只檢查正確性，也評估測試品質、修改範圍、程式碼風格與是否遵循 Repository 標準等「可合併性」。在 DeepSWE 1.1 上，OpenAI 報告 GPT-6 Sol max effort 得分 68.8%，GPT-6 Luna max effort 為 66.6%。

這些是 Benchmark 結果，不是對你的 Repository 的保證。團隊在更換預設模型前仍應使用自己的任務組合驗證。

GPT-6 Luna 已經足以處理嚴肅的程式開發嗎？

對許多邊界清楚的任務可能足夠，但答案取決於失敗成本。

Luna 的低 API 價格很適合重複性實作、測試產生、Repository 探索，以及其他容易偵測錯誤與重試的大量工作。當任務更模糊、跨越架構邊界，或需要在修改程式碼前做更強推理時，Sol 可能是更合適的預設選擇。

有用的 Routing Policy 不應只是「簡單工作用便宜模型、困難工作用昂貴模型」。它還必須計算驗證成本。

如果便宜模型造成更多測試失敗、修復迴圈或 Reviewer 工時，那麼較低的 Token 帳單可能只是假性節省。

TowCue 判斷：優化每個通過審核成果的成本

最值得看的指標不是每百萬 Tokens 的價格。

對 Agent Workflow，應衡量完整路徑：

任務 → 模型 → 執行 → 測試 → 審核 → 修復 → 接受成果

並把以下成本一起計算：

模型與 Cached Context 成本；
到達可審核成果所需的總時間；
測試失敗與修復回合；
人工 Review 時間；
Review 後返工；
Merge 後才出現的缺陷。

單次請求較貴的模型，最後仍可能有較低的「每個接受修改成本」。當任務定義清楚且驗證機制強時，便宜模型則可能真正勝出。

為什麼 Prompt Caching 也是這次發布的重要部分？

OpenAI 同樣在 9 月 22 日另外發布 GPT-6 Prompt Caching 改進。符合條件、在 30 分鐘視窗內重用的共同 Prefix 可以獲得 Cached Input 折扣；OpenAI 表示 Cached Input Reads 的折扣最高可達 90%。

這對 Persistent Agent 很重要，因為它們經常重複大量穩定 Prefix：System Instructions、Repository Policy、Tool Schemas 與參考資料。

GPT-6 也加入讓 Agent 改變 Reasoning Effort 或可呼叫工具時仍盡量維持 Cache Reuse 的控制方式。開發者可以使用 Explicit Cache Breakpoints、Prompt Caching Dashboard，以及診斷 Cache Miss 的工具。

Caching 並不代表所有 Token 都會變便宜。它真正獎勵的是能把穩定 Context 與頻繁變動 Context 分離的 Workflow。

GitHub Copilot 的快取結果告訴我們什麼？

OpenAI 公告引用 GitHub 的說法：在過去數月中，Prompt Caching 改進讓 OpenAI 模型在數十億次請求裡，需要重新處理的 Prompt Tokens 比例相較先前基準降低超過 50%。

這是 GitHub 向 OpenAI 提供的 Production 結果，不是所有產品都能預期得到的固定節省幅度。實際 Hit Rate 會受到 Prompt 結構、Tool Schemas、請求時間，以及共同 Prefix 改動頻率影響。

但它仍揭示一個重要事實：當 Agent 大規模運作後，Context Architecture 本身會成為實質的基礎設施成本。

團隊應如何在 Astra、Sol 與 Luna 之間分配工作？

應從任務後果與不確定性出發，而不是從模型名氣出發。

對範圍窄、可逆、且有 Deterministic Checks 的任務，可以優先使用低成本層級。當需求模糊、修改跨越多個系統、失敗代價高，或 Reviewer 很難低成本重建推理過程時，再提高模型能力。

也要保留升級路徑。如果 Luna 對一個有清楚邊界的任務反覆失敗，就升級到 Sol；如果 Sol 仍無法解決高風險或異常複雜的問題，再考慮 Astra 這類更強模型是否值得更高成本。

Routing 決策也應該可觀測。記錄每個任務使用哪個模型，並長期比較接受率、重試次數、Latency 與 Reviewer 工時。

更換預設模型前應該測什麼？

不要只依賴公開 Benchmark，應從團隊真正處理的工作建立一組小型 Evaluation Set。

至少包含機械式 Refactor、已知 Root Cause 的 Bug、跨多個檔案的 Feature、測試撰寫任務，以及一個通常需要架構判斷的模糊 Issue。

讓候選模型在相同 Repository Instructions 與 Validation Commands 下執行相同任務。除了程式碼能不能工作，也比較它需要多少修復與人工 Review。

如果 Agent 會攜帶大量重複 Context，應另外觀察 Cache Hit Rate。模型遷移與 Cache Architecture 改造不應被當成同一個實驗。

哪些使用者最值得測試這次更新？

有大量 Codex 使用、API Coding Agents 或其他 Persistent Workflows 的團隊最值得評估 Sol 與 Luna。當 Agent 每個任務會產生很多次請求時，較低單價與更高 Context Reuse 可能產生累積效應。

偶爾使用 ChatGPT 的個人使用者，則不應直接把 API 經濟性理解成自己的成本一定會下降。產品可用性也不同：OpenAI 表示 Sol 與 Luna 已向符合資格方案的 ChatGPT Work 與 Codex 提供，但目前尚未在 Chat 中提供。

TowCue 判斷：模型正在變成 Agent Stack 的其中一層

GPT-6 Sol 與 Luna 的發布再次強化一個更大的 AI Workflow 趨勢。

Production Agent 越來越像：

任務政策 → 模型路由 → 可重用 Context → 工具 → 執行 → 驗證 → 人工審核

模型品質仍然重要，但 Routing、Cache Design、工具穩定性，以及證明結果足以接受的成本同樣重要。

當模型價格下降，團隊很容易產生「到處都跑 Agent」的衝動。更好的問題是：每增加一次 Autonomous Run，產出的成果是否值得它完整的驗證成本？

最後勝出的 Workflow 不一定每一步都使用最強模型，而是為任務配置足夠的 Intelligence、在適合的位置重用 Context，並把人工注意力花在錯誤代價最高的地方。

GPT-6 Sol 與 Luna 上線：為什麼 Agent 經濟性正變得和模型能力一樣重要