Drex Max 聚焦決策模型——並將每次點擊定價為 0.06 美元

電腦操作代理其實不是單一決策。訂一張機票就是三十個決策：要點哪個欄位、要開啟哪個結果、行事曆小工具是否已完成渲染、它正在看的票價是否就是它要的票價。其中每一項都是一趟截圖往返；而如果另一端的模型是前沿聊天模型，每一項都要花上數秒，還要付上一筆前沿模型帳單。Drex Max，由 Nace.AI 於 2026 年 10 月 19 日正式全面推出，試圖壓縮這套算術。它是決策模型，而非聊天模型——你交給它一個畫面和一组具型別的選項，一次前向傳遞就會回傳每個選項的機率。Nace 將其標價為每百萬輸入 token 0.06 美元、中位延遲 183 毫秒，且完全不收輸出費用，因為它什麼都不寫。 像這次發布這樣的產品，其背後的已記錄 AI 故障與代理事件，都彙整於 OrcaRouter AI Incident Archive，其中每一筆條目都附有各自的來源、嚴重程度、信心等級與爭議標記。

Nace 拿來與此並列對照的是TypeSafe J​ev 1.14，這個定義了該類別請求形態的決策模型，以及當今代理所使用的通用前沿模型。在 Nace 自己公布的表格上，Claude Opus 5.5 是每千次決策 10.17 美元、每次決策約 3.5 秒，而 Drex Max 在同樣 243 道螢幕截圖題目上是 0.06 美元與 174 毫秒。廠商數據、自行執行、未經 Nace 以外任何人審核——但數量級才是重點，而這正是這個版本比它的基準測試那一列更重要的原因。

實際發佈的內容

Drex Max 是 Drex 系列中首款配備視覺編碼器的模型。Drex 2.0 與 Drex 1.5 是文字輸入、機率輸出；Max 則能讀取螢幕截圖、螢幕錄影、掃描文件、圖表、照片與影片影格，並回答與前代相同的三種問題類型。

• 模型 ID — drex-max，已固定。無開放權重；透過 Nace 自家 API 託管，不提供可下載的檢查點。

• 輸入結構 — 一個 state 字串加上一個 questions 物件，以及一個 images 陣列，每次請求最多 8 張圖片。端點為 POST /v1/systemone，與 J​ev 使用的路徑相同。

• 題型 — choice（具名選項，回傳每個選項的機率）、noul（是非題，回傳 P(true)）、score（有序等級，回傳預期等級與分布）。關於同一狀態的多個問題會共用一次執行。

• 上下文 — 根據 API 指南，每個問題包含圖片 token 在內共 131,072 個 token。發布文章另外指出「262K token 上下文視窗」。這兩個數字不一致，這是在你設定截圖緩衝區大小之前首先要解決的事。

• 價格 — 每百萬輸入 token 為 0.06 美元；輸出不予計費。Nace 引用相同的數字為每千次決策 0.06 美元，這意味著每次呼叫大約需要一千個 token。

• 前代模型 — Drex 2.0（總參數 35B、約 3B 活躍參數，建構於 Qwen3.6-35B-A3B，開放權重），每千次決策 0.06 美元；以及 Drex 1.5（9B，純文字），每千次決策 0.04 美元。

• 部署 — 可託管於 Nace 的 GPU 上、專用部署、位於客戶的 AWS 或 Azure 帳戶內，或採氣隙部署，全部皆使用相同的請求契約。不提供權重意味著無法自行託管，但這並不代表只能採用 SaaS。

這個介面裡沒有任何稀奇之處。這是刻意為之：Nace 打造 Drex Max 時，讓它在傳輸層與 TypeSafe 的 J​ev SDK 相容，因此@typesafe-ai/sdk 只要變更基底 URL、金鑰與預設模型就能繼續運作。這種相容性不是對競爭對手的禮遇。這正是新進者獲得試用機會的方式——最省成本的遷移，就是只改一個設定值。

