让 Agent 提前停下，能省掉一段最终失败的运行，也可能放弃一次本来会成功的尝试。本期最值得追问的，是怎样把这两件事放在同一张账上。StopLoss 用小模型读取行动记录，在离线回放中判断是否中止；它把监控费和保留下来的成功一起计入成本，让“少花了多少钱”有了交付结果这个分母。
SlopCodeBench 从另一端提出相似问题：给模型追加需求时，新增功能过关并不代表旧功能还在。严格通过与核心功能通过的巨大差距，提醒我们先说清成功的定义，再比较更多思考、更多调用是否值得。两条工作并不证明应该普遍少用计算；它们提供了检查资源究竟换来什么的具体方法。
沿着这条线读，可以先看 StopLoss 的停止机制与 SlopCodeBench 的连续任务，再看 DeepInfer 和 TorchTPU 怎样把计算核心变成可用的工程路径。后两项打开了新的硬件与实现选择，也留下缓存编排、编译和调试等实际工作。
最后两条从使用者出发：Simon 把个人游戏做到了能反复试玩，却被真实联机的高频音迫使改变方案；一位记忆工具使用者则建议先保留全文搜索基线，再判断复杂架构的增益。它们共同提醒我们，测试需要贴近想获得的结果，但各自的经历仍有明确范围。
当日材料
- DeepInfer 开放推理核心，完整服务仍有三块拼图
- TorchTPU：兼容 PyTorch 之后，性能来自整步编译
- StopLoss：小模型决定何时停下，账单必须算入误停
- SlopCodeBench：新功能通过，旧行为却未必保住
- Simon 做出了想玩的游戏，也碰到自动测试没听见的噪声
- 给 Agent 加记忆之前，先留下全文搜索这条基线