GPT-5.6 Luna Max：開發者如何在 Codex 中實際使用它——以及它在哪裡失效

8月1日，一份四行的配置文件开始在X上流传。它创建了一个名为luna_worker的Codex代理，将其模型设为gpt-5.6-luna，将其推理强度设为max，并把工作中无聊的那一半交给它，而GPT-5.6 Sol则继续掌握规划。几天之内，同样的配方就被人以英语、中文、日语、韩语、西班牙语和阿拉伯语重新发布；基于同一想法的一个插件更是在四天内就突破了1,300个GitHub星标。然而，差不多就在它走红的那一天，这种接法其实是个错误：该插件的作者在48小时内公开地把GPT-5.6 Luna从他自己的项目中撤了下来，因为一位同行告诉他，它作为Codex子代理并不奏效——两天后他又把它放了回去，但接法完全不同。

那整個事件發生在一週之內，而這是任何人針對這個模型所發表過最有用的內容。它告訴你廉價工人模式是真實存在的，最顯而易見的接線方式是錯誤的，而這兩者之間的差異正是價值的大部分所在。這篇文章中所有涉及技術的內容，都來自從業者在2026年7月30日至8月5日之間發布的自身結果——而非來自公司的文件；該文件將GPT-5.6 Luna描述為一個適用於「對成本敏感、高工作量」的模型，並且對這一切隻字未提。凡是數字由獨立第三方測量，我們會明確說明；凡是來自單一開發者的會話日誌，我們也會如實標註，包括當它們彼此矛盾之時。它們確實經常互相矛盾。

「Luna Max」是什麼，以及為什麼大多數人從未見過它

沒有名為 Luna Max 的模型。有兩個轉盤，Luna Max 是它們的一種組合：GPT-5.6 系列中最便宜的等級，以最深的推理設定運行。等級轉盤在 GPT-5.6 Sol、GPT-5.6 Terra 和 GPT-5.6 Luna 之間選擇。努力程度轉盤有六個檔位——無、低、中、高、極高和最高——它控制模型在回答之前進行多少思考。

幾乎沒有人會把低價方案與深度設定搭配使用，原因很平凡：max 預設是隱藏的。在 ChatGPT/Codex 桌面版應用程式中，它位於「設定 → 組態 → 可用的推理努力」之下，而這份清單預設最上方的選項是未勾選的。八月的第一週，有六位不同的開發者貼出了同一個只需三次點擊的修復方法，這足以顯示有多少人一直以 Luna 的預設深度執行它，並據此評斷這個模型。在 API 端則沒有任何切換開關需要尋找：你傳入模型 id gpt-5.6-luna，並將推理努力設為 max （在請求主體中），這就是全部的改動。

在閱讀任何基準測試之前，有一個後果值得銘記：當 Artificial Analysis 為這個模型發布智力分數時，頁面標題是GPT-5.6 Luna (max)。大家引用 Luna 的獨立數字是最大努力（max-effort）配置。如果你一直使用預設設定，並想知道為什麼你的體驗與排行榜不符，原因就在這裡。

沒人解釋的那個旋鈕：努力程度改變的是 token 數量，而非 token 價格

提高推理努力並不會讓您進入更昂貴的價格等級。GPT-5.6 Luna 在每個努力設定下，每百萬個輸入 token 花費 $0.20，每百萬個輸出 token 花費 $1.20。改變的是模型在得出答案前花費多少 token——而在最高設定下，它會花費非常多。

Artificial Analysis在執行其智慧指數的過程中測量了這一點，這些數字是對從業者所抱怨問題的最清晰獨立確認：

• 分數 — 在 Artificial Analysis Intelligence Index 上為 51，相對於該類別中受測模型的中位數 17。

• 冗長度 — 在指數運行期間生成了 130M 個輸出 token，而中位數為 61M。Artificial Analysis 將該模型標記為「非常冗長」。

• 原始速度 — 每秒輸出 182.5 個 tokens，在 163 個模型中排第 16 名。每個 token 的速度很快。

• 首次 token 生成時間 — 在最大努力模式下約需 136 秒，Artificial Analysis 指出，即使在該價位區間的推理模型中，這也算偏高。

• 總花費 — 在整個索引上評估模型花費了 $174.06。