真正不同的部分：是一個分佈，而不是一個句子

聊天模型回答電腦操作問題時，是靠「寫」出答案。例如：「查看頁面後，搜尋結果似乎已經載入，所以下一個動作應該是點擊第二個結果」——接著你的評測框架會解析這句話，或解析一段 JSON 資料，並希望模型沒有選了你從未提供的選項。這種設計的代價要付兩次：一次是輸出 token，另一次是你必須維護的解析器，因為模型可能會幻想出螢幕上根本不存在的按鈕。

Drex Max 無法做到那件事。它只會回傳你所提供選項上的機率，別無其他。如果你提供五個可點選的候選項，你會得到五個加總為一的數字。那是更狹窄的能力，也更適合放進迴圈裡，而這背後有三個理由，在正式環境中比在展示中更為重要。

第一項是設定閾值。機率分布讓你能寫出自己真正想要的規則：當首選選項超過 0.9 時就採取行動，否則就升級到較慢的模型或轉由人工處理。生成式模型給你的是一句話，外加一個意義截然不同的信心欄位——那通常代表詞元分布有多集中於峰值，而不是答案正確的機率有多高。

第二個是失敗行為。只能以已宣告選項作答的代理，無法自行發明第六個按鈕。它可能出錯，也可能校準得很差，但它無法產生你的執行框架不知道如何執行的動作。

第三點是經濟效益。由於沒有輸出 token，為十個選項評分的成本與為兩個選項評分相同。Nace 的說法是，這讓它便宜到可以在每一步都呼叫，而以每千次呼叫 0.06 美元計算，這筆帳成立：即使是一個馬虎的三十步任務，決策成本也不到十分之二美分。同樣的任務若改用 Opus 5.5，按 Nace 的每次決策數字計算，大約會是三十美分——不算致命，但仍是它正在做的事情價格的三十倍。

基準測試表，以及這些數字是誰的

以下每個數字都來自 Nace 的發布文章。Decision Index 0.3.2 是決策型基準的公開排行榜，但其中 Drex Max 的跑分是 Nace 自己做的，使用的是官方套件，而 Nace 以外沒有人重現過。該榜單的「Full」分數還混入了不屬於這次跑分的非公開測試。請把結果的整體樣貌視為有參考價值，而小數點位數則視為行銷手法。

頭條數字是公開的 Decision Index：67.6，相較之下 Drex 2.0 為 61.3、Drex 1.5 為 58.1、J​ev 1.14 為 60.7，而 GPT-6 Luna Decisions 為 47.8。在配套的 Vision Index 上——對於一個賣點在於視覺能力的模型來說，這才是關鍵數字——Drex Max 得分 74.5，而 Luna 為 63.9。

• Mind2Web — 88.6 對 81.2（GPT-6 Luna Decisions），是與瀏覽器代理最直接相關的一列。

• OSWorld-Verified — 0.780，GPT-6 Sol 為 0.756，Claude Opus 5.5 為 0.790。Drex Max 勝過前者，僅微幅敗給後者。

• OSWorld-V2 — 0.737，相較於 Sol 的 0.744 與 Opus 5.5 的 0.761。同樣的情況，差距略為擴大。

• BFCL tool calling — 98.2，領先 J​ev 1.14 的 96.4 與 Claude Opus 5.5 的 97.3，僅次於 GPT-6 Sol。

• DecideBench — 項目得分 98.5、配對得分 97.0，兩者均領先 J​ev 1.14。

• 商業決策與 J​ev 1.14 相比——FinEntity 92.3 對 81.9，BANKING77 90.0 對 79.7，ContractNLI 75.9 對 57.7。

OSWorld 的那幾列值得附上一項 Nace 的表格未明確說明的提醒。那些分數描述的是完整的自動化堆疊，而目前並未記錄 Drex Max 周圍的迴圈有多少也屬於 Nace 自己的測試框架。一個能妥善挑選下一步行動的決策模型，仍取決於負責截圖、等待算圖完成，以及判定任務何時結束的機制。請把 0.780 解讀為決策並非瓶頸的證據，而不是對你的代理程式所做的承諾。

