OpenRouter 实测 Jev 1.13 对比 Claude Opus 5,分类准确率差 3.3 点、成本仅 1/22
Is Jev as Accurate as Frontier Models at Classification?
- 1Jev 1.13 在 3,080 条银行客服语料上准确率 81.0%,比 Claude Opus 5 的 84.4% 低 3.3 点
- 2Jev 中位延迟 175 毫秒约为 Opus 的 1/13,每千次请求 $0.11 对 Opus 的 $2.42,约为其 1/22
- 3按置信度 0.90 阈值级联,76% 流量由 Jev 承接,准确率 84.0%,每千次 $0.69,约为纯 Opus 的三成
- 4作者标注局限,单数据集单次 15 分钟窗口,Opus 关闭推理;两模型均低于微调编码器的低 90% 水平
在小数据分类任务上,小型判断模型加置信度级联已能以不到三成成本逼近前沿模型,差距可压到 0.4 点内。
- 影响:意图识别、工单打标这类高频低延迟场景有了量化的成本参照;Opus 开 prompt caching 后每千次从约 $19 降到 $2.42,缓存策略直接影响账单;级联阈值需用自有流量重定,文中数字是该次测试的上界。
- 参考:可考虑挑一条量大、时延敏感的分类链路,先算出自家每千次成本与准确率曲线,再定 Jev 置信度阈值;值得复核现有用前沿模型做分类的调用是否已开 prompt caching。
- 依据:数字出自 OpenRouter 自行运行的 Banking77 全测试集 3,080 条评测,3.3 点差距的 95% bootstrap 区间为 2.3 到 4.4 点,属平台方单次窗口自测口径。
译文尚不完整,完整内容请切换到原文。
Jev 是 TypeSafe 的 System One 决策模型。给它一个应用状态对象和一个带类型的问题,它就会返回一个带类型的答案、一个置信度分数,以及每个可能选项的概率(即 Decisions API 的响应类型,而非聊天端点)。按照 TypeSafe 的宣传,在这类分类任务上,你可以用一个像 Jev 这样的小型判断模型来替代前沿聊天模型,同时大幅降低成本和延迟。那么你会牺牲多少准确率呢?
我们让 Jev 1.13 和 Claude Opus 5 分别处理了 3,080 条 Banking77 客服话语;截至 2026 年 9 月 22 日,在 OpenRouter 排行榜页面的 Task 支出部分,Opus 是用户在分类任务上花费最多的模型。每条话语会被归入 77 个银行意图之一,两个模型拿到的每个意图的单行描述完全相同。
下图将 Jev 与 Opus 并列对比,展示两者在准确率、中位延迟和每千次请求成本上的表现。

