DEV Community: Kosta Stamboldzhiev

Your Claude Code session as a 25-second timelapse (and the timestamp that lied)

Kosta Stamboldzhiev — Wed, 23 Sep 2026 13:59:21 +0000

Claude Code writes every session to disk as JSONL: one line per message, tool call and result, and a separate file for every subagent. I have been building a read-only viewer for those files that draws a session as a pixel-art office — each agent is a person at a desk. This week it learned to export a session as a GIF:

That is a staged session, so nothing private is in it: an orchestrator sends six scouts to map a billing service, hands eight changes to eight builders, and puts a verifier on each. One verifier comes back REFUTED, so a ninth builder goes to fix it and a ninth verifier checks the fix. Every frame is the real renderer replaying transcript events — the same code path as a real session.

To make one from your own latest session:

npx https://github.com/Kostakurta8/roundtable/releases/latest/download/roundtable.tgz --gif

It writes roundtable-<session>.gif where you ran it, in a few seconds, and sends nothing anywhere. By default it shows the task, the agent names and what they said, so look before posting; --bare draws the same run with none of that text.

Three things were harder than they looked.

1. A real session is mostly waiting

The first version sampled the session at even intervals and produced a still photograph with a few seconds of movement in it. Agents spend most of their time inside a tool call — a nine-minute build, a long read — and nothing moves.

So time is compressed before it is sped up. Every silence between two events is clamped to a beat (2.5 s, tightened down to 0.5 s for a busy session), and only then is the whole thing played faster to fit the clip. A session still too long at that point becomes its busiest stretch instead, scored by what a viewer can see: an agent arriving is worth 12, leaving 6, a file edit 2, a token count moving 0.

The wall clock in the office keeps the real time, so the cuts are visible: it jumps where the session waited.

2. One timestamp in the pipeline was lying

The first full render of the staged session reported it as six days long. It is nine minutes.

The observer attaches each subagent's name from a sidecar file next to its transcript, and it stamped that event with the moment it read the file, not the moment the agent started. The live viewer never noticed, because it processes events in arrival order. The clip sorts by timestamp, so every agent's name landed at the moment I ran the command — after all of them had already left the building, and six days after the session ended.

The fix pins each name to that agent's first transcript line. There is a test that fails if the staged session comes out longer than fifteen minutes.

3. I wrote the GIF encoder instead of installing one

The office is drawn with filled rectangles into a 480×270 RGBA buffer by a small software rasteriser that the visual-regression tests already use, so the missing piece was only the file format. It is about three hundred lines:

One palette for the whole clip, cut by median cut from a histogram of every frame, so a colour cannot shimmer between two indices from frame to frame.
Each frame carries only what changed: cropped to the bounding box of the changed pixels, with unchanged pixels inside the box written as the transparent index. An office where two people are walking is two small rectangles, not a whole room.
Scaling after indexing: the buffer is blown up 2× nearest-neighbour after the palette lookup, which is how the browser shows pixel art anyway, and LZW eats the repeated pixels.

The tests decode every frame back with a decoder written from the spec and compare pixel for pixel, including a 256×256 noise frame that fills and clears the LZW code table many times over — the path where encoders usually break.

A 25-second, 25-agent clip at 960×562 comes out at about 3 MB, and a whole render takes a few seconds.

It is also a live viewer on localhost where you can scrub back to any second of a session and see what each agent cost. Read-only, MIT, no account, no API calls: github.com/Kostakurta8/roundtable

If you run --gif on one of yours, I would like to know what it got wrong.

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.