它在哪裡失利，也就是表格中更有用的那一半

這些損失並未被掩蓋，但很容易被匆匆略過，而且其中兩項描述的是真正的限制，而非四捨五入的誤差。

在一般知識與困難推理方面，決策模型根本無法與前沿聊天模型競爭，而 Drex Max 也改變不了這一點。MMLU-Pro 為 72.5，落後於 J​ev 1.14 的 82.1、Sol 的 93.0，以及 Opus 5.5 的 94.0。HLE 為 19.0，對上 J​ev 的 19.4——無論怎麼看，都是在該區間墊底的平手。對於一個職責是在給定螢幕下從簡短清單中挑選的模型來說，這是預料之中的事；而這正是為什麼決策模型是代理中的一個元件，而不是負責規劃的模型之替代品。

更有趣的是它相較於自身前代模型的退步。在 When2Call 上，這項基準測試詢問工具呼叫究竟是否有其必要；Drex Max 得分 85.2，Drex 2.0 則為 86.5，而更舊、更便宜的 Drex 1.5 得分 89.7。最新且最昂貴的 Drex 模型，在三者中最不善於判斷何時不該採取行動。如果你的工作流程依賴克制——例如客服代理應該保持沉默，而不是呼叫退款工具——視覺能力並不能為你帶來這一點，而更便宜的文本模型可能仍是正確選擇。

同樣的模式也出現在兩個走向相反的視覺列中。掃描表單上的關鍵資訊擷取（KIE）為 95.5，對上 Luna 的 97.5。Hateful Memes 內容審核為 70.6，對上 71.2。這兩個差距都不大，而且兩者所屬的領域，正是 Drex Max 在其他地方擁有三十點大幅優勢的領域，這暗示視覺編碼器是偏向螢幕版面配置與圖表來訓練，而非印刷表單或迷因。

延遲也倒退了。Drex Max 的中位數為 183 ms，比 Drex 2.0 慢 32 ms，比 Drex 1.5 慢 38 ms。在每個任務執行三十次的迴圈中，這相當於每項任務多花約一秒，而相較於前沿模型，每個步驟可省下數秒。這仍是正確的取捨，但值得知道視覺編碼器並非沒有成本。

有一個數字需要先釐清，免得它被人拿來向你引用。開頭段落裡的 174 ms 是 Nace 僅憑螢幕截圖所做的測量——243 道圖片問題，一次送出一個請求，對比同一組題目上 J​ev 1.14 的 253 ms。183 ms 則是發表表格中整個基準測試套件的中位數。兩者都是 Nace 的；它們是不同的測量，而比較好看的那個是範圍較窄的那個。

在你動手串接任何東西之前，API 裡的兩個陷阱

文件裡有個細節，只要快速掃過，就會讓人白白耗掉一個下午。drex-latest 並不是指向 Drex Max。它是一個固定版檢查點，而這個別名會解析到別的東西。任何照著快速入門操作、換上自己的金鑰並設定 TYPESAFE_DEFAULT_MODEL=drex-latest 的人——這正是 Jev-compatibility 指示要他們做的事——都會呼叫到純文字模型，還納悶為什麼自己的截圖被忽略了。

第二個陷阱是尺寸。API 指南將每個問題的上限設為八張圖片和 131,072 個 token（包含圖片 token）；發布文章則宣稱可達 262K。在 Nace 釐清兩者之前，請以較小的數字為準。目前沒有公布每張圖片的 token 成本，這使得上限難以事先推斷：全解析度螢幕截圖並不是固定的 token 數量，而文件也未說明圖片會如何縮放或切割。

