OpenAI 的 Decisions API 在哪裡結束、Jev 又從哪裡開始：首位外部客戶展現了什麼

在 2026-10-06 UTC 23:05，一個名為 llm-openai-decisions 的外掛在 PyPI 上發布，而它自己的 README 含有那句話——發布報導從未印出的那句：「有別於 Jev，新的 gpt-6-luna 決策模型除了文字之外還支援圖片輸入。」作者是 Simon Willison，他也寫了 TypeSafe 決策模型的第一個用戶端；他所作的比較是在 GPT-6 Luna——OpenAI Decisions API 背後的模型——與 Jev 1.13 之間，後者是 TypeSafe 純文字的 System One 模型。同一篇部落格文章指出，這個外掛本身是由 GPT-6 Astra 閱讀 OpenAI 的文件所寫成。

這就是用戶端在 API 推出一週後才發布的好處：它是依據請求結構撰寫的，而不是依據主題演講，因此能揭露行銷文案所掩蓋的差異。這裡沒有任何內容是外洩的，也沒有任何內容未經證實——以下每個數字都來自 OpenAI、TypeSafe 或該外掛本身儲存庫所發布的頁面，全部於 2026-10-07 讀取。仍然缺少的是對端點本身的獨立量測，而這個落差會在結尾處說明，而不是被粉飾掩蓋。

三個表面，彼此隔開

首先必須釐清的是，這是三個不同的層次，而新聞報導會模糊它們之間的界線。

• 這些端點。OpenAI 的是 POST /v1/decisions，這是一條專用路由，而不是 Responses API 上的一種模式。TypeSafe 的則是 POST /v1/systemone。兩者都接受一組證據，加上一份帶型別的問題清單，並為每個問題回傳一個答案，以你為其指定的名稱作為鍵值。

• 模型。Decisions API 目前只接受一個模型，gpt-6-luna，它同時是 OpenAI 通用 GPT-6 系列中的低成本層級，並於 2026-09-22 以一般文字與圖像模型的身分推出。Jev 1.13 則是徹頭徹尾的決策模型——它完全無法輸出自由文字。TypeSafe 於 2026-09-15 推出它，自 2026-09-21 起已正式全面供應。

• 用戶端。OpenAI 自家的 SDK 自 2026-10-06 開放公開測試版以來便已支援此端點，因此這個外掛並不是第一個能呼叫它的方式。它是我們目前所能驗證、第一個不屬於 OpenAI 自家 SDK 的用戶端，也是第一個專為命令列工具而非應用程式函式庫所撰寫的用戶端。

那兩公尺，並排著

這正是客戶的 README 比公告更有價值的地方，因為數字就緊鄰著措辭。

• 價格 — Decisions API 每百萬個輸入 token 收費 $0.10，輸出不收費，快取讀取不收費，快取寫入也不收費。Jev 1.13 每百萬個輸入 token 收費 $0.042，輸出免費。兩者都只就你送出的內容收費，對回傳的內容則不收費，因此無論以哪個價格計算，一次決策的成本都只是一美分的一小部分，而兩者之間的差距是 2.4 倍，並非不同的計費模式。

• 輸入 — Decisions API 接受文字，或混合文字與圖片的用家訊息，而該外掛的 README 指出支援 PNG、JPEG、WebP 與 GIF 附件，每次請求最多 128 張圖片。圖片必須以內嵌 base64 資料 URL 的形式傳入；此端點不接受託管的 HTTP 或 HTTPS 圖片 URL 以及 file_id 輸入，因此外掛會先轉換 URL 或本機路徑再傳送。Jev 1.13 的文件則在另一個方向說得斬釘截鐵：「不支援圖片、音訊或影片輸入」，非文字輸入應在送達狀態之前預先處理成文字或結構化欄位。

• 問題類型 — OpenAI 記載了三種：predicate（所述條件成立、介於 0 到 1 之間的機率）、choice（從你的清單中選出一個值，外加一個分布與一個獨立的信心欄位），以及 score（在有序等級之間取得的機率加權平均）。TypeSafe 的三種其實是相同三個概念換了名稱：noul用於是/否，choice，以及 score。「Noul」是 Bernoulli 的簡稱，而這個名稱也公允地標示出文化差異——一家廠商端出的是白話英文名詞，另一家端出的則是統計學笑話。