請將第三行和第四行一起閱讀，因為這兩行合起來就是完整的用戶體驗。Luna 在最高設定下能快速串流輸出 token，但啟動需要數分鐘，接著在相同工作上產出的 token 數量大約是典型模型的兩倍。這就是為什麼實地報告中最常見的抱怨不是「它錯了」，而是「它很慢」——也是為什麼便宜的價格並不會轉化為相對便宜的會話。你是在以低單價購買大量的 token。

作為對比：在我們自己的 GPT-5.6 Luna 模型頁面上，七天真實流量中觀測到的首次 token 時間中位數為 1.78 秒，第 95 百分位數為 9.26 秒。這與 136 秒的數字並不矛盾——這是同一個模型在混合的 effort 設定下量測的結果，其中大多數並非最大值。你得到的延遲取決於你設定的檔位，而不是你呼叫的端點。

Luna Max 真的只是「六分之一價格的 Sol Medium」嗎？

這就是讓這個模式爆紅的說法，源自於 Dan McAteer。他將 Luna 在最高推理設定下的表現定位在大約 GPT-5.6 的水準，Sol 在中階設定下大約是 Claude Opus 5 的中階水準，而成本僅約六分之一。這個說法被大量帳號轉述，有時甚至把原本的保留措辭都給刪掉了。而我們值得去區分，哪些是實際量測的結果，哪些只是憑感覺。

獨立評分表強烈支持成本方面的主張，但對效能方面的支持僅有部分。以最大運算量跨層級執行同一基準測試套件時，Artificial Analysis 記錄到 Luna 以 174 美元取得指數 51、Terra 以 1,403 美元取得 55、Kimi K3 以 2,437 美元取得 57、Sol 以 2,824 美元取得 59。Luna 比 Sol 少了八個指數點，但完成同樣工作量所需成本約僅為其十六分之一。

獨立評分板在8月13日變得更加嚴格，當時DeepSWE發布了v1.1——這是對其長期工程基準測試的一次修訂，保留了來自91個儲存庫、涵蓋五種語言的113個原始任務，但現在透過在隔離容器中執行已提交的diff來評分每個修復，這使得作弊更加困難。在更新後的評分板上，所有三個GPT-5.6等級在最大努力下都落在7月報導所述的位置：Luna Max在pass@1上為67.2%，每個任務成本0.61美元；Terra Max約70%；Sol Max為73%，每個任務8.39美元——成功率高出六個百分點，但成本大約是十四倍。

值得再看一眼的比較位於 Luna 之下，而非其之上。Claude Sonnet 5 Max 在相同的 113 個任務上得分 54% — 比 Luna Max 落後約十三個百分點 — 每個任務成本為 $26.40，約為 Luna 為相同解法所支付費用的 44 倍。Luna Max 也超越 Gemini 3.7 Flash（在同一排行榜上高努力配置為 65%）；指出這一輪比較的社群貼文將與 Gemini 3.7 Flash Medium 的差距定為約 1.7 個百分點。DeepSWE 是 Datacurve 的獨立測試框架，而非公司評測 — 該公司自身宣稱 GPT-5.6 系列在 Terminal-Bench 2.1 和 DeepSWE 上創下最先進成果，這仍是另一項由廠商報告的說法。

接著是實地證據，而這些證據確實是分歧的。Pawel Huryn 執行了他自己的除錯基準測試——在兩個真實程式碼庫中埋入105個錯誤，採用盲測評判，每個模型一輪——並回報 Luna 在最大努力下以1.80美元修復了33個錯誤，而 Claude Fable 5 以68美元修復了24個。另一方面，Diego Haz 花了兩天進行配對會話，結果與此模式相反：Luna 每次會話平均花費1.20美元，而 Sol 平均花費29美元，但他必須重做 Luna 的大部分輸出，而且在他的使用案例中沒有得到任何可交付的成果，這使得節省看起來是幻覺而非折扣。另一位使用相同測試框架的開發者回報，Sol 在中等設定下產出的結果明顯優於 Luna 在最大設定下的結果，而且花費的時間約為一半。一場以中文進行的單一3D場景任務評比，為這種情況提供了具體數據：Sol Medium 在21分30秒內完成，獲得最高品質評分且消耗最少 token；Luna Max 花費40分55秒，燒掉約13萬個 token，品質評分最低，並用掉每週訂閱配額的一半。

一週過後，社群立場的誠實總結：Luna Max 不是 Sol Medium。它比 Sol Medium 便宜得多，但也更差，而這個取捨是否划算，完全取決於任務是否被定義得夠嚴謹，讓「比較差」無關緊要。這正是下方接線模式的用途。