Jev 在准确率上落后 Opus 3.3 个百分点,但中位延迟快 13 倍,成本仅为 Opus 的 1/22。
Jev 与 Claude Opus 5 一览
下面详细看看结果。Macro-F1 对每个意图赋予相同的权重。
| Jev 1.13 | Claude Opus 5 | |
|---|---|---|
| 准确率 | 81.0% (79.6 to 82.3) | 84.4% (83.1 to 85.6) |
| Macro-F1 | 80.5% | 83.6% |
| 无效响应 | 3,080 条中 0 条 | 3,080 条中 0 条 |
| p50 延迟 | 175 ms | 2,266 ms |
| p95 延迟 | 270 ms | 3,004 ms |
| p99 延迟 | 353 ms | 3,835 ms |
| 完整运行的计费成本 | $0.34 | $7.44 |
| 每 1,000 次请求的成本 | $0.11 | $2.42 |
| 平均输入 token 数 | 2,605 | 3,750(其中 3,725 已缓存) |
| 平均输出 token 数 | 826 | 17 |
括号中的数字是 95% bootstrap 置信区间,我们用 3,080 个样本计算得出。两个模型都没有返回格式错误的响应。每个错误都是标签错误,而非解析失败。
我们是如何运行的
Banking77 是来自 PolyAI 的话语级客服意图数据集,采用 CC BY 4.0 许可证。这些话语很短,中位长度为九个词,每条都被标注为 77 个意图之一。我们在 Banking77 上运行 Jev 和 Opus 时,使用的是完整的测试分割,共 3,080 个样本,每个意图 40 条。有些意图彼此非常接近,模型无法只凭几个关键词就不再继续阅读。想想 card_arrival 与 card_delivery_estimate。
我们仅根据标签名称为每个意图写出一条单行判据,完全没有查看测试数据,并把完全相同的判据列表同时提供给 Jev 和 Opus。为了给 Jev 评分,我们把每条话语作为 Decisions API 的 Choice 问题发送,并以这 77 条判据作为选项。对于 Opus,我们构建了一个提示词:系统消息列出所有判据,随后的用户消息只包含话语本身。我们以温度为零、关闭推理的设置运行 Opus,并使用带有 77 个标签枚举的严格 JSON schema 响应格式。我们为系统消息开启了 提示词缓存,因为它在每次请求中都完全相同。两个模型在同一台机器上运行,我们每次发送 8 个并发请求,并将延迟测量为客户端观察到的经 OpenRouter 的往返时间。
Jev 的准确率有多高?
我们来聊聊数字。在 Banking77 上,Jev 为 81.0%,Opus 为 84.4%。配对 bootstrap 给出的 95% 置信区间为 2.3 到 4.4 个百分点,因此 Opus 领先约三个百分点不太可能是噪音。
好的一面是,这两个模型有大量共识。它们在 89.3% 的话语上判断一致。在意见相左的地方,仅 Opus 答对的有 175 条,仅 Jev 答对的有 72 条。
On the downside, both are still sitting well below the low 90s that encoders fine-tuned on all 10,003 Banking77 training examples report. That’s the cost of relying on one-line criteria instead of doing a full fine-tune.
By class, Opus leads Jev on 35 of the 77 intents, Jev on 15, tied on 27. Opus’s biggest lead is on receiving_money, where it’s at 80.0% compared to Jev’s 52.5%. Meanwhile, Jev shines on compromised_card where it’s at 95.0% while Opus is at 70.0%. Opus tended to mistake stolen card details for an unrecognized payment.
How fast and how cheap is Jev?
Very quickly, Jev’s median round trip was 175 ms and p95 was 270 ms. Opus, on the other hand, without reasoning mode, had a median round trip of 2,266 ms and p95 of 3,004 ms. That means the slowest Jev call (~1.6s) was faster than the fastest Opus call (~1.9s).
The total for Jev was $0.34, or $0.11 per thousand requests. Opus came in at $7.44, or $2.42 per thousand requests. That Opus figure has the 3,700-token system prompt cached, so all the requests were at the cache-read rate instead of the list rate. Without caching, the list rate for Opus would have been about $19 per thousand requests. So if you’re using a label taxonomy with a frontier model, cache that system prompt.
Routing on Jev’s confidence
Jev gives you a confidence score, but it’s not a calibrated probability. Here, it overestimated its own accuracy mid-range. Still, it ranks well. For 58% of utterances with confidence ≥0.99, accuracy is 96.3%. For the 3.5% below 0.5, accuracy is 29.6%.
That ordering is all you need to cascade. Accept Jev above a given threshold, send the rest to Opus. Here’s accuracy and cost per thousand at each threshold, ranging from Jev only down to Opus only.
| Threshold | Handled by Jev | Accuracy | Cost per 1,000 |
|---|---|---|---|
| Jev only | 100% | 81.0% | $0.11 |
| 0.99 | 57.8% | 84.3% | $1.13 |
| 0.95 | 68.1% | 84.2% | $0.88 |
| 0.90 | 75.9% | 84.0% | $0.69 |
| 0.80 | 82.7% | 83.6% | $0.53 |
| 0.70 | 87.3% | 83.2% | $0.42 |
| Opus only | 0% | 84.4% | $2.42 |
At threshold 0.90, 76% of traffic bypasses Opus. In exchange, your accuracy is reduced by at most 0.4 points relative to Opus alone, and your cost cut by a factor of 3.5. Opus got right 175 utterances that Jev missed. The median confidence of those cases was 0.67, and 85% were below 0.90. So Jev usually knows when it’s just guessing.
Caveats
So let’s talk narrowly about the actual test we did: one dataset, one domain, one prompt design, and one fifteen-minute window on one afternoon.
If there is an Opus memorization edge here, its score may be slightly flattered by it, because Banking77 was published in 2020. But you can’t tell from this run alone.
The other point is that both models stumbled on one class, because the criteria were written from label names only, without seeing example messages. In this case, one of the labels was get_physical_card, which covers queries about whether the PIN is delivered separately. It’s practically impossible to guess that from the name. Each model scored 0 out of 40 on that class, routing most messages to change_pin instead. Excluding that class alone, Jev hit 82.1% and Opus 85.5%. But a shipping team would iterate on the criteria using held-out training data, not the test set, and both models would get better.
The cascade table we showed used exactly the same 3,080 examples used for the accuracy measurement, so this is an upper bound. Choose your threshold based on your own traffic.
And lastly, these tests were run with Opus in “reasoning off” mode and structured outputs on. Opus was not tested in “reasoning on” mode, or with other schemas or few-shot examples.
What this means
如果准确率上三个百分点的差距比每千次请求 2.42 美元的成本更重要,那就选 Opus。如果你面对的是高并发、低延迟需求,或者需要一个兜底方案,仅用 Jev 就能达到与 Opus 相差 3.3 个百分点以内的准确率。更妙的是,基于 Jev 的置信度分数运行级联,能让我们与 Opus 的差距缩小到 0.4 个百分点以内,而成本不到 Opus 的 30%。
Decisions API 参考介绍了基本的请求结构。Jev cookbook 演示了一个用 TypeScript 编写的可运行的 Choice 问题。Jev-verified cascade cookbook 提供了升级模式的代码实现:由廉价模型起草,Jev 检查草稿,前沿模型只处理未通过检查的内容。Banking77 测试集是 PolyAI 仓库中一个 3,080 行的 CSV 文件。
要对你自己的积压数据运行类似的标注任务,使用 Jev 大规模分类和标注文本的 cookbook 涵盖了在速率限制内进行批处理、根据已标注样本为每个标签选择阈值,以及计算每 1,000 条数据的成本。如果你刚接触 Jev,可以从 什么是 Jev?开始,然后阅读 Jev 与 LLM 对比,了解决策模型何时可以取代生成式调用。Jev 文档中心列出了 OpenRouter 上的所有 Jev 指南和 cookbook。
常见问题
在意图分类任务上,Jev 与 Claude Opus 5 相比准确率如何?
在 2026 年 9 月 22 日运行的 Banking77 测试集(包含 77 个意图的 3,080 条话语)上,Claude Opus 5 取得了 84.4% 的准确率和 83.6% 的宏平均 F1,而 Jev 1.13 取得了 81.0% 的准确率和 80.5% 的宏平均 F1。两者的配对差距在准确率上为 3.3 个百分点,95% bootstrap 置信区间为 2.3 到 4.4 个百分点。两个模型在 89.3% 的话语上结果一致。
在分类任务上,Jev 比前沿模型快多少?
在中位数和 p95 客户端观测往返延迟方面,Jev 的中位数为 175 ms,p95 为 270 ms,而禁用推理功能的 Claude Opus 5 中位数为 2,266 ms,p95 为 3,004 ms,中位数约为前者的 13 倍。这些数据是在 8 个并发请求下从同一客户端测得的,包含网络时间以及实际推理前供应商系统中的任何排队时间。
在 OpenRouter 上使用 Jev 对文本进行分类需要多少钱?
在 typesafe/jev-1.13 上,全部 3,080 个 Banking77 请求总计计费 0.34 美元,即每千次请求 0.11 美元,约合每次请求 0.0001 美元。对包含 77 个标签的系统提示词使用提示缓存后,相同请求在 anthropic/claude-opus-5 上总计计费 7.44 美元,即每千次 2.42 美元。如果不使用缓存,按标价计算,Opus 每千次请求的计费约为 19 美元。
我可以使用 Jev 的置信度分数来决定何时回退到更大的模型吗?
可以,而且在我们的数据中它可以用作排序信号。我们测得 Jev 在置信度不低于 0.99 的那 58% 话语上准确率为 96.3%,而在置信度低于 0.5 的那 3.5% 话语上准确率为 29.6%。将置信度低于 0.9 的请求全部路由到 Claude Opus 5,可以将准确率恢复到 84.0%,与单独使用 Opus 相差不到 0.4 个百分点,成本为每千次请求 0.69 美元。由于该分数并未按概率进行校准,请根据你自己的数据选择合适的阈值。
来源:OpenRouter:Blog(Announcements) · openrouter.ai