Claude Code 有笔比主对话还贵的暗账：状态栏那几个字（agent_summary）

Claude Code 有笔比主对话还贵的暗账：状态栏那几个字（agent_summary）

昨天这篇 769：长会话别再被假 1M 打断 讲的是：上下文过线时别停死，要 compact 后续跑。今天补同一条产品线的另一侧——钱和额度是不是在你看不见的地方烧掉。

场景很常见：开了几个后台 / 子 agent，面板上状态栏每隔一会儿换几个词（「reading files」「running tests」之类）。看起来无害。问题是：为了这 3–5 个词，客户端可能每隔约 30 秒，把该 agent 的整段 transcript再送给模型（多半是 Opus）做一次小结；结果只更新面板，不进你的主对话。

社区用 OpenTelemetry 按 query_source 分组后发现：在「多子代理、跑得久」的用法里，这项叫 agent_summary 的请求，可以占到总花费的大约 15%–20%，有人测到比主对话还高。GitHub issue #86879 里还有约 18%–26% 的独立测点。

下文数字一律标「据公开 gist / issue / 评论自测」，不是我本机复跑的账单。订阅制下损失的常常是限额余量，不一定是「多打一张发票」。先学会自己量，再决定要不要动第三方方案。

一、先看结论

二、机制：3–5 个词，为何能烧一整段上下文

据 Flamerix gist 与 #86879 的公开描述，行为大致是：

1. 对每个活跃的后台 / 子 agent，约每 30 秒触发一次（间隔也可被服务端调到约 30–240 秒区间，默认常落在下限附近）。
2. 请求把该 agent 当前整段对话历史（再加工具 schema 等）送到该 agent 自己的模型（实测里大量是 Opus 档）。
3. 模型被要求用 3–5 个词描述「最近在干什么」。
4. 文本只更新 Agents 面板状态栏；不写回主对话上下文（issue 里写明 fork、deny tools、skipTranscript 等）。

因此成本随两件事线性放大：

• 并发数：3 个长跑子代理 ≈ 每分钟约 6 次小结请求；
• 上下文体积：子代理 transcript 越大，每次重读越贵（缓存命中能降价，但「每 30 秒再扫一遍」仍会啃限额）。

gist 还给出一个反直觉比例：约 9000 : 1 的输入 token / 输出 token——输出就那么几个词，输入却是整段历史。

时间线（据 gist，2026）：

三、公开测点怎么读（别把「一周 16%」当成你的账单）

1）Flamerix / DRIM：按周汇总

来源：gist

在 Claude Code 的 OpenTelemetry 导出里，对 claude_code.api_request（或同类 API 请求事件）按 query_source 分组：

gist 自己写明：这里的 spend 是客户端每请求估计，不是发票；订阅用户丢的是 rate-limit / 限额余量。

2）Issue #86879：单会话原始包抓取

来源：#86879（2026-08-15 开，后续评论持续到 2026-10）

作者一次约 4 小时、27 个子代理、1496 次请求（OTEL_LOG_RAW_API_BODIES）：

同时：约 22.7% 的请求次数只换来总共约 2.2 万输出 token（约 65/次）的化妆文案。

3）评论区其它测点（同 issue）

• 有人在 20+ 子代理会话里看到加权 token 约 15–22%。
• 2.1.276 上一次约 1h45、四子代理会话：agent_summary 约占会话 cache-read 的 26%；长上下文子代理（约 380k）下，每小时光 spinner 就可到数千万级 cache-read。
• 2026-10-22 仍有人反馈 2.1.300 / 2.1.301 没有文档化官方关法；另有人用「可见 cache vs 隐藏 cache」估子代理暗读。
• 2026-10-28 Flamerix 在 issue 下挂出上述 Bun preload gist。

怎么用这些数字： 它们描述的是「子代理很重」的尾部用法。你若几乎不开后台 agent，份额可能接近 0——以你自己的 query_source 分组为准。HN / 二手文也会出现「我这边最多约 8%」这类反例，正好说明方差大，不要直接改预算表。

四、先装表：用 OTEL 按 query_source 自查

省 Token 系列一贯立场（见 760 冷静篇）：先表后刀。

agent_summary 还有个坑：skipTranscript: true（issue 原文）——它不进磁盘上的会话 transcript。只看本地 JSONL / 聊天记录的用量工具，会系统性低估。要看见它，得走 OpenTelemetry / 原始 API 体 一类通道。

实操提纲（按你现有采集栈裁剪）：

1. 打开 Claude Code 的用量 / tracing 导出（官方文档入口：Monitoring usage；具体环境变量以你当前版本文档为准）。
2. 过滤 API / LLM 请求类事件，按属性 query_source 分组。
3. 对比：agent_summary vs 主对话 / 真实 agent 轮次——先看请求次数占比，再看 token / cost_usd。
4. 选一天「几乎没开后台 agent」做对照：若份额接近 0，说明你平时不受影响。
5. 子代理很重的日子再采一次：这才是决策样本。

