OpenAI Decisions API 公開測試：0.10 美元輸入費率，機率能直接放行嗎？（2026）

2026 年 10 月 6 日，OpenAI 在官方更新紀錄〈Changelog〉公布 OpenAI Decisions API beta，由 GPT-6 Luna 把文字與圖片轉成有型別的答案。這次值得看的變化，是開發者已有可核對的決策介面與計費條件；接下來的問題則是：拿到一個機率，程式就值得照它行動嗎？

先把公告與正式規格讀清楚，再拆開速度、價格和機率的不同含義，最後判斷哪些流程值得接入。這篇分析 10 月 6 日公開測試的新交付；若想先練有限選項，先前的假工單教學提供的是本機規則練習，不能把那份程式當成正式 API 客戶端。

OpenAI Decisions API beta：從寫答案，到交出判斷

截至 2026 年 10 月 8 日查核，官方指南標示 public beta、目前支援 gpt-6-luna，使用專用 POST /v1/decisions 端點。未來數週 GA 是官方預期，尚不能寫成已正式上市。

Released the Decisions API in beta with gpt-6-luna.

中文：Decisions API 已搭配 gpt-6-luna 以 beta 形式釋出。

OpenAI，2026 年 10 月 6 日 Changelog

一般工作流可能先請模型寫一句「這是帳務問題」，再把文字轉成程式分支。這裡先由開發者把問題與答案空間定義好，再接回指定型別。它把介面設計的重心移到前端：你得先知道自己要問什麼、哪些答案有意義。這是我的架構判讀，並不是由介面推定模型內部用了哪種新訓練方法。

依正式 API reference，請求以 model、input、questions 組成，回應包含 answers。predicate 回傳命題為真的估計機率；choice 選擇提供的值；score 則對有次序的等級評分。分類、排序、判斷條件各自有位置，不能把這三件事混成同一個數字。

最容易誤讀的回傳：score、confidence 與 refusal

想像收貨流程：第一題問「是否可見凹損」，第二題問「交給哪一隊」，第三題問「問題多嚴重」。三題可以使用同一份材料，卻回答三個不同問題。凹損機率高，不會自動決定退款金額；嚴重度也不會替你選出處理部門。

文件的 score 示例把等級索引設為 0、1、2，再以機率加權：0.1 × 0 ＋ 0.7 × 1 ＋ 0.2 × 2 ＝ 1.1。這是等級上的摘要，不是「1.1% 出錯」，也不是選出一個叫 1.1 的類別。開發者先定義各等級的判準，才能解讀這個索引平均值；它沒有把不同等級的業務代價換算進去。若「小問題」與「重大事故」的代價差很多，單看平均值可能掩蓋尾端風險。

同一份規格將 choice／score 的機率分布與 confidence 分開列出。把它們當成不同欄位處理，再依應用資料驗門檻；不要自行假定 confidence 就是最高選項的機率，或直接翻譯成「這次一定有幾成機會答對」。

還有一個真正影響串接的分支：reference 明列 refusal，代表模型拒答這一題，同一請求的其他題仍可能收到答案。因此，「HTTP 回應成功」與「每一題都有可採用判斷」應分開驗。若程式把拒答當成否定、零分或默認通過，它改變的是業務決策，已超出欄位解析。

0.10 美元輸入費率，省下的是哪一張帳？

You pay only for input tokens

中文：只針對輸入 tokens 付費。

OpenAI，Decisions 指南 Pricing and availability

官方指南列出的基礎費率是每百萬輸入 tokens 0.10 美元；專用 Decisions 端點沒有快取讀取、快取寫入或輸出 token 費用。但同段明列地區處理加價與長上下文輸入倍率仍適用，不能把基礎牌價當作所有配置的完整報價。其他端點的 GPT-6 Luna 用法有各自的模型與處理費率，不是一律只收輸入。

用純文字的小例子估規模：假設每次合計 1,000 個計費輸入 tokens，1,000 次就是一百萬 tokens，按基礎費率為 0.10 美元；一百萬次則是 100 美元。這個算式刻意不含地區、長上下文倍率、重試與下游處理，目的是看懂 token 與呼叫次數的差別，不是替你的工單系統報價。

