OpenAI 的 Decisions API：GPT-6 Luna 停止聊天並選擇一個答案

GPT-6 Luna於 2026 年 9 月 22 日推出，是 OpenAI GPT-6 產品階梯中最便宜的一層。9 月 29 日的新消息，是為它安排了一項與對話毫無關係的工作。OpenAI 的 Decisions API 會接收你撰寫的問題、你允許的有限答案清單，以及一段脈絡——文字或圖片——然後回傳其中一個答案。不是散文。不是一段得解析後還得碰運氣的段落。而是一個單一選擇，因此支援工單會分流到五個佇列之一，圖片會歸入某個審核類別，或是由代理程式從你定義的政策中挑選下一步行動。它在 DevDay 2026 上發表，目前處於有限預覽階段；OpenAI 表示計畫在未來幾天內全面發布。

一個團隊在以此為基礎進行開發之前，所需的大部分資訊都尚未公布。沒有每次呼叫的價格，沒有說明一個請求可以包含多少個候選答案，沒有關於你是否可以用自己的資料對其進行調校的聲明，而且——截至9月30日——在OpenAI自己的開發者文件索引、更新日誌或API參考中，都找不到任何相關條目。我們查了這三個地方。這項能力目前存在於OpenAI的DevDay回顧中，以及OpenAI發言人在發布日告訴記者的內容中。因此，本文的其餘部分會將三個層級明顯區分開來：OpenAI已確認的事項、一項發布日測量所聲稱的內容，以及目前無人能知的事。

受約束的決策實際上究竟是什麼

現有兩種做法都做不好這件事，而 Decisions API 正是針對兩者之間的缺口而來。第一種是對聊天模型下提示：你寫一段仔細的指令，要求它從清單中挑選，它回你一句話，運氣好的話，你還可以從回應中讀出詞元機率，得到某個類似信心分數的東西。這方法行得通，但會耗掉大量詞元，而且那個信心數字只是粗略猜測。第二種是訓練一個小型分類器：快速、便宜，但需要標註資料，而且每當標籤集有所變動，就得再跑一次重新訓練。

決策模型介於兩者之間。它接受提示中的新標籤——就像提示本身一樣——但會回傳分數或選項，讓開發者無須解析就能據以分支，這正是分類器曾具備、而聊天模型從未有過的特性。OpenAI 對這種形式並不陌生：其 Moderation API 多年來一直回傳各類別分數而非文字，但有一點在此至關重要。Moderation 的類別是 OpenAI 的。Decisions API 的類別則是你自己的。

限制條件本身就是產品，而它帶來什麼、不帶來什麼，值得精確說明。有限的輸出空間意味著每個允許的值都事先已知，因此你的應用程式可以拒絕它未定義的答案、為每個分支附加不同的權限層級，並在信心或上下文不足時退回由人工處理。這也讓離線評估變得可行，因為每個測試案例都有目標類別，且出錯時有可衡量的成本。它換不到的，是正確性。受約束的模型仍可能選到錯誤但有效的答案、被誤導性的上下文牽著走，或繼承你所撰寫類別的偏見。

150 毫秒的說法，以及 OpenAI 未公布的數字

OpenAI 表示，Decisions API 做出決策的速度大約比 GPT-6 Luna 透過一般 API 快十倍——大約 150 毫秒對上約 1.6 秒。這個數字是供應商自行宣稱且未經重現；自推出以來的兩天內，沒有任何獨立測量，而 OpenAI 自己的回顧只說「即時決策制定」。這個數字並未附帶延遲分布、地區、輸入大小、並行層級或服務等級協議。

我們自家的流量資料無法替代那項測試，但它解釋了為何缺失的分布至關重要。在截至 9 月 30 日的七天內，經由 OrcaRouter 一般 chat-completions 路由提供服務的 GPT-6 Luna，在 32.3 億個混合工作負載 token 上，中位數為 699 毫秒，p95 為 7.6 秒——中段與尾端之間的差距超過一個數量級。那是與受限決策不同的請求形態，因此不能與 150 毫秒的宣稱相比。這就是為什麼單一頭條 p50 是設計截止期限時錯誤的數字。如果你測試預覽版，請分別記錄文字與圖像輸入的中位數、p95 和 p99，計入網路時間與重試次數，並測量你的產品實際擁有的截止期限——非同步佇列的路由決策，與位於點擊和付款之間的路由決策，並不共享相同的延遲預算。

定價：模型的成本是什麼，以及為什麼那不是 API 的價格

OpenAI 尚未公布 Decisions API 的費率。直接假定 Luna 權杖（token）費率適用也並不安全，因為 Decisions API 是它自己獨立的套裝方案——不同的端點、不同的限制，而 OpenAI 已表示會在「全面推出時」分享更多細節。現在任何人向你報出的每項決策成本，都只是推測而已。

所公布的是它所依據之模型的價目表，讀取自 OpenAI 的定價頁面，日期為 2026 年 9 月 30 日：

• 輸入 — 每百萬個 token 為 $0.10，當輸入超過 272,000 個 token 時則為 $0.20
• 輸出 — 每百萬個 token 為 $0.50，當輸入超過 272,000 個 token 時則為 $0.75
• 快取輸入 — 每百萬個 token 為 $0.01；快取寫入以 $0.125 計費，較未快取費率高出 25%
• 批次與 Flex 處理 — 標準費率的 50%；Fast 模式 — 適用費率的 2 倍