可选自检清单：

• 导出里能看到 query_source 字段
• 能单独筛出 agent_summary
• 知道自己用的是「估计 cost」还是供应商账单
• 对照过「无后台日」vs「多子代理日」

没有表，就不要先上第三方 hook。

五、有没有官方关闭开关？

综合 gist 与 #86879 的公开结论（截至素材核实日，issue 仍 open）：

issue 作者的诉求很朴素：给一个 env / settings 键，或把这类化妆请求纳入「可关的非必要流量」。在官方回应前，工程上只能：计量 → 减并发/减墙钟 → 或自担风险用社区方案。

六、社区 Bun preload：能关，但是第三方、升级敏感

Flamerix 提供的方案（MIT，作者声明 as-is、自担风险）：用 Bun 的 --preload 在运行时包一层 setTimeout / setInterval；若回调源码文本命中 summarizer 锚点（例如含 [AgentSummary] Timer fired 一类字符串），则换成惰性定时器，其它定时器原样放行。不改 Claude Code 二进制文件。

公开安装思路（完整脚本与校验步骤以 gist 为准，此处不复制整份 hook 源码）：

## 1) 下载 gist 中的 no-agent-summary.js 到稳定绝对路径（示例）
## 2) 启动前带上 preload，并重启 daemon，避免旧环境继承
claude daemon stop --any
BUN_OPTIONS="${BUN_OPTIONS:+$BUN_OPTIONS }--preload /绝对路径/no-agent-summary.js" claude

gist 强调的验收与坑：

1. 必须 claude daemon stop --any（或等价重启），否则 daemon / pty / 预热会话仍可能不带 preload。
2. 无头、claude -p、CI、编辑器集成也要带同一环境变量。
3. 作者测过 Linux 上多版（含 2.1.312 等）：hook off 时 summary fork 次数可到 0；pass 模式用于 A/B。
4. Fail-open：锚点字符串一变，hook 匹配失败 → 小结静默恢复。所以 每次升级后复验（看 preload 日志 + OTEL 里 agent_summary 是否归零）。
5. 可见副作用：面板状态不再刷新；与 SDK task_progress 的 summary 字段等可能变空——功能换额度，不是免费午餐。
6. 法律 / ToS：改客户端运行时行为是否触碰服务条款，作者明确甩给使用者自查；本博客不鼓励在未读条款、未自测的情况下对生产账号上 hook。

本站立场： 可以当「社区应急阀」了解；默认推荐仍是 OTEL 自查 + 少开无意义的长跑子代理。真要上 hook，请直接读原 gist，并在升级流水线里加一条「agent_summary 是否仍为 0」的检查。

七、和 769 / 省 Token 系列怎么串

可执行组合：

1. 长会话用户：先升到 2.1.311+（769），会话别断。
2. 子代理重度用户：OTEL 看一眼 agent_summary 占比。
3. 占比高且你不需要面板文案：再评估社区 preload；否则优先 少并发、短墙钟、任务拆小。
4. 任何「再省 20%」的承诺：回到 760——用自己的表验收。

八、检查清单

计量

• 能按 query_source 看到 agent_summary
• 区分「估计 cost」与真实限额/账单
• 有「无后台日」基线

行为

• 不需要的长跑子代理及时停
• CI / 无人值守会话尤其警惕「没人看的 spinner」

若考虑第三方 hook

• 已读 gist 免责声明与 Verify 节
• 只用绝对路径 --preload，并重启 daemon
• 升级 Claude Code 后复跑 Verify + OTEL
• 接受「状态栏不再更新」

九、小结

1. agent_summary 是给状态栏用的旁路模型调用：约每 30 秒、整段 transcript、常常是 Opus 档，不进主对话、也不进 transcript 日志。
2. 公开测点集中在 约 15%–26% 区间（花费或 token，口径不同）；你的数字以 OTEL 分组为准。
3. 社区目前认为 没有干净的官方关法；Bun preload 能压到 0，但是 第三方、fail-open、升级必复验。
4. 和 769 一起看：长会话既要续得上，也要看得见暗账——表先于刀。

参考来源

• Flamerix AI gist（机制、一周 16.4%/19.7%、Bun preload、版本表）：https://gist.github.com/flamerix-ai/c3905705cc4205e5de3011fa2e74efce
• GitHub issue #86879（会话测 18%/22.7% 请求、后续评论测点）：https://github.com/anthropics/claude-code/issues/86879
• Claude Code 用量监控文档：https://code.claude.com/docs/en/monitoring-usage
• 本系列：769 自动 compact · 760 省 Token 冷静篇 · 755 SmartCompact