OpenRouter 已上线 Jev Router，把 TypeSafe 的 Jev 接入模型路由。
按照 OpenRouter 的介绍，每轮请求发出前，Jev 会先判断任务难度、精度要求，以及当前模型和推理档位是否够用，再决定是继续沿用、提高推理强度，还是切换到另一款模型。
路由逻辑从任务分类扩展到逐轮难度判断
OpenRouter 原有的 Auto Router，更偏向按任务类型选择模型。它会先判断请求属于什么任务，再参考过去 7 天同类请求中各模型的使用情况来完成路由。
Jev Router 则会继续判断这一轮请求本身到底有多难。对于简单任务，系统可以降低档位；遇到更难的问题，则可以提高 reasoning effort。如果同一款模型仍然能够完成任务，系统不会急于切换模型。
长对话切换模型时，缓存损失也会被计入
OpenRouter 提到，模型切换还涉及一个实际问题：上下文缓存。
在长对话中，一旦更换模型，已经缓存的上下文通常无法直接复用，新模型可能需要重新处理整段聊天记录。Jev Router 会把这部分损失一并纳入计算。OpenRouter 表示，只有当换模型带来的预期收益高于切换成本时，系统才会真正执行切换；在同一模型还能处理请求的情况下，也会尽量继续沿用。
OpenRouter披露的自测结果
OpenRouter 自测称，在 4 项 Agent benchmark、共 423 个任务中，Jev Router 完成了 237 个，Auto Router 完成了 130 个，多解决约 82% 的任务。
在另外 5 项 Agent benchmark 中，Jev Router 的首 token 中位延迟也低于参与测试的其他路由器。
类似做法此前已出现在 Jev 社区
类似思路此前已经在 Jev 社区出现。比如，gholtzap/jev-codex-model-and-effort-router 会先让 Jev 为 Codex 选择模型和推理档位，再把整条线程固定下来以复用缓存；Jev-Auto-Router 则尝试在每次调用时重新选择模型。
OpenRouter 这次则把这类做法直接整合进了官方路由服务。