agentburn

Claude Code · Codex CLI · Gemini CLI · opencode · OpenClaw · Hermes Agent — 一个标准化的核心，完全本地、只读、零依赖

uvx agentburn

▶  在浏览器中试用——无需安装

你并不是在平常的一天用完了额度

你是在一个时段内用完的。在这台机器上，这个时段的用量是中位数的 5.4 倍——同一个人、同一周、同一订阅。

助手自己的日志已经记录了是哪个时段，以及是什么填满了它。你机器上的其他信息都做不到这一点：内置计数器只显示总量，账单也只显示总量，两者都不会告诉你是哪五个小时让你用完了额度。

⏳ agentburn limits — claude-code · rolling 5-hour windows

   PEAK WINDOW        Aug 04 12:45–17:45 · 555M weighted
                      opus 91% · sonnet 9%   ·   cli 93% · subagent 7%
   TYPICAL WINDOW     104M    median of 83 active 5h slots
   PEAK / TYPICAL     5.4×    a wall is hit by the peak, not by the median

   WHAT FILLS THE WINDOW
   cache reads     64%   ·   cache writes 25%   ·   output 11%

只需一条命令，无需账户，任何信息都不会离开你的电脑：

uvx agentburn            # where it burns, and what to change
uvx agentburn limits     # how fast you fill a usage window, and how long until the wall
uvx agentburn context    # what long contexts cost — and what a /clear at 150k would have saved

Agent 会以两种方式产生费用，也有两个问题要问

两者都会读取相同的本地日志，也都不会编造数据中不存在的数字。

优化订阅不会改变账单，只会改变你在被限流前能用多久。这是一个时间窗口问题，而窗口需要在单次会话内解析——一次会话通常会跨越多个窗口。

• 峰值与典型值。 将最差的滚动 5 小时窗口与活跃窗口的中位数进行比较。比值就是结论：峰值会触及上限。

• 窗口由什么填满——按模型、来源（你 / 子 Agent / 计划任务）和类型（缓存读取、缓存写入或输出）分类。

• 自动根据你自己的上限衡量。 Anthropic 不会公布这些额度背后的公式，因此 agentburn 不会凭空设定阈值。但 Claude Code 会将限流信息写入转录记录（"You've hit your session limit · resets 8:30pm"），每个这样的时刻都是一个实测上限。有多个记录时，上限取其中位数：

  YOUR MEASURED CEILING
  median of 35 cut-offs Claude Code recorded itself
  ceiling                146M   weighted tokens
  peak window            137%   of your ceiling
  last 5h                 16%   of your ceiling
  TIME TO WALL          2.7 h   at the pace of the last 30 min
  

  日志中还没有限流记录？使用 --hit "2026-08-20 14:30" 手动指定。实测上限会保存在 ~/.agentburn/ceiling.json 中，因此下面的状态行也能读取它。

• Codex：提供方自己的读数。 Codex CLI 会在每次请求旁写入 rate_limits.used_percent。agentburn 会将每个读数与同一窗口内的加权用量配对，并取中位数——这是根据提供方的计算方式得出的上限，而不是根据限流记录推算的。请将其视为估算值：该百分比统计了账号上的所有设备和应用，而本地运行记录只占其中一部分；当 Codex 不再报告某个窗口（套餐或客户端发生变化）时，后续峰值会标记为根据先前窗口测得，而不会误报为超限。

• 到达上限的剩余时间。 用上限减去当前窗口用量，再除以过去半小时的使用速度。工作时你真正想知道的数字。

• 周用量也有。 最繁忙的滚动 7 天时段、本周已用的比例，以及 Claude Code 记录到每周限流时的每周上限。

• 按项目查看。 会话会记录工作目录；峰值窗口会按目录拆分。

agentburn statusline — 在 Claude Code 中实时查看上限

一行、无颜色，专为 Claude Code 的 statusLine 打造：

⏳ 5h 63% · wall in 47 min · week 71%

{ "statusLine": { "type": "command", "command": "uvx agentburn statusline" } }

