Jev Router登顶背后：118次调用117次指向GPT-6.1 Sol

一个路由模型在基准测试中拿下第一，但它的118次调用里有117次都交给了同一个模型——这个模型自己单独参赛时只排第三。这不是魔术，而是一个关于基准测试、路由机制和统计噪声的清醒故事。

事件复盘：第一名和第三名是同一件事

TypeSafe 的 Jev Router（OpenRouter 上的 typesafe/jev-router）在 Forge 2.0 智能体编程基准上登顶，两次构建得分 0.6398 和 0.8523，中位数 0.746，领先 Claude Opus 5.5 的 0.6745。但 OpenRouter 的生成记录显示：118 次调用中 117 次交给了 GPT-6.1 Sol，仅 1 次给了 GPT-6 Astra。而 GPT-6.1 Sol 自己两次构建的中位数只有 0.5933，排在第三。

换句话说，冠军是通过路由器调用季军模型得到的。这听起来像漏洞，但更准确地说，它暴露了「路由」这一层在基准测试中几乎不可测量的部分。

GPT-6.1 Sol 与 GPT-6 Astra：文中反复出现的这两个模型是理解整个事件的关键。Sol 和 Astra 是同一代 GPT-6 系列下的不同变体，定位不同——Sol 偏向通用代理与长上下文任务，Astra 则可能在特定能力或定价上有差异。Jev Router 在 118 次调用中几乎全部选择了 Sol，唯一一次切换到 Astra 的调用就产生了 1.80 美元的单次账单，占构建 1 总花费的 44.87%。这说明路由器的选择不是随机的，而是基于某种决策逻辑，但当任务高度同质时，这种逻辑会退化为「总是选同一个」，使得路由器的表现本质上等同于被选模型本身的表现。

路由器的本质：不写一个字，只做选择题

Jev 不是大语言模型。据 OpenRouter 文档，Jev 是 TypeSafe 的 System One 决策模型，只返回带概率的类型化答案，不产出文本、推理或解释。Jev Router 用它来为每个请求选择模型和推理强度，被选中的模型负责生成回答，费用按该模型的单价结算。

这与学术界对路由器的定义一致。LMSYS 的 RouteLLM 论文将其描述为在强模型和弱模型之间动态切换、以优化成本与质量平衡的策略；RouterBench 的前提是「没有单一模型能最优处理所有任务」；RouterEval 甚至发现优秀路由器可以「超越池中最好的单模型」。问题在于，当池子里只有几个模型、任务又高度同质时，路由器很容易退化成「总是选同一个」。

RouteLLM、RouterBench 与 RouterEval：这三个是路由研究领域的代表性工作，构成了理解 Jev Router 的学术背景。RouteLLM 由 LMSYS 提出，核心思路是在强模型和弱模型之间动态切换，以在成本和质量之间取得平衡；RouterBench 是一个标准化基准，其前提是「没有单一模型能最优处理所有任务」；RouterEval 则进一步发现，优秀的路由器可以「超越池中最好的单模型」。这些研究共同定义了路由器的价值主张：通过智能选择实现成本优化或质量提升。但它们的实验设置通常包含多个能力差异明显的模型和多样化的任务类型，而 Jev Router 在 Forge 2.0 上的表现恰恰缺少这两个条件——池子小、任务同质，导致路由器退化为「总是选同一个」，这正是学术定义与工程现实之间的落差。

数据揭示了什么：117/118 意味着路由器几乎没在路由

两个 Jev 构建共 120 个生成 ID（118 次路由调用加 2 次 goose 自身的 Gemini 2.5 Flash 辅助调用）。逐个查询 OpenRouter 的 /api/v1/generation 端点后发现：

• 构建 1：74 次 Sol，1 次 Astra，1 次 Gemini Flash，得分 0.6398，花费 4.02 美元
• 构建 2：43 次 Sol，1 次 Gemini Flash，得分 0.8523，花费 1.15 美元

