AREX Feed Article
Jev 路由器首批独立测试结论相反：Theo 称更贵且慢近 5 倍，Elvis 称成本减半、全部答对
OpenRouter 的 是一个由 TypeSafe AI 小型判断模型 Jev 驱动的缓存感知路由器，按请求挑选模型和推理力度（reasoning effort）。上线次日，两份独立测试先后出现，结论指向相反方向：9 月 26 日，开发者 Theo - t3.gg 发帖称，他花 1,000 美元跑了一夜 DeepSWE 基准，路由后的性能与直连 GPT-6 Astra 低档大致相当，成本略高，耗时接近 5 倍；几小时后，DAIR.AI 创始人 Elvis（@omarsar0）公布的小样本复现显示，8 个案例、32 次真实调用全部答对，成本不到固定 GPT-6 Sol 基线的一半，中位响应时间反而更短。而在这两份数据出现之前，Gergely Orosz 已于 9 月 25 日发帖称，Linear 在路由器发布约一个半小时后就把它接进了 emoji picker（表情选择器）。
OpenRouter 发布约 95 分钟后，Linear 把 Jev 接进了 emoji picker
时间线从 9 月 25 日 22:21（UTC）开始。宣布 typesafe/jev-router 上线：对话发给 typesafe/jev-router 后，由 Jev 为每个请求挑选模型和推理力度，在质量、速度与成本之间取舍；解释了缓存设计——Jev Router 会在会话内尽量沿用当前模型，只有当换模型的预期收益大于切换成本（包括丢弃已缓存对话的损失）时才真正切换。发布当时，这款路由器的公开效果数据为官方自述：据开发者的 OpenRouter 自评，4 项 Agent 基准共 423 个任务中，Jev Router 完成 237 个，自家 Auto Router 完成 130 个，多完成约 82%。
23:56（UTC），技术通讯《Pragmatic Engineer》的作者 ：「Linear 领先了一个段位：他们已经把 Jev 集成进 emoji picker，效果惊艳。」他补充说，这条帖子是在一个吐槽 Google Docs emoji picker「二十年都没法用」的串里回的，✅ 图标在他的免费和付费账号上依然找不到。截至 9 月 28 日晨，这条帖子有 2,139 个赞、约 23.5 万次浏览。这是 Orosz 的一手使用体验，不是系统评测，帖中也没有 Linear 官方的说明或实现细节。
Theo 的基准截图：得分持平，耗时约 4.3 倍
9 月 26 日 09:12（UTC），：「我熬到凌晨 2 点、花了 1,000 美元给 Jev Router 跑分，这样你们就不用跑了。在 DeepSWE 上，性能与 GPT-6 Astra 低档大致相当。成本略高，运行时间几乎是 5 倍。」随帖的结果截图显示，测试用与公开排行榜相同的 harness（驱动代理循环的框架代码）跑 DeepSWE 的 20 个任务，每个任务只尝试一次：Jev Router 与 GPT-6 Astra 低档同为 20 题对 16 题（80%）；单任务账单成本 1.50 美元对 1.46 美元；每任务平均耗时 19.9 分钟对 4.6 分钟，约 4.3 倍。截图第三行给出参照：把 GPT-6 Astra 拉到最高推理档 xhigh，得分升至 17/20（85%），代价是单任务 4.42 美元、12.8 分钟。
截至 9 月 28 日晨，这条帖子获得 3,559 个赞、约 52.4 万次浏览，是三篇帖子里传播最广的一份。它的证明力同样有限：这是一次单轮运行，方法细节只体现在一张截图里；Theo 本人是编码工具公司 T3 Code 的 CEO，所测的又是编码场景的路由产品，与被测对象存在竞争关系。
Elvis 的复现：小型客服代理上的对照测试
同日 15:51（UTC），，称这是「我在 Jev 这类 System One 模型上见过的最有说服力的用例之一」。他的测试对象是用 Pi SDK 搭建的自定义 harness 里一个小型客服代理：同样 8 个案例，一组走 typesafe/jev-router，另一组固定调用 GPT-6 Sol 基线，共 32 次真实调用。两组全部答对；路由方案成本 0.008 美元，基线 0.018 美元，不到一半；中位响应时间 1.5 秒对 1.9 秒。
他写明了前提：「样本很小。」他还提到自己用 Jev 做路由器最大的顾虑是缓存——「这个问题没有被完全解决，但 Jev Router 让我看到了希望」。Elvis 把自己感兴趣的路由模式实现放到了 ：页面把 Jev 描述为只为决策服务、以数字作答、从不生成文本的小模型，并演示如何在 Pi SDK 的代理循环里接入。截至 9 月 28 日晨，这条帖子获 275 个赞、304 个收藏。
两份相反的测试，为什么还定不了论
两份测试量的并不是同一个东西。Theo 测的是端到端编码任务：DeepSWE 上 20 个 agent 任务，比的是得分、OpenRouter 账单成本和代理平均工作时长，对照组是 GPT-6 Astra 低档；Elvis 测的是客服代理的逐步决策：8 个案例、32 次调用，比的是答对数、总成本和单次调用中位响应时间，对照组是 GPT-6 Sol。同一个「快」字，两种口径读数相反：按任务计，走路由器的代理平均多跑十几分钟；按调用计，它的中位延迟反而更短。
两份数据目前都撑不起普遍结论。Theo 的基准是单轮运行，方法只有一张截图；Elvis 自己承认样本极小，8 个客服案例无法外推到其他工作负载；OpenRouter 那组 423 个任务的数据同样出自厂商自测。围绕路由器底层 Jev 的争论也没停过： 获得 2,500 多个赞的帖子写道，「它当然只是个分类器，但这是一个带着接近前沿智能的零样本分类器」；另有开发者称，固定句子编码器、只训练一个逻辑回归分类器，在 banking77 数据集上准确率可达 94.25%，同一测试中单独运行的 Jev 实验为 92.40%。
两项测试没有采用共同口径，结论便停在各自的限定词上：一个是单轮基准，一个只有 8 个案例。要让两个相反的读数收敛，需要覆盖更大样本、方法可复现的独立复测。