只读取最近三天的日志（上限来自状态文件），因此每轮运行的开销都足够低。

agentburn context — 长上下文的成本

每次调用都会重新读取完整上下文；在订阅方案中，这次重新读取就是窗口：一次 300k 的轮次，成本相当于三次 100k 的轮次。Claude Code 会记录每次调用的准确上下文大小，因此这是实测值，而非建模估算：

📏 agentburn context — claude-code · what a long context costs

   CALLS                        156,226   median context 143K · p90 316K · max 704K

   WHERE THE WINDOW GOES, BY CONTEXT SIZE
   100–200k     ██████············   35%    59,780 calls
   200–400k     ████████··········   43%    42,420 calls
   >400k        ██················   11%     7,257 calls

   IF YOU HAD RESTARTED AT…
   /clear at 100K     →   41% of the window not spent   (108,573 calls were past it)
   /clear at 150K     →   26% of the window not spent   (73,600 calls were past it)

   WHAT A SKILL COSTS
   handoff                                 7.96K per load ×  226 =     1.8M
   claude-api                              33.6K per load ×   14 =     470K

• /clear 的计算方式——每次调用中超过阈值的上下文部分，按缓存读取费率计算：假设较短会话完成相同工作，这就是养成重启习惯能诚实节省的用量。
• 实测技能成本——单独调用一次 Skill 后，上下文增长的中位数，取自最近的加载记录。捆绑技能不会触及磁盘；转录记录会看到所有技能。
• 按 effort 等级查看——各个 effort 设置占用了多少窗口用量。
• 带有可执行措施的发现会显示在 agentburn fix 中：重启阈值和占用较大的技能。

agentburn commits — 一次提交花费了多少

会话会记录工作目录和分支；你的代码库会记录每次提交的时间。两次连续提交之间的用量，就是第二次提交所花费的用量——只读 git log，不会写入任何内容：

   COSTLIEST COMMITS
       124M   33_Thoforge        1f7a31a1  Aug 30  fix(ui): правки UX-аудита — раскладка, навигация
      81.2M   33_Thoforge        ad19bff7  Aug 28  feat(ui): цель над деревом и развилка в карточке

   BY REPOSITORY
   33_Thoforge                 1.95M median ·  287 commits ·    1.52B total

加权令牌数 = 令牌数 × 公开发布的价格比率（缓存读取 0.1×、缓存写入 1.25×、按模型计算的输出），并统一折算为参考模型的一个输入令牌。所有比率都是公开的；没有任何一个是对提供方如何计费的猜测。

agentburn — 成本视图

• 费用花在哪里 — 按来源划分：cron / subagent / gateway:telegram|discord|whatsapp / cli。始终运行 ≠ 免费。
• 🌙 你睡着时 — 单独列出并命名夜间账单（--night 23-7）。
• 固定开销 — 按来源统计每次 API 调用未缓存的输入 token，并根据公开基准进行校准。
• Subagent 汇总 — 将委派成本追溯到发起它的会话。
• agentburn why — 行为取证：重复读取循环、重试风暴、空闲心跳、每个 cron 的账单、上下文抖动。
• agentburn fix — 可直接粘贴的配置补丁，默认采用试运行模式。

agentburn fix — 将发现转化为配置，而不是建议

不是“考虑使用更便宜的模型”，而是指出确切的文件和确切的行。只有经过 Agent 自身源码或已记录配置验证的调节项，才会提供补丁生成器：

🔧 agentburn fix — claude-code · DRY-RUN (nothing was changed)

   1. Drop 2 MCP server(s) you never called
      why    : registered but not called once in the last 30d: blender-mcp, pixellab.
               Every registered server ships its tool definitions with the context
               of every session that loads it.
      proposed:
        claude mcp remove blender-mcp

   2. Trim the always-loaded memory files (2,254 tokens)
      why    : loaded into every session's context and re-sent whenever the prompt
               cache expires or the context is compacted — at least 3,565× this window.

特意不提供 --apply：这是你的 Agent 配置。请自行粘贴，然后用 --save-baseline → --compare 验证节省情况。