唯一那次 Astra 调用占了构建 1 总账单的 44.87%。它携带 142,694 token 的提示、零缓存命中，单次花费 1.80 美元，而同一构建中 74 次 Sol 调用合计才 2.22 美元。这验证了 OpenRouter 自己警告过的成本陷阱：切换模型意味着输入缓存重建，长上下文代理任务中一次切换就能吞掉大块预算。

需要注意，这只是「我们的任务」上的表现。OpenRouter 的模型页显示，在所有流量中 DeepSeek^广告 V4.1 Flash 约占 36% 的 token，Sol 约 18%。在长上下文 Forge 构建中路由器几乎只选 Sol，并不代表它在混合流量中也会如此。

基准测试的结构性问题：两个构建分不清路由器和模型

Forge 2.0 要求每个模型跑两次独立构建，按中位数排名。但单个模型的两次构建差距中位数就有 0.0832，Jev 自己两次差了 0.2125，同组的 Gemini 4 Argon 两次构建甚至相差 0.4983（0.7926 对 0.2943）。在这样的噪声下，0.1527 的中位数领先并不牢靠。

更关键的是比较组。Jev Router 和 Gemini 4 Argon 同属比较组 1，Opus 和 Sol 属比较组 2。榜单自己写着「在同一比较组内比较模型」。跨组对比 Jev 和 Sol，按作者自己的规则并不公平。Jev 的构建跑在 goose 3.0.116 上，Sol 的构建跑在 3.0.110 上，两者间隔 73 个提交。虽然首次请求的工具集和系统提示一致，但引擎差异本身就是一个变量。

此外，Jev 的低分构建 0.6398 与 Sol 的高分构建 0.6495 仅差 0.0097。按照作者自己的比较工具 forge2_compare.py 的规则——只有当一方所有构建都超过另一方所有构建时才算分出胜负——这对组合应判为「未解决」。

比较组与中位数排名：Forge 2.0 采用「每个模型跑两次独立构建、按中位数排名」的机制，并将模型划分到不同的比较组中，榜单明确要求「在同一比较组内比较模型」。Jev Router 和 Gemini 4 Argon 同属比较组 1，而 Claude Opus 5.5 和 GPT-6.1 Sol 属比较组 2。跨组对比 Jev 和 Sol，按榜单自身规则并不公平。更关键的是，单个模型的两次构建差距中位数就有 0.0832，Jev 自己两次差了 0.2125，同组的 Gemini 4 Argon 两次甚至相差 0.4983。在这样的噪声水平下，0.1527 的中位数领先并不牢靠——它小于 Jev 自身两次构建的差距，意味着排名结论在统计上无法支撑。

一个无法证实的假设：路由器可能调高了推理强度

Goose 在所有构建中都发送 reasoning: {effort: "medium"}，但 OpenRouter 文档明确说，经过 Jev Router 时这只是建议而非保证。生成记录的 45 个字段里没有 effort 信息，但 native_tokens_reasoning 透露了线索：直接调用 Sol 时，95 次调用中推理 token 从未超过 516；经路由后，构建 1 的 74 次 Sol 调用中有 19 次超过 516，最高达 3,327。

这与路由器调高推理强度的假设一致，但也可能是其他尚未排除的因素。作者建议：如果你在自己的代理中使用路由器，务必发送 X-OpenRouter-Metadata: enabled 请求头，它会在响应中列出候选模型及其 effort 和路由理由。