歷經實戰仍存續的模式：Sol 規劃，Luna 執行，再由新的 Sol 審查

持續使用 Luna Max 的人，沒有人是把它當作通用型程式設計代理來用的。實務工作者在各個版本中趨向一致的有效配置，包含四個角色：

• 協調器——GPT-5.6 Sol 以高強度運作，駐留於主執行緒。它負責需求、架構、任務拆解與最終驗收，但不撰寫程式碼。

• 例行任務執行者 —— GPT-5.6 Luna 以最大努力，處理界限明確且規格完整的工作：機械式重構、測試撰寫、模組分析、文件更新，這類目標明確無歧義的任務。

• 硬性執行者 — GPT-5.6 Terra 以最大努力運行，適用於因 Luna 的指令漂移而成本高昂的上下文密集型建置。

• 審查者 — 一個全新且唯讀的 GPT-5.6 Sol 實例，它只看到最終的 diff，其他什麼都看不到。「全新」的重點在於，帶著實作脈絡的審查者往往會認可自己的推理。

參考實作是 sol-advisor，這是 Dan McAteer 所開發的 MIT 授權 Codex 外掛，推出第一週就獲得約 1,400 顆星。安裝方式是透過 Codex 外掛市集，加入 DannyMac180/sol-advisor 儲存庫，然後加入 sol-advisor 外掛。其目前的樣貌頗具啟發性：原生通道固定指定 Terra/High 實作者，接著由全新的 Sol/High 審查者審查；而 Luna 開到最大時則是一條明確的選擇性通道，以獨立且使用者可見的任務執行，由主要的 Sol 工作階段直接審查並接受其成果，而不是交由原生審查者處理。

如果你不想安裝任何東西，廣為流傳的精簡版本是位於 ~/.codex/agents/luna-worker.toml 的自訂 agent 定義，帶有兩項設定 — model = "gpt-5.6-luna" 和 model_reasoning_effort = "max" — 外加一段描述和指示，將其限制在具有明確界線的委派工作上，禁止它更改整體目標或擴大自身範圍，並將架構決策與模糊的需求回報給主 agent。流傳的建議是讓 Sol 為你撰寫這個檔案、根據你安裝的 Codex 版本進行驗證，並在你接受前先顯示 diff；無論你是否信任這個配方，這都是穩妥的做法。

子代理陷阱，以及社群凝聚出的修正方案

這就是此模式的病毒式版本與可行版本分道揚鑣之處。

Codex 的原生子代理系統並未將 GPT-5.6 Luna 視為一等公民。McAteer 撞上了一道硬牆——Luna 不被允許作為子代理——於是他改將其宣告為自訂代理來繞過這個限制，並公開指出了這個變通方案的代價：自訂代理不像原生子代理那樣能與主代理共享上下文。數天後他將 Luna 通道從sol-advisor中完全移除，並引述另一位專注於 Codex 的開發者的發現：Luna 在子代理角色中表現不佳，據推測是因為它尚未針對 v2 多代理協定進行過後訓練。Diego Haz 則從另一側獨立描述了同一道牆：Sol 無法將 Luna 生成為子代理，因此 Luna 只能存在於頂層執行緒中，這讓協調變得一團亂。

目前的共識，亦即現在的主流立場，就是停止對抗它：

• 給 Luna Max 一個專屬執行緒，而不是子代理圖中的一個插槽。指示 Sol 編排器在 Luna 上啟動一個獨立的頂層 Codex 任務，監控它並取回結果。這就是 McAteer 對 sol-advisor 於 8 月 4 日重新添加的內容，也是其他幾個人各自獨立得出的結論。

• 接受上下文隔離作為代價。 獨立的執行緒意味著獨立的歷史。這就是你付出的代價，也是為什麼下面的交接在此處會比在原生子代理設定中更為重要。

• 如果你必須將其強制納入 multi-agent v2，目錄就是它被過濾掉的原因。 有位開發者將排除原因追溯到內建模型目錄將 Luna 標記為 v1，並回報了一個變通方法：複製 ~/.codex/models_cache.json，將 Luna 的 multi_agent_version 設為 v2，將 model_catalog_json 指向你的副本，重新啟動 Codex，然後讓編排器以最高配置啟動 Luna，搭配快速服務層級，並關閉分叉。請將此視為某個人對內部文件的非官方破解——正是那種 Codex 更新就會破壞的東西。