長脈絡那條界線正是最容易讓人栽跟頭的一條，而它在整個 GPT-6 系列中的運作方式都如出一轍：一旦輸入超過 272,000 個 token，整筆請求都會改以較高費率重新計價，而不是只有超出的部分。至於把長文件或大批影像交給模型的決策 API，正是那種可能跨越這條界線的呼叫，而這也是預覽版尚未公布的限制所留下的又一個懸而未決之處。

以 GPT-6 自身的標準來看

把 API 拿掉後，底下的模型是一個推理模型，位於三階產品家族的最底層——低於 $2.00/$10.00 的 GPT-6 Sol，以及 $10.00/$50.00 的旗艦 GPT-6 Astra——配備 1,050,000 個 token 的上下文視窗、128,000 個 token 的輸出上限、2026 年 5 月 18 日的知識截止日，且推理強度可設定為六個值，從none 到 max。它接受文字與圖像輸入並回傳文字，而在 OpenAI 自家的開發者文件中，推理強度預設為 medium。同一頁還有一個實務上的注意事項，雖然與 Decisions API 無關，但如果你要把 Luna 接成備援就很重要：在 Chat Completions 上，函式呼叫只有在推理強度設為 none。若工具使用任何其他推理強度設定，則需要 Responses API。

在品質方面，獨立數據是 Artificial Analysis 的 Intelligence Index：Luna 在最高推理強度下為 37.3，而 GPT-6 Sol 為 47.5——差距約十個百分點，這才是解讀輸入端二十倍價差的誠實方式。這兩個數字都不是對 Decisions API 的評價；其受約束的任務屬於另一種量測，且並未公布分數。

Jev、Laya，以及「系統一」的框架

決策 API 並非憑空出現。TypeSafe AI 的 Jev於 2026 年 9 月 15 日由 Diogo Almeida 推出，自 9 月 21 日起正式全面可用，正是讓這個類別為開發者所理解的模型：它完全不生成任何文字，而是回傳帶有信賴值的型別化答案，每百萬輸入權杖收費 $0.042，輸出則不計費。由 Every 執行的 Jev 首次獨立測試，在不到 0.7 秒內對 37 份文件做出 777 項判斷，成本約為四分之一美分；第二項測試則測得每段落中位數 0.35 秒，相較於 Claude Fable 5.1 在高強度模式下需 8.83 秒——速度約快 25 倍，成本僅約 1/580，同時在七個刻意植入的缺陷中抓出六個，而 Fable 5 則全數抓出七個。「不錯但並不完美」是 Every 的評語，也是正確的一句話總結。Laya 是同型態的第三個參與者，一個無須寫出任何權杖就能作答的決策模型。

OpenAI 是否因為 Jev 而打造 Decisions API，純屬臆測。The New Stack 在發布當天報導此事時，稱這很可能是對 TypeSafe 的反應，並指出 OpenAI 很可能趕在 DevDay 前倉促宣布；OpenAI 從未發表過這類說法，而時間點——Jev 於 9 月 21 日正式推出，DevDay 在 9 月 29 日——雖有暗示性，卻不是證據。可以確定而非臆測的是，就買家在乎的那個面向而言，這兩者目前還無法相提並論。Jev 公布了價格、每次呼叫的計費形式，以及 GA 日期。Decisions API 這三項一概未公布。

它運行的位置，以及要在它旁邊保持溫暖的東西

Decisions API 是 OpenAI 自家的封裝產品。它不在我們的型錄上，我們也不為它做路由，所以如果你想要這個特定的端點，它就只在 OpenAI 那裡。它所建構於其上的模型則是另一回事：GPT-6 Luna 是 OrcaRouter 上一條實際運行的路由，以 OpenAI 的牌價、零加成直接轉嫁——每百萬個 token 輸入 $0.10、輸出 $0.50，而超過 272K 的級距則以 $0.20/$0.75 計價——在截至 9 月 30 日的七天內，它已透過我們處理了 32.3 億個 token，錯誤率為 0.18%。

這對如何降低預覽版的風險至關重要。測試受限決策端點時，穩妥的做法是讓以提示詞為基礎的路徑保持可用，作為備援，因為預覽版可能未經通知就變更限制或定價，而位居關鍵路徑上的決策需要有地方可退。把該備援放在與其他模型相同的金鑰上，就意味著不必再簽第二份合約，備援路徑也不用改程式碼：一個 API 串接 200 多個模型，並在供應商其中之一不穩時自動容錯移轉。而如果你的決策只是更長鏈條中的一步，路由 DSL 能把多個模型組合成單一次呼叫，這正是 Jev 的相關報導所推廣的「協調者加決策者」模式——由較大的模型負責規劃，較小的模型負責選擇每一步。這個模式今天就能用我們所服務的模型建構出來；在 OpenAI 開放之前，Decisions API 本身仍會落在这个模式之外。

誰應該移動，誰應該等待

如果你的問題是高頻的分類或路由工作，其中走錯分支的代價低廉且可逆，那麼這個預覽版值得你這週投入一種請求格式與一份標註資料集——這項能力是真的，這項限制確實比解析散文更進步，而預覽版正是了解其錯誤成本會落在何處的最便宜時機。如果你的決策會授權金錢、向客戶發送訊息，或位於使用者與付款之間，那麼這週的任何事都不會改變你的盤算：沒有已公布的價格可供建模，沒有已公布的上限可供據以設計，沒有 SLA，也沒有任何說法說明你是否能用自己的資料調校這東西。這四個空白正是「全面推出」必須補上的，而在 OpenAI 指名它們之前，對 Decisions API 最誠實的解讀是：一個前景看好的介面，廠商聲稱的時程很快，卻沒有附上帳單。