Hours doubled. Tool calls tripled.

By Spencer and Claude. Claude did the writing; the material is Spencer's engineering notes, measurements, and repositories. Nothing here has been independently fact-checked, so accuracy is not guaranteed — read it as a lab notebook, not a datasheet.

I read 28 days of local session transcripts to see whether one very long day was unusual. It was: active time rose 1.8× against the median, while tool calls rose 3.5×. The difference came largely from parallel subagents. The same record also shows a workday drifting later into the night.

What was counted

As of 2026-08-02, this Mac held about 1,050 Claude Code transcripts: 1.7 GB of timestamped JSON covering 262,340 events from July 6 through August 2.

• Prompt: a message I typed, excluding tool results and system metadata.
• Tool call: a tool_use block in an assistant message, including subagent transcripts. A subagent writes its own transcript, so a parent's Agent call and the calls that subagent then makes are counted once each, not twice.
• Active hours: every event from every transcript merged into one stream, with gaps under 15 minutes treated as continuous work. This is session activity, not verified attention, and on a day with subagents running it is barely a filter at all: the 15.7 hours below is the whole 15.7-hour span from the first event to the last. A 10-minute threshold changes it to 15.2.

The record has hard limits. Transcripts expire after 30 days, so July 6 is the start of the surviving record, not the work. It covers one Mac, not browser work or my other computers. It also contains no account identifier: every session on this machine is pooled and cannot be separated by subscription. And the files overlap slightly: a resumed session carries its earlier messages into the new transcript, so a few events are on disk twice. Counting by event id instead removes well under one percent of the day below.

The day

The window ran Saturday 10:05 to Sunday 01:48. Its longest pause between prompts was 50 minutes; the median was 1.7 minutes. Nothing in the merged event stream paused for a quarter of an hour, including across that 50-minute gap, because agents kept working through it.

The median uses the 27 recorded days. July 19 is the only empty day in 28.

The clock moved

The empty band narrowed from roughly 22:00–08:00 in the first week to 02:00–08:00 in the last. Several days never close cleanly.

The transcripts cannot say whether that means more work, thinner work, or a laptop left open longer. They only show that the session was producing events.

The work changed shape

Of 88 active sessions, 61 were subagents. Sixty-two Agent spawns produced 5,468 of the day's 8,540 tool calls, roughly two thirds of the mechanical work. The extra calls did not fit inside the extra hours, so they ran alongside each other rather than after each other. That much is close to definitional: once subagent calls are in the count, a day that spawns sixty-two of them is busier whether or not more got done. What the number says is where the work ran, not how much of it was worth running.

Across all 28 days the dominant tools were Bash (43,973 calls), Edit (12,826), Read (11,762), and browser automation (3,334). This was a shell-driven bench, not mainly an editor.

What the counts cannot claim

The raw token total is 3.30 billion, but 3.22 billion are cache reads: repeated context, not new work. The defensible number is 12.4 million output tokens, and even that measures generation rather than usefulness.

Likewise, active hours do not measure attention, prompts do not measure difficulty, and commits do not measure value. Tool calls are the weakest of the four: a call is a call whether it found the answer, repeated a search another agent had already run, or retried something that had just failed, and nothing here counts accepted output or how long a task took end to end. There is no comparison to other people because these are local files from one machine; no honest percentile can be inferred from them.

What we were actually building

None of the counting says what the work was for, so here it is plainly.

PoleFX makes LED dance poles. A polycarbonate tube you can climb and spin on, with addressable LEDs sealed inside, going into studios, into venues, and onto stages with touring performers. Everything else we build exists to make that pole do something worth watching, and to keep the business around it running without me holding all of it in my head.

A pole on its own is a tube with lights in it. What makes it a product is the chain behind it, and this month touched every link.

At the bottom is the pole firmware, an ESP32 that takes frames off the network and clocks them into the LED strips. Most of the month's hardware work went here, and most of that was honesty rather than features. Gamma correction that had never once been applied. A frame pipeline that can actually hold 60 fps instead of reporting that it does. Updates over the air, so a pole that has already shipped does not have to come home to get better. It speaks DDP, sACN and Art-Net now, which is the difference between a pole we can drive and a pole a lighting desk can drive.

Above that sits the player: a Raspberry Pi that renders patterns and streams them to a whole fleet of poles at once. It runs the show. Pattern library, playlists, text, effects, scheduling, and a web interface a venue can operate without phoning me. It answers to DMX and OSC as well, so it can live inside somebody else's lighting rig instead of demanding its own.

Then the bench, which is the part I would not have predicted mattering this much. It became a real instrument bench this month: a logic analyzer and an oscilloscope both under program control, a current sensor, relay-switched power, and a daemon that owns all of it so two experiments cannot quietly fight over the same hardware. The point is to stop guessing. A year ago a board kept dropping its Ethernet link and we never learned why, because nothing on the bench could show what the supply was doing at the moment it happened. I do not want that mystery twice.

Next to it there is now a virtual stage: a browser club with haze and lasers and a crowd of figures driven by real captured motion, where a pattern can be judged in something close to the room it will play in, before anybody drives to a venue to find out.

The hardware design ran alongside all of that. The controller board went from a schematic to a four layer design with real design rules, a readable silkscreen, and its first Gerbers, which is the point where a board stops being a drawing and becomes something a factory can quote.

The rest is the business, and I count it as the same system. Quotes, invoices, the customer and pole registry, the storefront, the manual the shop builds from, the docs a customer reads at midnight when something will not turn on. A pole that ships correctly and gets supported afterwards is as much the product as the firmware inside it.

The ambition under all of it has two halves. Make the whole chain, from the LED to the invoice, one system I actually understand and can hand to someone else. And make its claims checkable: measured instead of asserted, written down somewhere that is not my memory, and retracted out loud when it turns out to be wrong. That is why this journal exists, and why the retractions further down are the commits I would keep.

What landed in the same window

The 14 PoleFX repos took 2,122 commits. That is a map of attention, not a productivity score. A commit may be a typo or an OTA subsystem, and generated Gerbers or board exports make line counts worse.

Twelve commits explicitly retract or correct earlier claims: the flash-hunt conclusion that failed pulse analysis, voltage starvation that was limiter contamination, a creepage estimate replaced by the IPC-2221 table, a pattern sweep whose OSC messages never reached the pole. If I kept twelve commits from the two thousand, it would be those.

The part worth watching

A day 1.8× longer and 3.5× busier is not one to repeat. The useful finding is that parallel subagents changed how the bench work gets done over roughly two weeks without any deliberate decision to change it.

The total is less interesting than the heatmap. The thing to watch is the band where the cells stop.

Session figures come from local Claude Code transcripts in ~/.claude/projects/, counted on 2026-08-02 for 2026-07-06 through 2026-08-02 in UTC-7. Active hours use a 15-minute continuity threshold. Token counts are the API usage fields per assistant message. Commit counts cover the same dates across 14 repos under ~/Documents/polefx and only work committed on this Mac. No data from outside this machine appears here.