OpenRouter 价格拆解：Jev Router 真的免费吗？

Jev Router 是 OpenRouter 托管的 typesafe/jev-router 端点，于 2026 年 9 月 25 日上线。它是一个聊天端点，会为对话的每一轮选择负责回答的模型。它与最初的 Jev 决策模型不是同一款产品，也不同于那个名称相近的开源 CLI 封装工具。

OpenRouter 价格核查：Jev Router 免费吗？

核查后的答案比绿色“免费”标签更有限：Jev Router 标示的提示词与补全 token 价格都是 $0，但其所选模型的总成本缺乏足够清晰的说明，因此不能断言每一次路由会话都免费。

本文于 2026 年 9 月 26 日核查了 Jev Router 实时页面。页面 FAQ 明确回答路由器免费，提示词与补全 token 均不收费；同时还标出了 1,000,000-token 上下文窗口，并说明这个单一端点会随着对话变化选择模型和推理强度。

不过，同一天的两项目录信息让我们无法给出更确定的结论。OpenRouter 公开的 Models API 为该路由器的提示词和补全价格返回了 -1，而不是常规的固定数值；其端点记录则没有返回任何提供商端点。这些机器字段并不能证明一定会收费，但也无法把页面上的 $0 标签变成逐项列明的会话账单。

本次发布环境没有可用的已授权 OpenRouter API key，也没有已登录的 OpenRouter 会话，因此没有发起可能计费的请求。也就是说，本文的结论背后没有实测的 usage.cost 或 Activity 记录。稳妥的预算做法是：把 $0 视为端点的标示价格；在向客户或财务团队承诺推理免费之前，再核实整次调用的实际账单。

9 月 25 日究竟发生了什么变化？

真正的变化是：Jev 从一个可用于自行搭建路由器的组件，变成了托管聊天端点内部的决策层。

Jev 1.13 是一款 System One 模型，它输出受约束的决策，而不是自然语言段落。应用需要提供状态，并请求一个带类型的 Choice、Score 或 yes/no Noul 问题。模型可以决定“使用强模型档位”，但真正调用该档位、保留对话并核算两次请求的工作，仍要由你的代码完成。

托管路由器把这套流程收进了 typesafe/jev-router。根据 OpenRouter 的上线帖，Jev 会在每一轮对提示词的难度与精确度打分，判断更大的模型或更高的推理强度是否有帮助，同时检查任务是否已经变化。随后，OpenRouter 将这一轮发送给所选模型，并返回其生成的文本。

开源项目 gargpratyush/jev-router 尤其容易与新端点混淆。该项目会启动真正的 Claude Code 或 Codex CLI，在每个新的对话轮次执行一次 Jev 决策，把结果映射到具体账号的模型档位，并沿用 CLI 现有的身份验证。它不是 OpenRouter 托管模型的 slug，计费路径也完全不同。

这一区别会直接改变实现方式。最初的 Jev 工作流提供的是决策原语；DIY 路由器则围绕编程订阅建立本地策略；托管端点只需一次 API 调用，最终文本由它选中的模型生成。

AI 模型路由器如何管理一段对话？

Jev Router 的设计目标，是避免仅因下一条消息看起来不同就切换模型。这一点很重要，因为模型一旦切换，可能丢失提供商已经缓存的对话，迫使新模型重新读取完整历史。

OpenRouter 表示，只要某个模型在当前会话中仍然胜任，路由器就会继续使用它；它可以在不切换模型的情况下提高或降低推理强度，只有当预期收益足以抵消缓存损失时才会换模型。做决定时，它会读取对话文本。上线帖还说明，附件不会发送给 Jev，同时支持使用 zdr: true 的请求。

这不只是逐条提示词分类。对于简单的追问，廉价模型可能继续工作，因为保留其缓存比切换更划算；遇到高难度轮次时，也可以提高推理强度，而无需承担把整段对话迁移到另一模型所带来的上下文重读成本。只有任务真的改变，路由器才会移动。

但生产环境中也多了一道风险墙。OpenRouter 表示，如果 Jev 决策超时或返回无效输出，请求会直接失败，而不是回退到其他路由器。单独的 DIY 项目则采用故障开放策略，会继续使用当前模型或备用模型。因此，选择托管端点意味着在关键路径上新增了一项依赖，而不只是增加一个价格优化器。

OpenRouter 价格中的 $0 包含什么，又不能证明什么？

$0 标价覆盖的内容就是 OpenRouter 明确公布的内容：Jev Router 页面上的提示词与补全价格。它没有逐项解释所选付费模型、推理 token、缓存读取、工具和充值费用最终如何计入这笔价格。

OpenRouter 的通用计费规则称，普通请求按所选模型与提供商的费率收费；新的 Jev 页面则称路由器免费。两个来源都没有明确说明：托管端点是否会暂时补贴所选模型、是否把推理费作为单独账项转嫁，或是否采用其他上线期安排。直接套用普通 Auto Router 规则只是一种假设；宣称所有付费模型的推理都免费，同样也是假设。

