编码 Agent 的账单大头是每轮重发的上下文：一个 4B 模型插在中间，官方称长会话压掉 85%
编码 Agent 的 token 账单，大头往往不是你的提问，而是每一轮都要重发的工具定义、历史记录和大段文件读取。Paritok 的做法是在 Agent 和模型 API 之间插一个代理：请求先被改写压缩再转发上游，按压缩后的 token 计费；网关与 4B 压缩模型都已开源，Apache-2.0。

在一个 Claude Code 会话里连跑 5 轮只读的"找 bug"任务，工具过滤在两边的条件下，内容压缩单独贡献 4.6%（第 1 轮）到 22.2%（累计 5 轮）；把工具 schema 过滤算回来，第 1 轮约省 25%，第 5 轮约 39%，上下文吃满的长会话宣称超过 85%，同一上下文窗口能多塞约 3 倍轮次。它的差异化设计是"非破坏性"：被压缩的段落带引用标签，Agent 可以按需取回原文；工具 schema 按会话冻结，避免破坏 prompt 缓存；超过窗口的历史做一次摘要。

所有节省比例都是发布方自测，arXiv 预印本与模型出自同一团队，没有第三方复现；官方给的第 1 轮数据只有个位数百分比，25% 那个数字是把"过滤掉约 2.1 万 token 工具块"折算回去的结果，属于估算而非实测；这类压缩必然改写上下文，而官方没有公开压缩后任务成功率的对照数据。我们此前写过同类工具宣称省 89% 而实测账单没降，这类工具的收益只能自己在真实会话里压着测。

我的判断：值得试，但别按宣传口径采购。挑你最长、读取最重的那类会话跑一周，把账单和任务成功率一起记——只降账单、不降返工，才算真的省。