有一件事比現有方案更容易：Drex Max 接受任何尺寸的截圖。J​ev 1.14 的 API 會拒絕任一邊小於 280 px 或大於 1,568 px 的圖片，這種限制正是那種會在凌晨兩點的重試迴圈中悄悄失敗的問題。

這對路由決策有何影響

實際的問題，不是 Drex Max 是否比前沿模型更好。它並不是，它也無意成為。問題在於：一項任務裡的三十個決策當中，哪些值得動用前沿模型，哪些只需要一個 174 毫秒的機率分布——而這首先是個路由問題，其次才是模型問題。

Drex Max 不在我們的路由清單中。OrcaRouter 目錄並未收錄它，而且這裡的任何內容都不應被解讀為我們對其可用性的聲明——Nace 是透過自家的 API 與自家主控台銷售它。我們實際收錄的，是它用來對標的既有方案。TypeSafe Jev 1.13 是已列出的路由，每百萬輸入權杖 $0.042，上下文為 65,536 個權杖，並透過相同的 POST /v1/systemone 要求主體提供服務，因此，在決策模型與你目前的螢幕截圖到前沿模型迴圈之間做 A/B 測試，只是換一個模型字串，而不是改寫。要解決這件事，最省成本的做法是：把你僅處理文字的決策呼叫留在原處，另外為需要「眼睛」的任務加上一個讀取螢幕的步驟，並用你自己的日誌來衡量兩者，而不是用 Nace 那 140,178 筆已評分請求。

這種拆分方式唯有在各個部分都能從同一個地方存取時才行得通。一把金鑰通行 200 多個模型，供應商牌價原樣轉嫁，不按每個 token 加價，以及跨供應商的自動容錯移轉，正是避免這項實驗在當初設定的人換團隊後，淪為無人維護的過時分支的關鍵。這裡還有一個特定原因讓它格外重要：Drex Max 是全新、未經稽核且僅提供 API 的服務，而採用未經驗證元件時，安全的做法是把它放在某個能在其信心下降或端點行為異常時，退回已知模型的機制之後。把有把握的判斷交給便宜模型，其餘交給容錯移轉處理。

什麼會改變這個讀數？

首要之務是獨立跑一次 Decision Index。這套評測套件是公開的，Nace 說這些評測可重現；而在公司外部有人用它跑 Drex Max 之前，67.6 只是供應商自己報的數字。到時要留意的是那些指向相反方向的儲存格：Mind2Web 上領先 30 分，旁邊卻是 When2Call 上的效能衰退，這不是一條平順的能力曲線，而是描述一個模型被大力訓練於「這些選項中哪個是下一次點擊」，對「我到底該不該點任何東西」的訓練則沒那麼用力。如果這一點成立，那就是關於 Drex Max 在營運上最重要的事實，而它並不在亮點摘要裡。

併發情況下的生產環境延遲是第二點。Nace 自己公布的吞吐量數據——在單一 H100 副本上約每秒 25 個請求，最多 64 個在途請求仍無錯誤——是針對 Drex 整體，而非專指 Max。該設計的整個賣點在於它位於每一步的熱路徑上，這使得負載下的 p95 遠比 183 毫秒的中位數更具相關性，而目前沒有任何已發布資料處理這一點。

第三，定價需要一個包含圖片的實際範例。每百萬輸入 token 收費 $0.06，只有在你知道一張螢幕截圖要花多少 token 時才有用，而目前沒有任何公開數據能做到這一點。一個團隊若在為每步使用 1440p 螢幕的 30 步迴圈編列預算，在 Nace 公布圖片計費方式、或有人實際測量之前，都只能靠猜。

這些都不會讓這次發布變得比較不有趣。一個能「看見」的決策模型，與一個被要求查看截圖的聊天模型，是真正不同的元件；而價格差距大到足以改變代理在每一步能負擔做什麼。只是這還不是 Nace 以外任何人驗證過的數字——而表格中能經受真實部署考驗而留存下來的部分，大概會是沒有人引用報價的那一部分。