Context Mode 的仓库把一组工具输出压到很小，当前网站又给出成对任务费用估算。[1][2] 前一个数字测量进入上下文的字节，后一个把一段任务中的模型调用计入费用。两者都可能有用，却不能互相替代。过去关注“省下的调用费会不会花在别处”，今天首先要修正一个容易延续的怀疑：不能在已读到新测量后，仍说项目只测过压缩比例。
新测量也留下具体条件。当前网关把输出处理、缓存和其他机制一起打开，并包含短回答风格；同一脚本任务反复运行，支持这个任务上的采样估计，不支持任意任务分布。文档又只展示区间完整落在省钱方向的结果。[2] 我因此把它当作值得继续检查的正面证据，而不会把节省区间写成所有用户都能达到的保证。仓库插件、商业网关和不同客户端仍要分开。
3月的外部分析追问检索往返成本，当前候选 PR 则给出一个更可操作的失败：某类非 ASCII 词边界让应有的记忆没有被召回。[3][4] 前者是方法批评，后者是作者报告的基准对照，两者都不是编辑独立复现。没有找到与找到错误信息会造成不同后果，评测不该只把它们记为一句“搜索失败”。
这使我更关注压缩的单位。对于问日志有多少错误，先写程序统计可能保留全部所需信息；对于判断一个约束是否违反，先给标题和计数可能省掉真正关键的条件。保存在外部不等于已进入模型的判断，也不等于它会想到正确检索词。应让任务预先指定需要找到的证据，记录回读次数、首次命中、误取旧约束以及最后是否完成。
SWE-TaskFlow 在同一组目标与最终测试下改变信息逐步出现的方式，费用就变了。[5] Meta 的新模型则强调跨会话记忆与持续执行。[6] 这些材料没有共同验证一种压缩方案，但让比较目标更清楚：既要看信息怎么存，也要看何时取出、任务改向后能否换掉旧判断。存储更省与使用更可靠应分别测量。
可以从几十个有明确证据位置的长任务开始，比较全文、摘要后按需检索、以及稳定前缀加按需检索三种方式。保持模型、最终测试和总预算一致，计入索引、追问与失败运行；另放一组有同名实体、旧版本约束和多语言术语的任务。若摘要方式只在简单统计题上省钱，就把适用范围收回到统计题。这样的负结果也能帮助我们决定哪些信息不应提前压掉。
另一种解释
短而独立的统计任务可能天然适合输出处理；持续要求完整证据的任务则可能回读很多。不同模型自己筛选数据的能力也会改变收益。
接下来观察什么
核对公开成对费用数据的完整任务清单与选择规则，并找独立复测；重点检查多语言检索与失败费用。