Where the quota went without a result: context, cancels and compactions
Running out of quota is annoying. Running out of quota on turns that produced nothing is worse. Bumeter's Effectiveness panel looks back over your history and points at the turns that burned your limit without a result. It does this from facts the logs record, without calling a model, and it shows you how sure it is.
First, count tokens the way your limit does
The obvious way to rank turns is by total tokens. On a real Claude Code history that ranking is almost useless, because most tokens are cache reads: every turn re-reads the whole conversation from the prompt cache. A turn with 980,000 cache-read tokens and 20,000 new input tokens looks like a million tokens, but cache reads are cheap.
So Bumeter ranks by quota-weighted tokens, using the ratios every Claude model is priced with:
| Token type | Weight |
|---|---|
| New input | 1× |
| Cache write (5 minutes / 1 hour) | 1.25× / 2× |
| Cache read | 0.1× |
| Output and reasoning | 5× |
That million-token turn weighs 118,000, not a million. Rate limits are very likely weighted the same way, so this ranking matches what actually moves your 5-hour percentage much better. It is a relative unit, not money, and Bumeter says so wherever it shows one.
Three facts that point to wasted quota
The first version tried to spot corrections from your wording: a message starting with "no," or "fix that" after a turn. On real history most of those matches were new requests, not corrections, so it was dropped. What is left are three things the logs record as facts:
- Late cancels. You pressed Esc after the model had already been working for more than 2 minutes. Whatever it spent is gone. Bumeter is sure about these.
- Turns that started with a very large context. Every turn sends the whole context again, so a turn that starts above your "large context" threshold (300K tokens by default) is expensive before it does anything. This one is likely waste, not certain: sometimes you need that context.
- Sessions that overflowed twice or more. When the context overflows, Claude Code compacts it and the model forgets the start, then often reads the same files again. A session that does this twice is usually a task that should have been split. Also likely.
Each finding comes with how many turns or sessions it covers, their quota-weighted tokens, and one suggestion:
No model is called for any of this, so the analysis itself costs no tokens and nothing leaves your machine.
What a session's context is made of
Knowing that a context was big is half the story. The session view in the app (or bum session <id> in a terminal) shows what it was made of, call by call, by reading the session's log file directly:
| Part | What it is |
|---|---|
| System | everything not in the log: the system prompt, tool definitions, CLAUDE.md, hidden reasoning, plus compaction summaries |
| Skill | skill instructions loaded into the conversation |
| File read | files the model read |
| Tool I/O | other tool calls and their output: commands, searches, edits |
| Thinking | visible reasoning |
| Output | the model's replies |
| User | your messages |
The "System" part is worked out rather than measured: it is the real context size Claude Code reports, minus everything Bumeter can see in the log. That keeps the parts adding up to the true total, instead of a pie chart that silently leaves out a third.
The same pass looks for three patterns worth fixing, and says them in plain words:
- a file read 3 or more times in one session: "File src/app.ts was read 4 times (~38K tokens). Read it once, or use offset/limit."
- a single tool output over 10K tokens: "Output of `npm test` is ~22K tokens. Trim it with | head or grep."
- a skill that loads more than 5K tokens per call.
A nudge while you work
All of this is after the fact. While you work, Bumeter's part of the Claude Code status line shows the context the session carries right now, and adds ⚠ /compact once it passes the same threshold:
There is a desktop notification for a large context too, which you can turn off in Settings.
Habits that follow from the numbers
- Start a new session when you switch tasks. Carrying yesterday's context into today's bug fix is the most common source of "very large context" turns.
- Agree on a plan before a long run. Late cancels are the clearest waste; a two-line plan first is cheaper than three minutes of the wrong work.
- Split big work before it overflows. Two short sessions with a written handoff beat one session that compacts twice.
- Trim tool output. A test run that prints 20K tokens is paid for again on every turn after it.
Bumeter is free and open source (GPL-3.0), and everything stays on your machine. The source is at github.com/chieund/bumeter. The analysis is crates/bum-core/src/effect.rs and crates/bum-adapters/src/claude_code/composition.rs.