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，与 Jev 使用的路径相同。

• 问题类型 — choice（命名选项，返回每个选项的概率），noul（是/否问题，返回 P(true)），score（有序等级，返回期望等级和分布）。关于同一状态的多个问题共享一次遍历。

• 上下文 — 根据 API 指南，每个问题为 131,072 个 token，包含图像 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 分布有多集中，而不是答案正确的可能性有多大。

第二个是失败行为。一个只能使用已声明选项作答的智能体无法凭空发明出第六个按钮。它可能出错，也可能校准得很差，但它无法产生你的执行框架不知道如何执行的动作。

第三点是经济性。因为没有输出 token，给十个选项打分的成本与给两个选项打分相同。Nace 的说法是，这让它便宜到可以在每一步都调用；按每千次调用 0.06 美元计算，这笔账是成立的：即便是粗糙的三十步任务，决策成本也不到十分之二美分。按照 Nace 的每次决策数字，同一任务改用 Opus 5.5 大约要三十美分——不算致命，但已是它正在执行之事的价格的三十倍。

基准表，以及这些数字是谁的

以下每个数字都来自 Nace 的发布文章。Decision Index 0.3.2 是一个决策类基准测试的公开排行榜，但 Drex Max 在其中的运行成绩是 Nace 自己用官方套件跑出的，Nace 之外无人复现。榜单的“Full”分数还混入了不属于此次运行的私有测试。请把结果的总体形态视为有参考价值，而把小数位视为营销。

核心数字是公开的决策指数 67.6，而 Drex 2.0 为 61.3，Drex 1.5 为 58.1，J​ev 1.14 为 60.7，GPT-6 Luna Decisions 为 47.8。在配套的视觉指数上——对于一个以视觉为卖点的模型来说，这才是关键数字——Drex Max 得分为 74.5，而 Luna 为 63.9。

• Mind2Web — 与 GPT-6 Luna Decisions 的 81.2 相比为 88.6，这是与浏览器智能体最直接相关的一行。

• 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 工具调用 — 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 兼容性说明让他们做的事——的人，都会调用一个纯文本模型，并纳闷为什么自己的截图被忽略了。

第二个陷阱是尺寸。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 是一条已列出的路由，价格为每百万输入 token 0.042 美元，上下文长度为 65,536 个 token，通过相同的 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 之外的任何人核验过的数字——而表格中真正经受住实际部署检验的那部分，很可能正是没人引用的那部分。