OpenRouter 10 月 28 日发布博客，称这是其成立以来对供应商路由算法最大的一次改动。旧算法的逻辑很单一：平台上约 77% 的请求所调用的模型由多家供应商同时提供，默认路由几乎只按输入 token 价格排序，谁便宜谁拿流量，失败再回退到次便宜的一家。后果是「便宜但慢」的供应商也能拿到大量流量，供应商唯一的竞争手段是降价，甚至出现压低输入价、抬高缓存价与输出价的定价组合来维持份额。

新算法算的是「一次成功回答要花多少钱」

新路由为每个端点实时计算 Routing Cost，由三部分组成：有效价格（按近期真实流量测得的缓存命中率与输入输出 token 配比折算，而非标价）、等待时间（TTFT 单独计权，吞吐按每模型设定的换算率折算成钱）、重试的期望成本（供应商错误率、HTTP 429 限流率、以及工具调用格式是否合规等质量信号）。如果一个供应商五次里失败一次，就要按 1.25 次付费来算。

实验结果

由于路由改动无法用常规 A/B 测试隔离（旧算法分到的流量会因新算法避让而变快，污染对照），团队采用 switchback 设计：每天切成 3 小时区块，新旧算法成对轮换，每次切换留 1 小时预热数据丢弃，跑满一周，共切分 2400 万次请求、1030 亿输入 token。结果：TTFT p50 由 1007ms 降至 837ms（降 16.9%），p95 降 18.9%；吞吐 p50 由 62.4 升至 72.6 tok/s（升 16.3%）；命中至少一次 429 的比例由 7.1% 降至 3.8%（减少 46%）；需要重试的请求由 10.4% 降至 6.9%（减少 34%）；代价是每千次请求成本由 1.25 美元升至 1.32 美元（升 6.0%）。

对自动化流程的影响

这次改动不需要改一行代码，对定时任务和智能体链路是净收益——429 少了近一半，意味着批量任务因限流失败重跑的概率明显下降。但有两点要留意：一是成本会小幅上升，按 token 计费的批量任务应重新核一次单价；二是显式设置了 provider.order 或 provider.sort 的请求会绕过新算法，想继续走纯低价可设 provider.sort 为 price 或在模型名后加 :floor。另外会话只在首个请求时选路，之后固定在同一供应商以保住缓存，长对话不会中途换供应商。