agent 迴圈裡有大量這種問題：這條 shell 指令可逆嗎？這個頁面相關嗎？該走哪條 route？每一題的答案都只有幾個選項，但 chat model 回答時照樣要 build prompt、生成文字、parse、validate schema、drift 時 retry。分支夠多的時候，控制流程的成本會超過真正的工作。
兩個產品，兩種架構
2026 年 9 月 29 日，OpenAI 在 DevDay 宣布 Decisions API：把 GPT-6 Luna 限定在開發者預先定義的問題和答案清單上，輸入文字或圖片，回傳一個可以直接 branch 的選項。它不做起草、摘要或解釋。Sam Altman 在 keynote 上用它驅動一個 computer-use agent，並說「這不是加速播放」。
十四天前，TypeSafe AI（由前 OpenAI 研究員 Diogo Almeida 創立）已經推出 Jev——一個 purpose-built 的 decision model，官方說法是它從頭就沒學會寫字。它有三個可混用的 primitive：Choice 回傳選中的選項加上每個選項的機率和 confidence；Noul 回傳條件成立的機率；Score 回傳 ordered rubric 上的位置加完整分布。
架構上的差異落在三個地方：Jev 不生成文字，所以 output token 免費，輸入價格是每百萬 token 0.042 美元；OpenAI 的做法是收窄一個 generative model 的職責。圖片輸入是 OpenAI 的明確優勢——Altman 的 demo 正是看螢幕做決策，而 Jev 目前只吃文字。
OpenAI 沒公開的東西
根據 Firecrawl 作者 Hiba Fathima 的查核，截至 2026 年 9 月 30 日，OpenAI 沒有發布 Decisions API 的 endpoint path、request 或 response schema、SDK method 或定價。她檢查了 API guides、endpoint reference、文件匯出、OpenAPI spec 和三種語言的 SDK，都找不到；DevDay recap 裡，這是唯一沒有「Learn more」連結的公告。換句話說，任何展示 OpenAI Decisions request body 的文章都是編的。
官方的延遲數字也該小心讀。DevDay 投影片寫 150 ms 對上標準 GPT-6 Luna 呼叫的 1.6 s——十倍加速，但基準是 OpenAI 自己最便宜的模型。對照組：OpenRouter 的實際流量遙測顯示 Jev 的 P50 是 0.21 秒、P99 是 0.75 秒。一個是未註明條件的 vendor claim，一個是實測，作者的建議是在有人同時 benchmark 兩者之前，當作同一個量級。
社群怎麼看
Hacker News 上的反應比想像中冷淡，一個原因是開發者這兩週已經看過六次社群自製版本——包括拿到 691 分的「Jev in 25 Lines of Python」，以及在自家訓練出 Jev 相容 0.8B 模型的「Jeff」。有人質疑整個類別：grammar constraint 在任何 LLM 上都能保證格式正確。反駁的關鍵在於 structured outputs 是在模型決定說什麼之後約束形狀，而 decision endpoint 是在推理之前就限縮答案空間，所以往返本身變短。
關於 Jev 的命運，兩邊都有人下注。一方說兩週就被追平代表這裡沒有 durable moat；另一方說 OpenAI 進場本身就證明了類別是真的。Almeida 在 keynote 後九十分鐘發文回應，拿到 647 個讚。還有個實際的小麻煩：OpenRouter 本來就有一個叫 Decisions API 的 endpoint，而且就是拿來跑 Jev 的，搜尋時很容易混淆。
落地時的三個判斷
不管選哪一家，設計模式是共通的：送進去的是人類審核者回答這一題所需的證據，問題要具體到兩個工程師會同意什麼叫正確答案，然後把結果當作 policy code 的輸入——權限、資源範圍和業務規則留在你的程式裡。0.97 的「看起來安全」分數不能替帳戶授予它本來沒有的權限。
這和我之前寫過的決策模型落地是同一條線：Clef-omni 把跨模態打分壓進一次 API 呼叫，思路同樣是把判斷從生成的文字裡拆出來。
實際的下一步：如果你的決策點涉及螢幕截圖，目前只有 OpenAI 的方案可行，但要接受沒有公開契約的風險；如果只需要文字、要 per-option 機率和確定的 schema，Jev 已經 generally available。兩者的延遲差異，最好等獨立 benchmark 出來再下結論。