Asana 的案例里，最有意思的地方不是标题中的倍数，而是一个违反直觉的结果：每轮删除旧截图、缩短历史，可能让调用更贵。原因是修改了前面的内容，后续请求不能继续复用原来的缓存前缀；改成分批清理，则能在多轮之间保留可复用的历史。[1][5] 在这套系统中，账单既与输入有多长有关，也与相邻两次输入有多少内容没变有关。
这使 Lynch 对自动模型分工的期待多了一层需要验证的条件。他不想为了简单子任务一直支付最强模型的价格，也不想自己负责拆解和切换。[2] 这个需求合理，但“把简单问题交给便宜模型”还不是完整的成本方案。接手的模型需要知道什么，前一个模型留下的结论能否检查，失败之后由谁接着做，都会改变最终账单。
2024 年的 RouteLLM 已经研究过按请求选择模型。除了省钱结果，值得留意的是它的分布变化：只用 Arena 偏好数据训练的路由器，在 MMLU 上表现接近随机路由；加入该领域的数据后才明显改善。[4] 这提示我们，判断任务难度也需要合适的经验。“这个请求看起来短”与“便宜模型能可靠完成它”之间，并没有现成的等号。
TokenRouter 讨论的是更细的 token 级路由，不能直接当作上述任务分工的实现。它把注意力放在切换后的异步执行与批处理，说明路由策略之外还有运行时调度问题。[3] 把这几份材料放在一起，我的推断是：选择模型时，除了下一步的能力和价格，还应考虑继续使用当前状态的价值。一个略贵但已有可复用上下文的选择，可能比便宜却需要重新铺垫的选择更合算；具体能否成立，要看服务的缓存规则和任务轨迹。
不过，“少切换”也不该变成新的口号。沿用当前模型可能延续一个已经错误的思路，过长历史可能干扰判断，重新整理上下文有时恰好能减少返工。真正要比较的是切换的增量收益与增量代价：它有没有提高最终完成率、减少后续尝试，代价又有多少来自重新输入、生成、排队和验证。只数调用次数，会把这些效果压成同一个数字。
我会把后续实验的核算单位定为一批原先就确定好的任务，而不是事后挑出的成功请求。分别比较固定模型、按子任务路由，以及把缓存与近期失败记录纳入决策的路由；保持验收要求和时限一致，报告整批总费用、完成率、等待时长，再给出每个合格结果分摊的费用。失败任务消耗的预算仍留在总费用里，否则最容易失败的方案反而可能显得便宜。
还需要看组合效果。可以把稳定前缀策略和模型路由分别打开、关闭，观察四种设置：两项优化是否互相促进，还是其中一项把另一项赖以成立的条件破坏了。今天的几份材料还没有回答这个组合问题。它比“多模型一定省钱”更值得追踪，也可能为路由器提供一个更实际的目标：不要只预测下一次回答的质量，要预测这一步会给后续任务留下什么成本。
另一种解释
上述材料涉及浏览器任务、按请求路由和 token 级路由，粒度不同，收益不能相加。短小、独立、容易核验的请求可能几乎没有状态交接成本，简单路由就已经够用。
接下来观察什么
后续优先寻找包含连续任务轨迹、缓存命中、失败重试和最终验收的公开测量；如果只报告单次生成成本或解码吞吐量，就不能用来确认整个任务更便宜。