交接資料包：解決最常見抱怨的五個問題

Luna Max 最常被回報的失敗，是它不會嚴格遵循指示，尤其是當你提供一個具體的工作流程或迭代迴圈讓它執行時。這類抱怨同時出現在喜歡該模型的開發者，以及已放棄它的開發者身上。從業者最終不斷得出的緩解方式，並非寫作風格意義上更好的提示詞，而是一份更嚴格的契約。在 Luna 討論串開始之前，請回答五件事：

• 這個代理應該完成什麼確切任務？ 不是工作領域——而是最終狀態。

• 哪些檔案、文件或系統在範圍內？ 明示列舉，而非默示。

• 它不能改變什麼？ 那些禁止更改的介面、遷移、配置和公共合約。

• 什麼證據能證明完成？ 一個具名的測試、特定命令的輸出、以及僅改動所列檔案的 diff。

• 缺少哪個決策才能讓它停止？ 觸發返回而非猜測的機制——這正是防止過度急切的廉價模型自行發明架構的關鍵。

這裡也正是值得把該公司自身的提示詞（prompting）指導一併納入的地方，而且該為它貼上應得的標籤：該公司報告，在內部的 coding-agent 評估中，更精簡的系統提示詞使評估分數提高了10–15%，同時總 token 數減少了41–66%、成本降低了33–67%；該公司並建議審計從 GPT-5.5 或 GPT-5.4 繼承下來的提示詞，而不是把它們直接移植過來。這些是供應商自行報告的數字。但這個方向與該領域的發現一致：精確地描述目的地，刪除對每一步的敘述。請注意這與上一段之間的張力——對範圍與約束的精確要求並不等同於冗長，而社群的共識是：Luna Max 需要更多前者、更少後者。

需要規劃防範的故障模式

• 指令漂移。多位開發者證實：它會忽略初始指令的某些部分，而且當指令是要遵循的程序，而非要達成的結果時，情況最糟。

• 實際時間（Wall-clock）緩慢。 屢次被回報，且與 Artificial Analysis 在最大努力模式下測得的約 136 秒首個 token 延遲時間一致。適合可以放任其執行的任務；但在互動式迴圈中則令人痛苦。

• 上下文消耗。 一位開發者回報，Luna Max 消耗 258k Codex 執行緒視窗的速度驚人地快，並懷疑一旦 Codex 在接近上限時開始壓縮，配額消耗就會飆升。壓縮的部分是他的印象，而非實測結果——但這種消耗速率正是 Artificial Analysis 獨立測量到的冗長程度所導致的預期後果。在 API 端，請注意長上下文階段：此模型的轉嫁價格表在請求超過約 272k tokens 時，會從 $0.20/$1.20 調整為 $0.40/$1.80，因此持續增長的執行緒每個 token 會變得更貴，而不只是總價變得更貴。

• 任何視覺相關的事物。這是實地報告中最鮮明的界線。一位廣受閱讀的從業者為了 Luna Max 取消了 Kimi K3 編碼訂閱，評價它與他原本使用的產品一樣好，而且便宜得多——但明確為前端工作保留了例外。另一位則更直言不諱：不要用 Luna 來執行設計、圖形、排版或簡報工作；「用 Sol 規劃、用 Luna 執行」的分工模式適用於逐步教學任務，而非美學相關任務。

• 子代理目錄。上文已說明 — 如果在多代理執行中 Luna 悄然從未被選中，那是遭到過濾，而非失敗。

• 虛假的節約。唯一一種不會出現在任何基準測試中的失敗模式：一次花費 1.20 美元而非 29 美元的會話，產出的成果卻需要你親手重寫——這最終讓你付出 1.20 美元，外加一整個下午。

何時不該追求極致

Max 並非免費升級，而經得起考驗的指引是一把梯子，而非一種設定：

• 明確的轉換 — 重新命名欄位、機械式擷取、格式整理。在 Luna 上屬低或中等工作量。以指定的測試通過作為門檻。

• 常規實作：高或極高。Luna worker 的社群預設值為極高（xhigh），而非最高（max），正是因為 max 會在從未困難的任務上耗費時間與代幣。

• 有界但真正困難——這就是 max 實際的工作。數據包既要困難，又要有嚴格明確的規範，才能使額外的推理轉化為更好的結果。

