temper的弃置——为什么"开始前判断复杂度"这个思路走不通

temper是一个模型路由器。核心想法很简单：在Agent开始干活之前，先判断这个任务有多难，然后选对应的推理档位——简单问题用便宜档位，复杂问题用强档位。目的是省钱。

为什么会有这个想法

同一个模型（DeepSeek）不同推理档位，成本差好几倍，但能力提升越来越小。从minimal提到medium可能贵一倍但只多对了5%——大部分任务根本不需要那5%。如果能自动匹配档位，理论上省一大笔。

为什么走不通

三个原因，都是实践里撞出来的。

第一个是根本性的：temper假设能在对话开始前准确预判复杂度，但这个假设不成立。 对话是动态的，聊着聊着方向会变。你开始问个简单问题，后续可能引出复杂的架构讨论。temper在入口处的判断，管不了后面的走向。

第二个是技术约束：中途切换推理档位可能丢掉prefix cache。 DeepSeek的prefix cache存的是输入文本经过模型计算后的KV矩阵。不同推理档位在后端可能是不同实例，cache不互通。切换档位意味着已经积累的几千token前缀缓存全丢，重建成本可能超过省下来的推理费。同一个模型不同档位的cache是否兼容，取决于厂商后端实现，没法确定。

第三个是边际收益太小：用户日常用minimal/low就够了，temper能优化的空间几乎为零——已经是底档，只能往上调不能往下降。

真正的降本方向

temper想解决的问题是实在的，但解法不对。真正省钱的杠杆在其他地方：

减少重复的API调用。审查前移减少迭代轮次。给Codex的需求写得更精确让它少跑几轮。这些措施省下的token远比选模型档位多。

结论

temper弃置，项目保留不删。之后再想降本方向时，核心约束已经清楚了：不要在对话中间频繁切换模型或档位，prefix cache的隐性成本太大。降本应该从减少调用次数入手，而不是从降低每次调用的单价入手。