Tools / Claude Code Runway Audit
Where does your Claude Code usage go?
In my own September, 92% of Claude Code tokens were Claude re-reading the conversation, not reading my new messages or writing answers. This free script shows the same split for your sessions.
One Python file, standard library only. It reads token counts on your machine and sends nothing.
- Cache reads: Claude re-reading the conversation
- 92.49%
- Cache writes: saving the conversation to re-read later
- 6.90%
- Output: what Claude wrote
- 0.59%
- New input: your new messages
- 0.02%
My own Claude Code history, 1 to 28 September 2026.
Why: each turn re-reads the whole session
Every time Claude answers, it reads the whole conversation so far again. Early in a session that is cheap. Late in a long session, each short question re-reads everything before it. That is why cache reads dwarf everything else.
Illustration of the mechanism, not measured data.
| Top bar: share of sessions (338 of 3,384) | 10% |
|---|---|
| Bottom bar: share of main-session tokens they carried | 92.04% |
| Tokens carried by sessions of 40 or more turns | 87.67% |
| Compactions, median context size when each fired | 878 at 168,423 |
Measured, my own main sessions, 1 to 28 September 2026.
Check yours in two minutes
- 1
Download
runway_audit.py. It needs Python 3.8 or newer and nothing else. - 2
Run
python3 runway_audit.pyfrom any folder. Add--days 14to change the window. - 3
Read the Fit line. Then save a baseline with
--json > runway-baseline.json, because Claude Code deletes old transcripts.
Here is part of what it printed for my September:
Runway Audit 1.1.0 window 2026-09-01 to 2026-09-29 (UTC)
Counted: 3384 sessions, 170 subagent runs, 42783 assistant turns
Tokens: 5,204,305,526
Where the tokens went
input 813,552 0.0%
cache_write 359,252,884 6.9%
cache_read 4,813,273,963 92.5%
output 30,965,127 0.6%
subagents carried 4.5% of all tokens
...
Session shape
top 10% of sessions (338) carry 92.0% of session tokens
sessions of 40+ turns carry 87.7% of session tokens
turns per session: median 2.0, 90th percentile 7
...
compactions: 878 (2.59 per 10 sessions), median size before compaction 168,423 tokens
Fit: LIKELY FIT (a rough screening rule, not a prediction of savings)
- sessions of 40+ turns carry most of your tokens
- your sessions hit compaction regularlyWhat your result means
Likely fit
Sessions of 40 or more turns carry at least half of your tokens, and you hit compaction at least once per 10 sessions.
The Runway Kit ($29) adds the change steps: handoff and compaction templates, a way to trim the context every session loads, a status line that logs your plan usage, and a script that compares two periods of your own usage.
See the Runway Kit, $29Possible fit
One of those two is true.
Try the free habits first. Start a fresh session when the task changes, and carry over a short note instead of the
whole conversation. Run /compact yourself before the context fills.
Probably not a fit
Neither is true. Changing how you run sessions will probably not change much for you, so save your money.
Use the free token counter insteadInsufficient data means fewer than 10 main sessions or 300 assistant turns in the window. Widen it with --days.
Limits of my numbers
Window: 1 September to 28 September 2026. Denominators: 3,384 main sessions, 170 subagent runs, 42,783 assistant turns and 5,204,305,526 tokens, read from 5,120 transcript files written by Claude Code 2.1.281 to 2.1.285.
This is one heavy user, and most of those sessions are automated one-shot runs (the median session has 2 turns), so the session count overstates interactive work. It describes where my tokens went. It is not a comparison and not evidence that any change saves tokens.
How it works
Claude Code writes one transcript file per session under ~/.claude/projects (or under CLAUDE_CONFIG_DIR if you set it). Each assistant turn records its token usage in four classes: uncached
input, cache writes, cache reads and output. The audit adds those up per session, counts each message once even when
it appears on several lines, and counts the compaction markers Claude Code writes when it summarizes a full context.
Subagent runs are counted separately from main sessions. Lines it cannot parse are skipped. If it finds no readable rows in the window it reports UNREADABLE with the versions it saw, never a row of zeros.
The fit rule is a screening rule, not a calibrated model. I chose its thresholds knowing my own history is heavy-tailed, so they may favor heavy users like me, and they have not been checked against anyone else. The rule was fixed before the result above was produced, and a test in the kit fails if it changes.
Free tools that measure the same data
Measurement is not scarce. Claude Code's own /context and /cost commands show the current
session. ccusage reports usage across sessions from the same transcript files. claude-devtools shows compaction
boundaries. This audit adds two things: the fit screen above, and a saved baseline you can compare against later.
Questions
- Does the audit send my data anywhere?
- No. It is one Python file that uses only the standard library. It makes no network calls, needs no API key, and reads only token counts, model names, timestamps and compaction markers from the transcript files Claude Code already keeps on your machine. It never reads what you or Claude wrote.
- Why does it say INSUFFICIENT DATA?
- It needs at least 10 main sessions and 300 assistant turns in the window before it gives a verdict. Claude Code deletes old transcripts, so a short history can fall below that line. Widen the window with --days, or run it again after a few more weeks of work.
- Is the fit verdict a prediction of how much I will save?
- No. It is a screening rule that has not been tested against other people. It says whether your usage has the shape the change steps are aimed at: most tokens in long sessions, and regular compaction. It does not estimate a saving.
- Does it work on Windows?
- It has not been tested on Windows. It is written for macOS and Linux with Python 3.8 or newer.