• 模糊調查——改變等級，而非調整旋鈕。如果模型是在誤判而非規劃不足，在較便宜的模型上增加思考量也無法解決；那是 Sol 的任務。

• 模糊的任務說明——要修正的是合約，不是模型。任何努力設定都無法彌補未言明的驗收標準。

關於訂閱的一項特別警示（出自第三方指南，且容易搞錯）：Codex 按模型收取的點數費率，其比例關係與 API 列表定價並不相同，因此你不能直接將 API 的價格比例拿來當作訂閱路由規則。Plus 方案所回報的五小時訊息配額即說明了這點——在 Sol 上約為 15–90 則本機訊息，Terra 上為 20–110 則，Luna 上為 50–280 則；範圍之所以如此寬廣，是因為「一則訊息」並非固定的工作量單位。如果你的路由決策是由訂閱上限而非帳單所驅動，就應以該上限為衡量基準。

超越 Codex：人們還將它指向什麼？

廉價深度推理的組合在編碼代理之外也證明有用，以下是有憑有據的用途：

• 瀏覽器代理。 一位開發者在 GPT-5.6 Luna 上執行瀏覽器自動化堆疊，開啟 Hacker News 前 15 篇貼文、閱讀每個連結頁面並撰寫報告——總成本 3 美分。長時程、低風險、高 token：這正是此模型定價所針對的形態。

• 技能鏈。兩位實踐者獨立回報，從單一的 Luna Max 目標驅動一條雙技能管道——先產生影像，再送入影像轉 Three.js 的轉換器——最終得到一個可互動的低多邊形 3D 物件；兩人都提到這幾乎沒有推升他們的每週使用計數。這份回報值得與「別用 Luna 做視覺工作」的警告並讀：Luna 只是在編排執行視覺工作的工具，而非自己判斷美學。

• 讓單一工作階段保持熱度。此模型上的快取輸入成本為每百萬個 token 0.02 美元，而全新輸入則為 0.20 美元——這是 Artificial Analysis 在其定價面板上列出的 90% 折扣——而且快取視窗約為 30 分鐘。多份指南獨立得出的實際意涵是：一個長時間執行、持續重新讀取同一程式碼庫的工作階段，會比每項任務都開新工作階段便宜得多。

• 配額套利。 這是整套說法中最激進的一項，而且被明確標示為一項宣稱：一位開發者回報，因為把努力開到最大幾乎不花成本，而檔位倍數又很大，於是在低價檔位跑滿努力，讓他在 200 美元方案下，三週內跑完 49 億個 token——以 API 費率計算價值六位數——而且他把 Kimi K3、Grok 和 DeepSeek 模型放在同一個選擇器中，背後以本地路由器調度，這樣碰到一家供應商的額度上限也不會讓工作停擺。目前還沒有人獨立重現這個 token 數字。不過，背後那套路由習慣，才是值得仿效的部分。

在沒有 Codex 訂閱的情況下執行相同的拆分。

以上都是訂閱形態的故事：人們之所以在意 Luna Max，是因為它拉高了每週上限。在 API 這一側，同樣的架構更容易建置，也更容易理解，因為你是在支付帳單，而不是管理額度——而 orchestrator/worker 的分工也不再是外掛，而是變成一般的路由。

GPT-5.6 Luna 可透過 OrcaRouter 取得，價格為每百萬輸入 token 0.20 美元、每百萬輸出 token 1.20 美元——這是供應商的牌價，以 0% 加價轉傳，因此 7 月 30 日的降價在廠商宣布當天就在我們這端生效，而非等到下一個帳單週期。它可透過相容的 API 提供於/v1/chat/completions與/v1/responses，因此 reasoning-effort 欄位會與直接呼叫時一樣放在請求主體中，而模型 ID 是openai/gpt-5.6-luna。GPT-5.6 Sol 與 GPT-5.6 Terra 共用同一組金鑰，而這正是此模式的關鍵：一個 orchestrator 在某一層、一個 worker 在另一層，代表的是單一整合中的兩個模型 ID，而不是兩份廠商合約。路由 DSL 讓你可以用單一呼叫表達這種拆分，不必手動將執行緒黏合在一起；自動故障轉移則涵蓋了配額套利者用本機路由器解決的情境——當某個供應商效能劣化時，請求會落到其他地方，而不是就此中斷。

