21.3% 这个数我自己复算了一遍，换个算法，它变成 19.6%。
一、14.5% 是四个预测点的均值，其中一个点是负数
分项是 Task Start −2.2%、Call Start +1.9%、In-call Update +30.4%、Task Update +27.8%，均值 14.475 ≈ 14.5，账能对上。但 96 个组合（4 套件 × 6 模型 × 4 预测点）里有 24 个输给最强比较器——15 个在 Task Start、9 个在 Call Start。任务刚起步时你什么都不知道，预测自然垫底。摘要里那个负号没有出现。
二、21.3% 是「百分比之均」，不是「均之比率」
七个预算档上的节省是 34.6 / 30.1 / 26.0 / 21.6 / 16.9 / 12.3 / 7.8，算术平均 21.33 ✓。但按总量口径复算：固定预算 215.09k 对 TokenCast 173.0k，省的是 19.6%。七行逐行闭合（Table 21 每行 Execution+Prediction=Total 都对），数据是真跑过的——只是挑了对自最有利的平均方式。
三、匹配的是「跑到底」，不是「解对」
七个预算档的轨迹完成率逐档全同（30.2% → 89.9%），匹配属实。但原文自己写了 the replay does not measure task resolution——省下的钱对应的是不是仍然解对的任务，一个字没提。更扎的是 EGTP：同样回放能省 44–81%，代价是完成率从 30.2% 掉到 13.5%。论文用「匹配完成率」把这个更强的对照排除在外，却没讨论这笔取舍划不划算。
四、32.8ms 是累积值，标准差跟它一样大
Table 15 写的是 32.8±30.5 ms，且只在「每次调用都刷新」的设置下成立（每 3 次调用是 11.9ms），只测了 SWE-bench Verified。好消息是开销占运行时长约 0.025%，这个可以放心。
五、三个种子、无检验、无 Limitations
全部 MAE 是三个随机种子的均值，无误差棒、无置信区间。结论也自己交代了：预测器从录制轨迹学出来，换新任务域或新模型要靠一小批目标任务；把预测接进运行时预算管理是 future work。
下一根钉子：给同一套回放加上任务成败标签，看 21.3% 还剩多少。若剩不到 10%，这方法的卖点就变成「省了一笔没人要的钱」。