Cursor 在 7 月 22 日发布 Cursor Router 时，先给了一个很有意思的数字：约 60% 的 Cursor 开发者会选定一个模型，把它当作 daily driver。
这意味着改 typo、重命名字段、补单元测试和处理复杂架构问题，可能都在调用同一档模型。大量常规任务按 frontier 价格结算，但输出质量并没有同比增长。
我觉得这不是开发者不会选模型，而是供应侧错配。模型池越来越大，却仍让用户在每次任务前手动做调度。Cursor Router 要修的正是这一层：在模型运行前，由 IDE 判断任务该交给谁。
Cursor Router 是怎么动的
Cursor Router 本质上是一个分类器。它读取 query、context、task complexity 和 domain，再结合不同模型的行为，把简单工作交给价格效率更高的模型，把 UI 更新交给更有 “taste” 的模型，把长链复杂问题交给 frontier reasoning model。
Cursor 用 60 万条以上的真实请求训练 Router，并在数百万条线上请求中做 A/B 测试，优化目标是用户满意度 AFC，也就是输出是否被接受并继续使用。
缓存感知是其中容易被低估的一环。切换模型会造成 cache miss，所以 Cursor 的训练数据包含了由路由引发的 cache miss，生产评估也把这部分成本算进结果。它不是先假设缓存永远命中，再给出一张漂亮的降本图表。
三个 mode，以及真正该看的 cost per commit
Cursor Router 提供三种模式：
- Intelligence：优先保留高质量和复杂任务能力。
- Balance：在满意度与成本之间取中间点。
- Cost：进一步压低推理支出。
真正有说服力的不是 cost per request，而是 cost per commit：
| 模型或模式 | Cost per commit |
|---|---|
| Cursor Router Intelligence | $6.76 |
| Cursor Router Balance | $4.63 |
| Fable 5 | $12.69 |
| Opus 4.8 | $7.34 |
Intelligence 的用户满意度接近 Fable 5，但每个 commit 便宜约 47%；Balance 比 Opus 4.8 便宜约 37%，满意度还略高。Opus 4.8 的每 commit 成本比 Intelligence 高约 9%。
GPT-5.6 Sol 的成本与 Intelligence 接近，但用户满意度更低。另一组对比中，Balance 又能以更低支出取得与 GPT-5.6 Sol 相近的满意度。这说明 Router 的价值不只是挑便宜模型，而是把质量、任务类型和实际产出放在一起优化。
为什么选 Online A/B，而不是 Offline eval
Cursor 明确选择大型线上 A/B 测试，而不是把 offline eval 当作主要证据。原因有三个：
- Offline eval 通常不会计算切换模型带来的 cache-miss 成本。
- 真实路由发生在跨 session 的对话里，既要决定选哪个模型，也要决定什么时候切换。
- Coding Agent 的"任务完成"很难压缩成一个稳定 rubric。
在 early access 阶段，三个高流量企业账户、数千名用户的真实流量，相比全部使用 Opus 4.8 节省了 30% 到 50%，同时没有出现质量下降。这个生产数字比单一 benchmark 更接近团队真正要付的账单。
不只是 Router：dynamic tool calling 与 model pool
Cursor Router 只是 token-efficiency 战略的一部分。另一项并行优化是 dynamic tool calling：不再把所有原生工具描述塞进每个 prompt，而是在模型第一次需要某个工具时才加载，MCP 也采用类似模式。
这会让 read、edit 等高频工具保持可用，同时避免低频工具长期占据上下文。模型路由是在减少"用错模型"的浪费，动态工具调用是在减少"带错 prompt"的浪费。
Cursor 还在扩展可路由的模型池。Grok 4.5 面向更困难、成本更高的任务，Composer 则继续承担 everyday path。Router 越了解模型之间的差异，模型池扩张带来的就越可能是效率，而不是选择焦虑。
对 builder 意味着什么
多模型时代，routing 最终会进入 IDE 和 Agent harness，而不是停留在一张供用户手动选择的下拉菜单里。
真正的优化对象也不再只是模型价格，而是整条执行路径：给模型多少上下文、何时加载工具、能否复用缓存、什么时候切换模型，以及最终能否形成被接受的 commit。
这与我在 Codex 移动端与远程 Coding Agent 里讨论的变化相呼应。Coding Agent 正在从一个模型入口变成持续运行的工程系统，而系统一旦跨设备、跨 session、跨模型，调度层就不可能长期缺席。