OpenRouter新增编程路由，按请求选模型

OpenRouter 在 2026 年 11 月 6 日推出重做的 Auto Router，以及面向编程任务的 Auto Code：每次请求都可以重新选择模型和推理强度。它想解决的是，简单任务用贵模型浪费，复杂任务用便宜模型又容易反复返工。

最吸引人的数字是：Auto Code 在五项基准上表现接近 Claude Opus 5.5，每任务成本低 74%。但这不是你的账单折扣承诺。对程序员更有参考价值的，是它如何把通过率、失败反馈和缓存损耗放进同一套决策。

两个路由器，优化的目标有什么不同

通用入口仍是 openrouter/auto，适合混合流量、应用和通用 Agent，倾向于选择成本较低的一档模型。入口名没变，现有调用者无需修改代码，就会使用新版路由逻辑。

新增的 openrouter/auto-code 面向编程 Agent 和执行框架，起步成本档位更高。它关注实测通过率、速度和每个成功任务的成本，对失败的惩罚也更重。

这个区别很实际。一次调用便宜，不代表完成任务便宜。如果模型连续改错、重复跑测试，省下的单次费用可能被重试吃掉。Auto Code 试图围绕「任务有没有完成」做选择，而不只看调用价格。

两者共用路由引擎，但默认取舍不同。原文没有披露通过率、速度和成本各占多大权重，也没有给出具体的失败惩罚公式。

每次请求重新选模型，为什么不会频繁切换

新版先用一次决策模型调用，评估请求的 11 个因素，包括任务类型、任务是否变化、难度、速度要求、视觉或代码库知识需求，以及更大模型、更多推理或更便宜模型是否合适，再结合实时价格、提供商健康状态和缓存状态决策。

整个请求分五步：

1. 根据约束缩小候选池，包括零数据保留要求、模型能力、提供商限制、BYOK 密钥及允许或排除的模型列表。
2. 由决策模型给请求评分。
3. 结合实时价格、缓存和基准表现，选择模型与推理强度。
4. 进入提供商路由，为选中的模型寻找服务提供商。
5. 把模型是否遇到困难、已有缓存等信号用于下一轮判断。

模型路由决定用谁，提供商路由决定由谁提供这个模型。

OpenRouter 的 600+ 个模型在加入平台当天都会进入考虑范围，但是否进入成本最优集合，还取决于基准和热度信号。进入候选范围，不代表会获得相同的调用机会。

另一个关键是缓存。更换模型后，新模型需要重新建立输入 token 缓存，因此路由器倾向于先调整推理强度，收益足够大时才切换模型。反复出现相同错误、修改后测试仍失败，会增加切换概率。

按 OpenRouter 的说法，接近九成 Agent 轮次会沿用同一个模型。这套机制考虑的是整段会话的代价，不只盯着当前一次请求。

74% 怎么看，接入又要改多少

OpenRouter 公布，新路由器在部分基准上最高达到旧版的 4 倍表现；路由步骤的 p90 延迟从 1.96s 降至 0.65s，约快 3 倍。这里缩短的是选模型的时间，并非整个任务的完成时间。

Auto Code 则在 Deep SWE、SWE-Atlas QA、Terminal Bench 4.0、tau-bench Banking、MMMU Pro Vision 五项基准上，得分与 Claude Opus 5.5 接近，每任务成本低 74%。

相对旧路由器的 beta 测试还报告：无效工具调用降至原来的四分之一，Agent 回复被截断的频率减半。平台给出的规模背景是，每月超过 10 万人通过 Auto Router 使用超过 2.5 万亿 tokens。

这些都是 OpenRouter 公布的数据。原文提到公开基准会定期重跑，但没有展开任务分布、执行框架和各项成绩，不能据此推算某个前端仓库能省多少。

接入方式很直接，下面的请求把模型设为 Auto Code，让它为指定函数增加退避重试：

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/auto-code",
    "messages": [{"role": "user", "content": "Add a retry with backoff to fetchUser in api/users.ts"}]
  }'

要看的是 "model": "openrouter/auto-code" 这一行：这里指定路由入口，响应的 model 字段才告诉你实际用了哪个模型。

平台不额外收路由费，按实际服务模型的标准价格计费。不过，新版刻意提高了默认成本取向，让更多能力较强的模型参与选择；想接近旧版偏低价的行为，可以把 cost_tier 设为 low。allowed_models、excluded_models 仍然有效，openrouter/auto-beta 用于提前接收路由更新。

可观察性也有补充：chatroom 的 routing insights 面板能展示任务分类、候选模型选择占比，以及难度、精度和大模型收益判断。API 开启 router metadata 也能获取分析，但原文没给出具体启用参数。模型页面则展示按会话类型、难度划分的实时模型使用分布。

我的判断

我认可它把缓存和失败成本纳入路由。对多轮编程任务，便宜模型反复失败，确实可能比一次用强模型更贵；只比较 token 单价，很容易选错优化目标。

但「会根据失败纠偏」依赖反馈质量。原文没有说清如何识别测试失败、如何区分模型问题与环境问题，也没交代执行框架需要传回哪些信号。不能仅凭换一个模型字符串，就认定自己的 Agent 已经具备可靠的自动纠错能力。

74% 应当作为开展对照测试的理由，不能直接写进成本预算。

固定模型的优势是行为更稳定、回归更容易；自动路由更适合任务差异大、又不想持续追踪模型发布的团队。如果工作已经稳定适配某个模型，切换未必划算。OpenRouter 自己也承认，没有路由器能在成本与质量曲线上的所有位置都胜过最佳前沿模型。

至于 Auto Code 是否比通用路由更适合你的编程框架，原文没有提供足够细的对照数据。它的优化方向有道理，实际收益仍需验证。

能拿来做什么

• 从现有编程任务里挑出小改动、测试修复和跨文件修改，用固定模型与 openrouter/auto-code 做对照，同时记录完成率、总费用、重试次数和耗时。
• 已在使用 openrouter/auto 的应用，可以先复查费用与质量变化；新版默认选择更贵，预算敏感时应明确设置 cost_tier，并用模型列表限制候选范围。
• 在日常 AI 编程调用日志里保留响应的 model 字段；需要解释选择原因时，再按文档启用 router metadata，避免只记录路由入口而无法定位变化。
• 对已有稳定模型方案的任务保留直接调用，把任务跨度较大的流量交给路由器试跑，依据自己的成功率和成本决定使用范围。