第一项事实依据是响应本身。OpenRouter 的用量核算文档称，每个响应都包含提示词、补全、推理、缓存 token 和成本信息。usage.cost 是该账号被收取的总金额，响应中的 model 字段则标明实际回答的模型。

第二项依据是生成记录。OpenRouter Logs 会显示模型、提供商、成本、token 数量、延迟、缓存折扣、BYOK 成本，以及网页搜索、网页抓取或文件处理的费用。汇总后的 Activity 面板还会展示支出、请求数、token 类型与缓存命中率，并可按模型、提供商、key、应用或用户筛选。

每一项争议成本都有对应的核查位置：

• 所选模型： 将返回的 model 与 usage.cost、生成记录中的 total_cost 对照。
• 推理： 保存 completion_tokens_details.reasoning_tokens，以及该轮次的路由说明。
• 缓存复用： 保存 prompt_tokens_details.cached_tokens，再到生成详情中确认是否有缓存折扣。
• 工具： 基线测试先不启用工具；上线前再读取工具对应的独立生成账项。
• 充值费： 单独分摊购买手续费。OpenRouter 当前 FAQ列出的费率是：银行卡充值 5.5%，最低 $0.80；加密货币充值 5%。这是充值手续费，不能用来证明 Jev Router 存在附加费。

账算清楚：路由决策免费，不等于会话免费

路由决策这一项本来就很便宜。真正影响经济性的，是 Jev 能否选到合适的模型、保住有价值的缓存，并产出可以直接采用的结果。

先看旧的显式决策路径。Jev 1.13 的输入价格为每百万 token $0.042，输出价格为每百万 token $0。假设每次路由决策需要 500 个输入 token，总计 100,000 个轮次，那么 Jev 输入量为 50 million token，决策层成本是 $2.10。每轮真正作答的生成模型还要另外计费。

按托管页面的标示费率，同样的路由成本是 $0。因此，在这个工作负载下，表面上每 100,000 次决策可节省 $2.10。这笔节省有价值，却不足以单独决定产品选择。一次糟糕的模型切换，其影响可能大过数千次 Jev 决策。

假设一段对话已有 20,000 个提示词 token，所选模型的示例输入价格为每百万 token $2。换用新模型后，仅重新读取历史就要花费 $0.04，这还没有计算缓存折扣或新输出。53 次不必要的切换会花费 $2.12，已经略高于前述 100,000 轮示例中的全部 Jev 1.13 决策费用。

这正是会话感知型路由器更持久的成本价值：保住正确的缓存，可能比让路由分类器免费更重要。这是一段明确标注的情景计算，并不是在声称 Jev Router 一定会选择价格为 $2 的模型，或一定能避免 53 次切换。

性能证据值得关注，但尚不完整。OpenRouter 报告称，在 4 项智能体基准测试中，Jev Router 在 423 项任务里完成了 237 项，而 Auto Router 为 130 项，前者多 82%。它还称，在 5 项智能体基准测试中，Jev Router 的首 token 时间中位数快于参与测试的其他所有路由器。这些都是厂商结果，并非独立复现。

Theo Browne 在一份 9 月 26 日的基准测试报告中提供了有价值的反向参照。他表示自己花了 $1,000，测得 DeepSWE 的表现与低推理强度下的 GPT-6 Astra 大致相当，价格略高，等待时间则接近后者的 5 倍。这是带有明确出处的基准结果，不代表路由费高达 $1,000；帖子也没有公开足够的逐请求计费数据，无法据此解决本文讨论的成本问题。

对采购方而言，最终仍应看每项被接受任务的成本：

(selected-model cost + tools + allocated funding fee + retries + review time) / accepted tasks

$0 的路由成本可以改善这个分子，却不会让等式中的其他部分消失。

对开发者、运营团队和采购方分别意味着什么？

开发者获得了更简单的集成，也接受了更关键的依赖。 一个兼容 OpenAI 的模型 slug，可以替代自建分类器、策略表、模型调用和部分会话逻辑。代价是路由器会挡在每一次回答之前。面对文档所述的故障关闭行为，应用层必须预设 Jev 失败后的处理方式，例如重试一次、请用户再次尝试，或按照自己的策略明确调用固定模型。

最低限度的有效日志应包含：响应 ID、请求的 slug、所选模型、路由原因、推理强度、提示词 token、缓存 token、补全 token、推理 token、usage.cost、延迟和结果。缺少这些字段时，模型切换看起来会像毫无规律的价格波动，质量退化也容易被误判成智能体故障。

运营团队应该按会话管理，而不是盯着 token 单价标签。 一段客服副驾、研究智能体或编程工作流的对话里，可能同时包含简单轮次、困难轮次和任务转向。真正有价值的行为是：只有困难轮次值得时才增加开销，不值得切换时则保留缓存。应把可接受任务数、重试、人工修正和会话总成本放在一起衡量。