兩點誠實的提醒。Codex 特有的機制——子代理圖、外掛程式市集、模型目錄、每週配額——都屬於公司所有，而這些都不會隨 API 金鑰一併提供；如果你想要的模式是 sol-advisor（在 Codex 應用程式內部），你需要的是 Codex 訂閱方案。而上述的失敗模式是模型本身的屬性，與傳輸層無關：路由會影響一次呼叫的成本，以及供應商故障時會發生什麼事，但不會影響 Luna 是否遵循你的指示。

誰應該複製這個，誰不應該

如果你的工作屬於高量且可機械化指定的類型——大型程式碼庫的重構、測試脚手架、抽取、文件編寫、分析掃描——就把 max 開到最大，把 Luna 放到獨立執行緒中，用五個問題的交接來啟動，並在它前面保留一個 Sol 執行個體做規劃、後面保留一個做審查，預期花費會少一個數量級。回報成果最大的人都在做某種版本的這種做法，而獨立的成本數據也支持這個方向，即使它們未必支持「跟 Sol 一樣好」的說法。

如果你的工作屬於探索性、美學導向，或是以模糊的簡報起步、隨進展才逐漸清晰，現場報告清楚指出，你會把省下的成本加倍花在重做產出上。而如果你是互動式使用——坐在那裡盯著它——最高強度下兩分鐘的冷啟動，會比價格帶來的滿意度更讓你困擾。

值得關注的是：公司是否會針對 v2 子代理協議對 Luna 進行後期訓練。現行方案中每個彆扭的部分——單獨的執行緒、遺失的共享上下文、目錄的應急手段、整個收回並重新接線的過程——都源於那一個缺口。補上它，這種模式的最佳版本就會簡化好幾步。

值得認真回答的問題

最高的推理努力等級是否比預設等級每個 token 的成本更高？

不，這是對這個設定最常見的誤解。GPT-5.6 Luna 的計費是每百萬個 token 輸入 $0.20、輸出 $1.20，與 effort 無關。max 改變的是花費的 token 數量——模型會規劃更多、自我檢查，並在回答前進行修訂。Artificial Analysis 測量到該模型在一個基準測試套件上輸出了 1.3 億個 output tokens，而中位數模型輸出 6,100 萬個。因此，在相同任務上，max-effort 的會話成本高於 medium-effort，完全是因為 token 量更大，而且產生第一個 token 所需的時間也更長。Effort 其實是一個掛著品質標籤的 token 數量旋鈕。

GPT-5.6 Luna 現在能以原生的 Codex 子代理身分運行嗎？

截至2026年8月5日，答案是「否」——社群已經放棄嘗試。Codex 的原生子代理路徑不接受 Luna；自訂代理的繞行作法雖能讓它執行，卻會失去與主代理之間的共享上下文；而此模式最知名外掛的開發者移除了 Luna，再將其重新加入為由編排器監控的獨立產生的頂層任務。如果你看到多代理執行中 Luna 從未被選取，那很可能是因為它遭到過濾——標準模型目錄將它標記為 v1 而非 v2，有位開發者已自行手動修補，風險自負。這是這份清單上最可能因 Codex 更新而改變的一項，因此請務必根據你安裝的版本進行驗證，不要輕信任何作法，包括這個。

它是否足以取代 Claude 或 Kimi K3 的寫程式訂閱方案？

有幾位開發者正是因為這件事而公開取消了每月 200 美元的方案。讓這個問題浮上檯面的貼文，來自一位每天寫程式的免疫學家：他退掉了 Kimi K3 的程式碼訂閱，不是因為它不好，而是因為在他的經驗裡，GPT-5.6 Luna 對他的工作來說一樣好，而且便宜得多——前端除外。獨立的成本數據讓這個論點很難被忽視：在同一套基準測試上，Kimi K3 在最高強度下得分 57、花費 2,437 美元，而 GPT-5.6 Luna 在最高強度下得分 51、花費 174 美元。但在你取消任何東西之前，先讀讀異議。那些量測了配對 session 並得出負面結論的開發者，並不是在測試不同的模型；他們是在測試不同種類的任務——開放式、視覺化、或規格鬆散——而在那種任務上，便宜的模型輸得夠慘，足以抵銷省下來的錢。站得住腳的答案是，Luna Max 取代了你很大一部分的編碼工作，不一定是你最好的編碼模型，而那些最善用它的從業者，是那些身邊保留了一個前沿等級方案、用來規劃與檢查的人。