为何相信这些数字

Token 追踪工具之间经常存在差异（公开问题讨论中的差异达 2–91 倍）。agentburn 采取相反的做法：

• 数字来自Agent 自身的账目，以只读方式读取。不抓取、不使用代理、不猜测。
• 每条回复只计算一次。 Claude Code 会为每个内容块写入一行转录记录，每行都带有相同的 usage；累加这些行会使调用和 token 数膨胀约 1.8 倍。agentburn 按 requestId 去重（在 0.14.0 中发现并修复；此前此工具报告的绝对总数因此被放大，但比率不受影响）。
• 原样显示服务商计费的成本；估算值以 ~ 标记；混合数据会标为混合。
• 没有价格的地方，就不虚构价格。 Claude Code 不记录成本，而订阅用量也没有可信的单 token 价格，因此该适配器只报告 token 和时间窗口，绝不报告金额。
• 会检测有消息但记录的 token 数为零的会话（已知的记账缺口，例如 hermes-agent #12023）：总数会明确标为下限，并将修复记账问题列为建议 #1。
• 对于不记录结果权重的 Agent，权重会标为估算值，且只用于对发现进行相互排序。

速度

转录文件只会追加内容，因此只需解析一次。每个文件的解析结果都会按文件大小和修改时间缓存在 ~/.agentburn/cache 中，后续运行会复用所有未更改的文件：

文件增大后会重新解析并缓存；其他内容不会被触碰。--no-cache（或 AGENTBURN_NO_CACHE=1）会强制完整重新解析，--clear-cache 会删除缓存。缓存属于派生数据——删除它只会耗费时间，不会产生其他影响。

隐私

所有操作都在本地运行，并以只读方式读取你的日志。不进行网络调用、不发送遥测数据，也不需要账户。报告归你所有。只有明确说明的命令会访问网络：drift 会 GET 一个公开的趋势文件，--submit 会打开一个预填好的问题，由你审核并提交。

~/.agentburn/cache 中的解析缓存（权限模式 0700）会保存报告中显示的相同工具名称和截断后的参数键，这些数据从本机已有日志中派生——绝不包含消息内容。--clear-cache 会将其删除。

为什么会有这个项目

全天候运行的 Agent 会让你不断付费——而它们内置的计数器只会显示总量：

“每次 API 调用中，有 73% 都是固定开销——约 13.9K 个工具定义和系统提示词令牌，每次都会重新发送。” — hermes-agent #4379

“一位新手写道，早上醒来发现隔夜运行产生了 47 美元的意外账单——这并非罕见的故障，而是无人监督的循环默认会发生的情况。” — dev.to

对比

ccusage 和 codeburn 在各自擅长的领域都很出色——agentburn 有意从它们止步之处开始（ccusage 尚未纳入按工具范围分析）。

支持的 Agent

采用统一的规范化模型，每种 Agent 对应一个适配器。运行 agentburn，机器上发现的每种 Agent 都会有自己的报告。

各适配器基于共享模型编写，约 150 行代码——欢迎为下一个适配器提交 PR。

claude mcp add agentburn -- agentburn mcp
# Hermes / OpenClaw: add an stdio MCP server with command `agentburn mcp`

🔥 my claude-code agent · last 30d
3.01B tokens · 19,255 API calls
where it burns: cli 77% · subagent 23%
⏳ my peak 5h window: 555M weighted tokens — 5.4× my own median window
🌙 while I slept (00–08): 75.3M tokens — 3% of everything
— agentburn · local & private

agentburn explain --model llama3.1          # local ollama — nothing leaves the machine
agentburn explain --llm https://openrouter.ai/api/v1 \
  --model deepseek/deepseek-chat --yes-remote --lang ru

agentburn --agent openclaw --budget-night 5 --fail-over --no-color \
  || notify-send "🚨 agent is burning money at night"

相关项目

token-history — 宏观视角：每日存档世界在使用哪些 Agent。agentburn 则是微观视角：你的支出都花在哪里。

许可证

MIT

_{mcp-name: io.github.Socialpranker/agentburn}