同一个 agent 任务跑两遍，API 账单能差 30 倍。而这30 倍不是噪声，是可以提前算出来的——只要你不指望它在开跑前算得准。
先把机制说清楚。agent 每走一步都可能触发新的模型调用，而前几步留下的上下文，会变成后面每一次调用的输入。早一步多生成一段话，后面十次调用各多一段。上下文不是一次性支出，是复利债务。
【直引】TokenCast 的做法是给每段执行记三个数：自己花掉多少、上下文增长多少、起点偏移多少。组合公式里最关键的是第三项——后面每段都要把前面段引入的上下文重读一遍，这项就是重读税。一段话总结：你早期欠下的上下文，后面每次调用都在替你还利息。
预测器本体出乎意料地朴素：LightGBM。单次推理 0.8 毫秒，全管线一次任务累计 32.8 毫秒，不花一分钱 API 调用。我用树模型预测大模型的花销——我算了一下，32.8 毫秒里塞了 41 次 0.8 毫秒的推理。这件事本身值得想一下：agent 怎么花钱，是可学习的。
现在说最要紧的那处。素材说"MAE 降 14.5%"，数字对，但它是四个时点的平均，而这个平均把最关键的那个格子藏起来了。
我把这四个数摆出来自己算了一遍：任务开跑前 −2.2%，每次调用开始 +1.9%，生成中滚动更新 +30.4%，任务中途更新 +27.8%。四者相加除四，正好 14.5%。
于是结论很清楚：事前预测它不赢，执行中修正它大赢。而付账单的人恰恰最想要事前预测。 任务开跑前那一格是负的——比最强基线还倒输。跑分格输，日用格赢，跟"跑分是断言、日用是执行"是同构的成本版。
第二处限定：21.3% 有两个限定词。一是离线回放，288 个 GPT-5.4 轨迹、七档预算做停止规则实验，不是线上真实干预；二是论文自己在脚注里写明"回放不测任务是否真正解决"——素材说的"完全不牺牲任务完成率"，其中的"完成"是到达记录终点，不是把问题做对。主动把这些预测接进运行时做实时干预，论文原话是 future work。
第三处：32.8 毫秒是一次任务全程累计，不是单次响应延迟。说毫秒级没错，但不是"每步都快"，是"整场便宜"。
还有一组数字帖子没提，我觉得比14.5% 有意思。论文的区间可靠性那段：在标称 90% 水平下，Task Start 时TokenCast 覆盖 82.0%，而 Self-Prediction 只覆盖 52.7%。同时 TokenCast 的校准区间让区间分数相对原生的降 32.0%。
【判断】这两件事放一起才有意义：预测难不准，但可以把不准的边界画准。一个覆盖 82% 的 90% 区间，比一个覆盖 52.7% 的 90% 区间在生产里有用得多——你不需要知道要花多少钱，你需要知道"超过这个数我就该叫停了"。最便宜的控制，是提前知道自己会在哪儿撞墙。
还有一个特征分析的细节值得单拎：有用证据在运行中会换人。开跑前和调用开始时是"请求长度"领先（相对重要性 0.24 和 0.30），生成中变成"已提交的前缀长度"主导（0.58），一次调用结束后则是上一次调用的输入 token、剩余计划项、无进展的调用数三者接近（0.28、0.25、0.23）。
【推论】这意味着不存在一个全程通用的成本特征。任何只盯着开头几个 token 做静态预算的方案，都在拿生成中那 58% 的主导因素当噪音。
下一根钉子：论文同时报了 LongBench-v2 上 MAE 32.2k 对应 WAPE 4.2%、MMLU-Pro 上 MAE 8.0k 对应 WAPE 15.8%——同样是"预测得挺准"，两个任务的相对误差差了近四倍，只因为平均消耗是 771.2k 对 50.6k。报token 成本预测的论文该报相对误差，纯绝对误差是跨任务不可比的。