• 分數運算——兩者完全吻合，這是最強烈的跡象，顯示這屬於同一個產品類別，而非兩個。OpenAI 的文件為三個嚴重性等級分別提供 0.1、0.7 和 0.2 的機率，並得到 1.1 的分數——刻意落在兩個等級之間，而非就近取整到最接近的等級。TypeSafe 的等級同樣以零為起始索引，而 Jev 的外掛則接受二到十個有序等級。OpenAI 的頁面並未說明上限；那是他們文件中的缺漏，而非我們能斷言的限制。

• 預算 — Jev 精確記錄了它的視窗：每個請求約 64,000 個 token，其中約 32,000 個涵蓋狀態加上最長的那道單一問題，而我們自家型錄中 GPT-6 Luna 作為通用模型所載明的脈絡長度為 1,050,000 個 token。OpenAI 的決策頁面完全沒有公布任何 token 預算，只註明區域處理附加費與長脈絡輸入乘數仍適用於該費率。

客戶所揭露而公告未揭露的內容

外掛及其 README 中有三個細節值得特別提出，因為每一個都會改變你串接端點的方式。

第一點是，決策可能會以拒絕的形式回傳。OpenAI 的文件從未以文字說明這一點，但每個 SDK 範例都會針對它做分支判斷——answer.type === "refusal"（JavaScript），以及OpenAI::Models::Decision::Answer::Refusal這種情況（Ruby）——而此外掛的 README 明確指出，被拒絕的問題會以 {"name":"...","type":"refusal"} 的形式保留下來。因此，答案型別實際上共有四個值，而不是三個，任何正式環境的迴圈都必須處理這個沒有任何公告提及的第四個分支。

第二點是外掛所缺少的，而不是它裡面具備的。Willison 自己的文章把這項工作描述成讓 GPT-6 Astra 閱讀新文件，並據此建構客戶端——從文件到客戶端，一次完成，沒有人工教學。如今這已是一種撰寫客戶端的常態方式，也意味著某個端點的文件是否完整到足以產生可運作的客戶端，這個問題已經變成實務問題，而不是編輯問題。對這個端點來說，答案大致上是肯定的，而拒絕類型則是那道看得見的接縫。

第三點是問題陣列的形狀。OpenAI 讓你可以把彼此獨立的問題放在同一個請求中，針對共用輸入一起處理——在同一通呼叫中檢查產品照片有無損壞，並分類其類別——但當後續問題取決於先前的答案時，就必須拆成不同的請求。Jev 基於相同理由採取相同立場：它的問題是針對同一個狀態平行評估，所以任何具序列性的東西都必須變成兩次呼叫。兩家廠商都是為扇出而設計，而且都在告訴你同一件事：延遲預算該花在哪裡。

這個類別現在有三個佔用者，其中兩個不是通用模型

值得把第三個也提出來單獨說明，因為唯有將三者一併納入視野，「決策端點」這個框架才說得通。Perplexity 推出了自家的 Decisions API，由pplx-decider-v1-27b 提供服務——這是一個 270 億參數的決策模型，於 2026-10-01 以 Apache 2.0 授權發布，權重已上架 Hugging Face。這讓這個類別呈現出與 OpenAI 截然不同的樣貌：Jev 1.13 是閉源且僅支援文字，Perplexity 的決策器則為開放權重並可接受圖像，而 GPT-6 Luna 的產品是在通用模型外搭建的框架，而非專為決策而打造的模型。

對今天要做出選擇的讀者而言，實際的分野比行銷宣傳所說的更窄。若你的證據是一句話或一筆紀錄，而你想要每次呼叫成本最低、行為變異最小，Jev 1.13 是專門的選擇，其 $0.042 的費率是我們能查證的三個公開價格中最低的。若你的證據包含照片，或者你希望由你已在日常任務中熟悉的模型來做判斷，Decisions API 是這兩個封閉選項中唯一接受影像的。開放權重選項回答的是另一個問題——掌控權與自架——而我們尚未測試它。

我們實際上能測量什麼，以及沒有人擁有什麼

OpenAI 對該端點的說法是，它「能評估文字、圖像或兩者，並回傳具型別的答案，速度約比 Responses API 快 10 倍」。這是廠商自述且未經重現：沒有區域、沒有輸入大小、沒有併發層級、沒有服務等級協定，而且基準是泛指 Responses API，而非任何特定工作負載。單一加速倍數不是用來訂定截止期限的正確數字。

我們能放在它旁邊的，是我們自己的七天服務窗口，結束於 2026-10-07，涵蓋下方兩個模型，資料來自我們的 playground 流量——而且重要的是要說明那些數字不是什麼。它們描述的是一般生成請求，不是決策。