如果一張單還要多次補問、人工回看或呼叫下一個模型，那些工序仍要記帳。輸出費用省下來，讓高頻窄判斷更值得試；真正的採用問題，是整個流程在相同品質下省了多少工作。尤其把很多上下文重送給小問題時，便宜的單價仍會乘上大用量。

「約快 10 倍」是發布主張，還不是你的延遲成績

OpenAI 更新紀錄與指南宣稱，相較 Responses API，型別化答案約快 10 倍。這裡保留為供應商主張。本文沒有呼叫 API 重跑測速，也未取得可獨立確認這個倍率適用範圍的完整公開測試，因此不把它換成一般任務的等待保證。

這個方向有合理的工程誘因：當工作只要一個固定選項，生成長解釋可能不是必要交付。但我們不能從輸出很短，就推定所有加速都來自某一個計算機制。公平的比較應讓兩個接口處理相同題目、同樣長的輸入、同樣的正確條件；再量完整回應時間及高分位延遲，別拿一邊的第一個字與另一邊的完整答案相比。

討論熱度也回答不了可靠性。Hacker News 的原始討論有人追問 90% 能否對應到十次約九次正確；那是待驗的問題，並不是校準完成或失敗的證據。Jev 的發布解析曾討論過同一條界線：有型別的輸出契約，與有品質的決策契約各要一份證據。

AlphaLab 的判讀：這次交付要通過四個關口

一、題目縮窄，才有可管理的輸出

我同意這個介面方向：程式常需要的是一次判斷，而非一段對話。若你能把問題限定在已知資料、清楚選項與可觀察條件，型別化答案容易接入紀錄、回退和比較。若問題本身含糊，固定選項只會把含糊包進合法的值；設計者得先把「其他」「資料不足」放在自己的業務流程裡。

二、機率的用途，取決於錯誤代價

分流到錯的內部隊列，可能只是多一次轉派；放行錯誤退款，卻會產生另一種損失。同樣的機率不應自動共用同一個門檻。我的建議是先畫出每種誤判會發生什麼，再用未參與調整的標註樣本，量不同門檻下的錯放、漏放與需複核比例。

校準要回答的是：一批得到相近機率的案例，實際發生比例是否也相近。它描述群體統計，不能替單張照片或工單保證結果。資料換了語言、客群或拍攝條件後，原先的門檻需要重新驗；這個驗收責任不會因 API 回傳了小數而消失。

三、決策元件與動作權限要有兩份紀錄

把「有凹損」交給商品複核隊列，和立刻執行退款，是兩個操作。前者可用分類結果排序，後者還牽涉授權、金額及對帳。我的判斷是：先讓 Decisions 提出候選與優先序，讓你的應用層留下採用依據和執行結果；任何需要擴權的動作，都有明確的核准條件。

Beta 串接也應把超時、拒答、格式檢查與業務判斷分開記。如果結果缺了一題，流程要能停在那一題；如果只能用默認值掩蓋失敗，就很難知道省下的時間是否換來更多錯誤。Agent Harness 的分工概念可以幫你把模型、工具與真正執行工作的層次畫清楚。

四、我存疑的是，從低價與快直接跳到全面放行

公開 beta 與可查規格，足以讓開發者把它放進候選清單。價格與速度值得量；但它們沒有替你的繁中內容審核、圖像判斷或 Agent 路由完成校準。下一個有用訊號，是不同團隊在固定題集上公開完整錯題、機率分布與端到端成本，讓外部讀者能看清楚什麼條件下值得採用。

下一步：先觀察它怎麼判，再決定讓它做什麼

現在可以挑一個可逆的小流程，例如替待複核圖片排優先序。先保存人工標準答案，讓 OpenAI Decisions API 在旁路產生判斷，原流程繼續運作；把題目版本、輸入、原始答案、拒答與完整時間留下來，再和既有方法對照。這是建議的驗收設計，不是本文已完成的跑次。

先看各類錯題，再看不同門檻如何改變工作量。圖片接入也有明確規格：目前 reference 要求 inline data URL，外部圖片網址與 file_id 不支援這個端點；不要把其他 OpenAI 接口的輸入方式直接套過來。需要自行設計 JSON 欄位或生成解釋時，Structured Outputs是另一條文件化路線，應按交付需求比較。