采购方应该在预算表中拆分推理、路由和充值。 端点标示的 $0 应记在路由一栏；实际观察后，所选模型的总成本记在用量一栏；搜索、抓取、文件处理等工具各自单列；5.5% 的银行卡手续费属于点数充值成本，不是虚构的逐请求加价。

如果要了解更完整的平台账单，现有的 OpenRouter 价格分析涵盖共享点数、BYOK 和充值费用。若要了解最初的决策模型工作流，可阅读 Jev 使用指南，其中介绍了带类型的工单路由和 Jev 1.13 的 $0.042/M 费率。

谁适合现在行动，谁应该等待，谁几乎不受影响？

如果你的智能体工作流边界清晰、可随时回退，能把评估支出限制在 $1 以内，并且已经记录每一次生成，那么可以现在行动。非关键编程任务、内部研究循环或影子模式的客服助手，都是合理的评估场景。目标不是证明路由看起来有多聪明，而是在相同提示词上，把每项被接受任务的成本和延迟与固定模型进行对比。

以下情况更适合等待：面向客户的请求无法容忍新增的故障关闭依赖；财务团队要求先取得正式计费规则，再启用任何可变路由；或提示词含有尚未通过隐私审查的受监管数据。支持零数据保留固然有用，却不能取代你自己的数据流审批。

如果一个固定模型已经达到质量与延迟目标；如果工作负载只是适合交给 Jev 1.13 的狭窄带类型决策；或如果你明确选择通过本地 DIY 项目路由 Claude Code 和 Codex 订阅，那么此变化基本与你无关。托管路由器并不会天然优于稳定的直接调用。

如果确定性提供商控制比自适应选择更重要，先比较这些用于多模型路由的 OpenRouter 替代方案，再决定是否迁移关键路径。

“Jev Router 免费”这句话被夸大了什么？

最夸张的说法，是把一张 $0 模型卡等同于整个模型生态都免费。OpenRouter 尚未公布足够的 Jev 专属计费细节，无法支持这一结论；公开的机器目录也没有显示常规的固定路由。

反方向的夸大也同样站不住脚：不能因为信息不完整，就断言一定存在隐藏的路由附加费。本次核查既没有找到相关说明，也没有实测到这类附加费。把它擅自加入预算预测，就是编造。

基准测试也需要放回恰当的比例中看。OpenRouter 所谓任务完成数高出 82% 的结论，是厂商拿自己的 Jev Router 与自己的 Auto Router 对比得出的；Theo 花费 $1,000 的 DeepSWE 报告，则是一位从业者针对一种固定模型设置做的单项测试。两者都无法告诉你自己的智能体每项被接受任务要花多少钱，也不能取代一次简短的账号级账单核对。

最后，1,000,000-token 上下文窗口并不等于百万 token 对话一定经济。长会话是否高效，取决于所选模型、缓存行为、推理强度和任务变化。上下文上限代表容量，不代表预算。

周一就能完成的四请求成本核查

4 个小型合成请求，能比继续解读一周价格页面提供更多确定信息。关闭工具，不使用私密数据，要求简短输出；如果累计 usage.cost 接近 $1，就立即停止。

第一次请求可以直接使用以下格式：

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -H "X-OpenRouter-Metadata: enabled" \
  -d '{
    "model": "typesafe/jev-router",
    "messages": [
      {"role": "user", "content": "Return only the word READY."}
    ]
  }' | tee jev-router-response.json

然后使用响应 ID 获取对应的生成元数据：

GENERATION_ID=$(jq -r '.id' jev-router-response.json)
curl --get https://openrouter.ai/api/v1/generation \
  --data-urlencode "id=$GENERATION_ID" \
  -H "Authorization: Bearer $OPENROUTER_API_KEY"

判定规则很机械：

• 如果 4 个响应都显示 usage.cost: 0，4 条生成记录的总成本也都是零，并且同一个 key 的 Activity 视图没有新增支出，那么你已经在该账号、该日期实测到一次零成本的合成会话。
• 如果任何记录不是零，就依据其中的所选模型与成本明细处理。无论目录标签如何，该请求从端到端都不是免费的。
• 如果响应、生成记录和 Activity 互相矛盾，不要外推。保存相关 ID，并请 OpenRouter 支持团队确认哪一条记录决定实际账单。

基线对账完成前，不要添加工具。将搜索、抓取或文件处理接入智能体后，再重复一次受控请求，并把这些生成账项视为独立成本；不要从 Jev Router 模型卡推断它们的费用。

周一要做的，就是把这 4 个请求与 4 个固定模型对照请求并排运行，然后比较会话成本、延迟、可接受输出和失败率。只有路由决策改善了这组完整结果，才应采用 Jev Router；不能仅仅因为目录里出现了两个零就上线。

通过邮件通讯获取下一次经核实的模型路由变化及其预算影响。