推理强度（reasoning effort）与 native_tokens_reasoning：推理强度是 OpenAI 等模型提供商引入的一个参数，控制模型在生成回答前进行内部推理的 token 预算，通常分为 low、medium、high 等档位。Goose 在所有构建中都发送 reasoning: {effort: "medium"}，但 OpenRouter 文档明确说，经过 Jev Router 时这只是建议而非保证——路由器可能覆盖这个设置。生成记录的 45 个字段里没有 effort 信息，但 native_tokens_reasoning 字段透露了线索：直接调用 Sol 时，95 次调用中推理 token 从未超过 516；经路由后，构建 1 的 74 次 Sol 调用中有 19 次超过 516，最高达 3,327。这与路由器调高推理强度的假设一致，但也可能是其他尚未排除的因素。作者建议发送 X-OpenRouter-Metadata: enabled 请求头，它会在响应中列出候选模型及其 effort 和路由理由，从而验证这一假设。

逐项检查：Jev 赢在哪三个检查上

Forge 2.0 的得分是「测试得分」乘以「可靠性系数」。可靠性系数对 19 组测试中每组的最差表现进行惩罚：最差测试完全失败则该组乘以 0.90。Jev 两次构建的测试得分分别为 0.9409 和 0.9856，Sol 为 0.9498 和 0.9383——平均检查层面几乎打平。差距来自可靠性：Jev 为 0.68 和 0.8647，Sol 为 0.6838 和 0.5724。

有三个检查是 Jev 两次都赢、Sol 两次都没赢的：以用户身份按 Atlassian 文档格式发布冲刺评论、跟踪问题重新估算的事件管线、以及应用内 AI 解释按钮返回答案。其中两项 Sol 只是部分失分（0.8333 和 0.5），并非完全失败。没有任何一个检查是 Sol 两次都赢过 Jev 两次的。

Jev 自己的两次构建在 12 个检查上不一致，Sol 的两次在 22 个检查上不一致。构建 1 在某个种子站点上出现 47 次存储限制错误，构建 2 一次没有；构建 1 在 958 次面向用户的配额请求中拒绝了 1 次，构建 2 在 984 次中拒绝了 0 次。每个检查取三个种子站点中的最低分，一个坏站点就能拖垮整个构建。

成本对比：路由没有额外费用，但有切换风险

Claude Opus 5.5 两次构建账单 42.50 美元，中位数 0.6745；Jev Router 花 5.17 美元拿到 0.746；Sol 自己花 2.38 美元拿到 0.5933。Jev 每次调用成本（0.0536 和 0.0268 美元）高于直接调用 Sol（0.0245 和 0.0256 美元），主要差在那次 Astra 切换上。

路由本身不收费，但它引入了切换风险。去掉 Astra 调用后，构建 1 的 74 次 Sol 调用每次 0.0299 美元，仍然略高于直接调用。换句话说，在这个任务上，路由带来的成本优势并不存在。

如何自己验证路由器的真实行为

作者给出了可操作的检查步骤：保留每次调用的 generation id；用 GET https://openrouter.ai/api/v1/generation?id=<id> 查询 model 和 router 字段；统计模型分布——如果某个模型承担了几乎所有调用，就把路由器的结果和该模型直接调用的结果在同一测试框架、同一版本、同一周内对比；发送 X-OpenRouter-Metadata: enabled 查看推理强度和路由理由。

判断标准也很直接：当路由器的领先幅度小于它自己两次构建之间的差距时，排序就不可信。Jev 领先 Sol 中位数 0.1527，而它自己两次构建差 0.2125。

结论：想要的到底是路由，还是那个模型

如果目标是 GPT-6.1 Sol 在这类长代理任务上的表现，直接调用 Sol 能得到同样的模型，还免去切换风险，代价是放弃路由器可能带来（也可能没有）的推理强度调整。如果目标是混合流量下的成本优化——那正是路由器设计的初衷——这个基准完全没有测试到。

TypeSafe 自己在关于基准测试的文章里写道：「跑你自己的私有评估，对公开结果持保留态度，不要放大你看到的每一个数字或图表。」这句话同样适用于这个榜单。

真正的下一步很明确：在同一个 goose 版本上，为 Jev 和 Sol 各跑第三、第四次构建，并开启元数据头。在那之前，第一名和第三名之间的距离，可能只是统计噪声的形状。