Three ways I miscounted my own AI agents, and what the transcripts actually say

Kosta Stamboldzhiev — Fri, 18 Sep 2026 09:06:44 +0000

Claude Code writes a JSONL transcript for every session, and another one for every subagent it spawns. They sit in ~/.claude/projects/ right now, on your machine, and nobody reads them.

I have spent six weeks reading mine. I got the arithmetic wrong three times in public, and each mistake turned out to be a property of the file format rather than a slip. Here they are, with the one-liners that expose them, so you can skip the part where you post a wrong number on Reddit and get corrected by a stranger with a better corpus.

1. Most of the output is in files you are not looking at

The transcript you watch live is the parent. Every subagent writes its own file:

~/.claude/projects/<project-slug>/<session-id>.jsonl          the session you were watching
~/.claude/projects/<project-slug>/<session-id>/subagents/     everything it spawned

On my machine, across 51 runs that used subagents, the children wrote 58.4% of all output tokens. If you are judging your own usage by what scrolls past you, you are looking at under half of a fan-out run.

There is a second tier that is easy to miss entirely, because it lives one directory deeper:

<session>/subagents/<id>.jsonl                          a Task subagent
<session>/subagents/workflows/<wf_id>/agent-*.jsonl     a workflow agent
<session>/subagents/workflows/<wf_id>/journal.jsonl     NOT an agent

My first walker stopped at the top level and under-counted children by about half. My second walker filtered on .jsonl and counted 34 workflow journals as silent agents, inflating the count by 7% and dragging down every per-child average. Same directory, opposite errors, two weeks apart.

Count them properly:

ls ~/.claude/projects/*/*/subagents/*.jsonl | wc -l
ls ~/.claude/projects/*/*/subagents/workflows/*/agent-*.jsonl | wc -l
ls ~/.claude/projects/*/*/subagents/workflows/*/journal.jsonl | wc -l

2. Summing usage per line over-reports you by about 3x

This is the one that will bite anyone writing a cost tool.

A single assistant response with several content blocks — thinking, then a tool call, then text — is written as several lines, and every one of those lines repeats the same complete usage object. It is not a running total. It is the same number, three times.

On my corpus: 130,002 lines carrying a usage block describe 63,014 responses. Summed per line that is 90,955,151 output tokens. Deduplicated on message.id it is 46,959,967. Plus 94%.

And here is the part I only saw after splitting it by tier:

tier	over-count if you sum per line
main transcripts	+195%
subagent transcripts	+2%

Subagent files mostly write one line per response. So a reader with this bug looks correct on the child files — which are exactly the files you would spot-check when validating it. That is why the bug survived two of my own reviews.

Deduplicate on message.id, keeping the last line you see for an id, because a response is written progressively and the final line is the complete one.

3. A hook firing writes two records, and sometimes zero

Every hook firing is written into the transcript, which means the question "has this guardrail of mine ever actually run?" is answerable retroactively, for your entire history, with no instrumentation:

grep -ho '"hookName":"[^"]*"' ~/.claude/projects/*/*.jsonl | sort | uniq -c | sort -rn

Mine says PostToolUse:Edit 505 and PostToolUse:Bash 4. Four. Ever. I would have told you that shell guard was load-bearing.

Except those are records, not firings. One firing writes two lines that share a toolUseID:

hook_success — the command, its exit code, duration and stdout
hook_additional_context — the text it injected back into the session

Deduplicate and my 8,831 records become 6,898 firings. Counting lines over-reports your own guardrails by 28%.

The payoff is that hook_success names the command, so a matcher carrying two hooks splits apart. Mine on Edit runs format-after-edit 185 times against lint-after-edit 52 — I had no idea one was running a third as often as the other.

Then the caveat that cost me my favourite claim. I had been saying that a hook absent from that list has never fired. A reader on r/ClaudeAI disproved it on a much bigger corpus: her PreCompact hook fires and writes no hookName at all — she proved it by lining its own output file up with nine compaction boundaries. So absence is three cases, not two:

never registered
registered, never fired
fired, never recorded

The transcript cannot tell them apart. What appears definitely ran; what is missing needs a second check.

The command

I got tired of maintaining scratch scripts that were wrong in a new way each week, so the reader I build has it as a flag now:

npx github:Kostakurta8/roundtable --stats

It reads every transcript under ~/.claude, prints one screen, and exits — no server, no port, nothing written, nothing leaving the machine. It prints the traps rather than silently correcting them, including the caveat that a missing hook proves nothing.

  1,469 session transcripts, 51 of them spawned subagents
  513 children  (327 task, 186 workflow)  median 7 per run

  children wrote 58.4% of the output of the runs that spawned them
  cold start: 46,669 cache-creation tokens per child, before it does any work
  median child: 65 tool calls over 1,286 s
  13 of 513 children (2.5%) made no tool call and wrote nothing

That last line is my favourite, because it is the failure you cannot see from the orchestrator: thirteen children that ran for hours and produced nothing at all. Twelve of them belong to a single run — one lane of a fan-out died quietly while the run as a whole looked busy and healthy.

The rest of the project is a viewer for the same files: it draws the session as a pixel-art office where each agent is a person at a desk, and the timeline rebuilds the room at any second by replaying the events rather than approximating them. It is read-only by construction — 405 to every non-GET, no outbound connection — and MIT.

github.com/Kostakurta8/roundtable

If you run --stats, I would genuinely like to know your child share. Mine is 58.4% and I have no idea whether that is normal.

DEV Community: Kosta Stamboldzhiev

Three ways I miscounted my own AI agents, and what the transcripts actually say

1. Most of the output is in files you are not looking at

2. Summing usage per line over-reports you by about 3x

3. A hook firing writes two records, and sometimes zero

The command