agentburn

[Claude Code](#supported-agents) · [Codex CLI](#supported-agents) · [Gemini CLI](#supported-agents) · [opencode](#supported-agents) · [OpenClaw](#supported-agents) · [Hermes Agent](#supported-agents) — one normalized core, local, read-only, zero dependencies

uvx agentburn

[▶ Try it in your browser — no install](https://socialpranker.github.io/agentburn/)

---

You didn't run out on your average day

You ran out inside one window. On this machine that window was 5.4× the median one — same person, same week, same subscription.

Your assistant's own logs already know which window it was and what filled it. Nothing else on your machine does: the built-in counter shows a total, your invoice shows a total, and neither says *which five hours took you out.*

⏳ 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%

One command, no account, nothing leaves your computer:

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

Two ways agents cost you, two questions

Both read the same local logs. Neither invents a number the data doesn't contain.

agentburn limits — the subscription view

Optimizing a subscription doesn't change your bill. It changes how far you get before you're cut off. That is a *window* problem, and windows need intra-session resolution — a single session routinely spans several of them.

• Peak vs typical. Your worst rolling 5-hour window against the median of your own active ones. The ratio is the finding: a wall is hit by the peak.
• What filled it — by model, by source (you / subagents / scheduled work), and by kind (cache reads vs cache writes vs output).
• Measured against your own wall — automatically. Anthropic doesn't publish the formula behind those allowances, so agentburn refuses to invent a threshold. But Claude Code writes the cut-off into the transcript itself (*"You've hit your session limit · resets 8:30pm"*), and every one of those moments is a measured ceiling. With several, the ceiling is their median:

  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

No cut-off in your logs yet? --hit "2026-08-20 14:30" names one by hand. A measured ceiling is remembered in ~/.agentburn/ceiling.json, so the status line below knows it too.

• Codex: the provider's own reading. Codex CLI writes rate_limits.used_percent next to every request. agentburn pairs each reading with your weighted usage of the same window and takes the median — a ceiling from the provider's arithmetic, not from a cut-off. Treat it as an estimate: that percentage counts every device and app on the account, while your local rollouts are only part of it — and when Codex stops reporting a window (plan or client change), a later peak is flagged as measured on earlier windows, not sold as an overrun.
• Time to wall. Ceiling minus the current window, divided by the pace of the last half hour. The number you actually want while working.
• The week, too. The heaviest rolling 7-day span, how much of it this week already is, and a weekly ceiling when Claude Code recorded a weekly cut-off.
• By project. Sessions record their working directory; the peak window is split by it.

agentburn statusline — the wall, live, inside Claude Code

One line, no colour, built for Claude Code's statusLine:

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

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

Reads only the last three days of logs (the ceiling comes from the state file), so it stays cheap enough to run on every turn.

agentburn context — what a long context costs

Every call re-reads its whole context, and on a subscription that re-reading *is* the window: a turn at 300k costs what three turns at 100k cost. Claude Code records the exact context size of every call, so this is measured, not modelled:

📏 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

• The `/clear` arithmetic — the part of every call's context above a threshold, at the cache-read rate: the honest saving of a restart habit, assuming the same work in shorter sessions.
• Skill costs, measured — the context growth right after a lone Skill call, median of recent loads. Bundled skills never touch the disk; the transcript sees all of them.
• By effort level — how much of the window each effort setting took.
• Findings with a lever land in agentburn fix: the restart threshold, and the heavy skills.

agentburn commits — what a commit cost you

Sessions record their working directory and branch; your repositories record when each commit landed. The usage between two consecutive commits is what the second one cost — read-only git log, nothing written:

   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

Weighted tokens = tokens × *published* price ratios (cache read 0.1×, cache write 1.25×, output per model), normalized to one input token of the reference model. Every ratio is public; none of them is a guess about how the provider counts.

agentburn — the money view

• Where it burns — by source: cron / subagent / gateway:telegram|discord|whatsapp / cli. Always-on ≠ free.
• 🌙 While you slept — the overnight bill, isolated and named (--night 23-7).
• Fixed overhead — uncached input tokens per API call, per source, calibrated against a public benchmark.
• Subagent rollups — delegation cost chained back to the session that spawned it.
• `agentburn why` — behavioral forensics: re-read loops, retry storms, idle heartbeats, per-cron receipts, context thrash.
• `agentburn fix` — ready-to-paste config patches, dry-run by design.

agentburn fix — findings become config, not advice

Not "consider a cheaper model" but the exact file and the exact lines. Patch generators exist only for levers verified against the agent's own source or documented configuration:

🔧 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

1. 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.

There is no --apply on purpose: it's your agent's config. Paste it yourself, then prove the saving with --save-baseline → --compare.

Why trust these numbers

Token trackers quietly disagree with each other (2–91× in public issue threads). agentburn takes the opposite stance:

• Numbers come from the agent's own accounting, read-only. No scraping, no proxies, no guessing.
• One reply is counted once. Claude Code writes one transcript line per content block, each carrying the same usage; summing lines inflates calls and tokens ~1.8×. agentburn deduplicates by requestId (found and fixed in 0.14.0 — earlier absolute totals from this tool were inflated by that factor; ratios were not).
• Provider-billed costs are shown as-is; estimates are marked ~; mixed data is labeled mixed.
• Where a price doesn't exist, none is invented. Claude Code records no costs and subscription usage has no honest per-token price — so that adapter reports tokens and windows, never dollars.
• Sessions with messages but zero recorded tokens (known accounting gaps, e.g. hermes-agent #12023) are detected: totals become an explicit lower bound, and fixing the accounting becomes recommendation #1.
• Result weights on agents that don't record them are labeled *estimates*, and only ever used to rank findings against each other.

Speed

Transcripts are append-only, so they are parsed once. Each file's parse is cached under its size and mtime in ~/.agentburn/cache, and a run reuses every file that hasn't changed:

A file that grew is re-parsed and re-cached; nothing else is touched. --no-cache (or AGENTBURN_NO_CACHE=1) forces a full re-parse, --clear-cache deletes it. The cache is derived data — deleting it costs time, nothing else.

Privac