• GPT-6 Luna，所有請求型態：中位數 1,448 毫秒、p95 為 4,912 毫秒，七天內 643,394,111 個 token 的錯誤率為 1.31%，這就是模型寫作時、每秒約 125 個輸出 token 的吞吐量所呈現的樣子。

• Jev 1.13：中位數 149 毫秒、P95 245 毫秒，在 110,193,080 個 token 上的錯誤率為 0.10%。這確實是個速度極快的端點，而它之所以快，是因為它不會產生回應——它會為只匯入一次的狀態回傳數字。

把這兩列相互對照來看，它們是個警訊，而不是一項比較。一次決策請求只會輸出少量 token，因此在 Decisions API 上，主宰 Luna 一般概況的輸出吞吐量數字不再是關鍵限制，而開始變得重要的是模型讀取證據所需的時間。我們尚未在 decisions 端點上測量這一點，而且就我們所知，OpenAI 以外沒有人發表過。

更深層、尚未被衡量的問題是校準，而這正是決定這一切是否可用的關鍵。可見損壞的機率為 0.92，只有在你的整體流量中，評分接近 0.92 的照片確實約有 92% 損壞時，才值得據以分流。OpenAI 的文件告訴你要用有標註的範例來設定閾值，並依照偽陽性與偽陰性的成本來選擇閾值。這是正確的建議，同時也等於承認：這些數字的校準是你必須自行建立的事。初步而言，先在你已經知道答案的樣本上，測量回傳機率的分布。如果所有結果回傳的都是 0.99 或 0.01，那麼這個閾值就毫無作用，而這個端點也只是個非常昂貴的布林值。

如何在不將正式環境路徑押注於其上的情況下，試用其中任一個

來源說明，坦白說：本文中的端點合約、價格與圖片規則來自 OpenAI 自家的 Decisions API 文件以及外掛的 README，兩者皆於 2026-10-07 讀取；Jev 1.13 規格來自 TypeSafe 自家的模型文件；服務數據是我們自己的 playground 資料，涵蓋截至 2026-10-07 的七天期間；套件時間戳來自 PyPI 與該專案的 Git 歷史紀錄。10 倍速度的主張是 OpenAI 的，並已如此標示。開放權重決策者的授權條款與發布日期來自其模型儲存庫。

Decisions API 本身是 OpenAI 自家的封裝，我們並不經手轉送；如果你要的是那個特定端點，它就存在於 OpenAI。底層的模型則是另一回事。GPT-6 Luna 是 OrcaRouter 上的一條即時路由，以 OpenAI 的標價提供、零加價直接轉嫁，而typesafe/jev-1.13 以標價提供也位於同一把金鑰上，這讓本文的比較成為你能親手執行、而非只是閱讀的內容：相同的狀態、相同的問題、兩個端點、一份要管理的合約，而且不用多出第二張帳單。

那是採用未經證實介面的明智做法。把決策置於備援機制之後，這樣一來，拒絕、逾時，或測試版限制在你腳下變動時，就會降級成以提示為基礎的呼叫，而不是服務中斷；並讓該備援機制與主要機制使用同一把金鑰，這麼一來，當端點邁向一般可用性時，就沒有什麼需要重新配置。OpenAI 表示 GA 會在接下來幾週內推出，而gpt-6-luna是這段期間唯一的模型；這兩點都是現在就依其形態進行開發並加以監控的理由，而兩者也都不是現在就把付款授權置於其後的理由。

接下來要看什麼

有三件事能解決這篇文章無法回答的問題。為 decisions 端點公布 token 預算，讓請求可以據此估算，而不是憑猜測。任何 GA 公告——這正是僅輸入費率不再只是 beta 承諾的時刻。以及對該端點本身的延遲與校準進行一項獨立測量——第一個把數千組標註配對送進去並公布可靠性曲線的人，對這個領域的貢獻會比兩篇發布文都更大。

在那之前，誠實的總結既狹隘又實用：如果你需要判斷的東西是文字，Jev 1.13 更便宜，而且在我們的流量中大約 150 毫秒內就會回傳數字。如果你需要判斷的東西包含圖像，OpenAI 的 Decisions API 就是會去看它的那個，價格是輸入價格的 2.4 倍，而且包裝盒上還掛著 beta 標籤。截至本週，兩者都可以從命令列呼叫，而這比它們七天前各自的處境都要好。