I run a fleet of AI agents from parallel terminals. For one week I stopped guessing what that was worth and measured it — reading timestamps and token counts straight out of 266 local session logs. No impressions, no estimates. This is the readout.
Output roughly 5× in four weeks — from 14.9 agent-hours to 75.6. Over the same span my own hours grew about 4× (9.7 → 38.3). That difference is the part worth paying attention to: I am not only working more, each hour of my attention now buys more output as parallelism widens. (First and last bars are partial weeks at the window edges.)
The interesting number was never the volume. It was the ratio — and the ratio is still climbing.
The trailing 32 days average 7.0 agent-hours/day. This past week ran 14.5 — more than double the monthly baseline, with two days above 25 agent-hours.
| Time scale | Agent-hrs | My hrs | Leverage | Streams | Tokens | Tool calls |
|---|---|---|---|---|---|---|
| Daily average this week | 14.5 | 5.8 | 2.49× | 9 | 255M | 813 |
| This week 7 days | 101.6 | 40.7 | 2.49× | 115 | 1.78B | 5,693 |
| Trailing month 32-day measured | 224.3 | 104.8 | 2.14× | 264 | 4.37B | 12,347 |
| Annualized at current pace | ~5,280 | ~2,120 | 2.49× | ~5,980 | ~92B | ~296K |
A "stream" is any independent unit of work started — a terminal session or a parallel sub-agent run. The annualized row is a straight-line projection of this week's pace, not a measurement.
I did not run one assistant. I ran four, routing work by weight: the heaviest reasoning to the top tier, high-volume operational passes to the mid tier, quick strikes to the fastest one. Running them concurrently across terminals is what produced the 2.49× — four workers moving while I direct.
All 63 sessions, sorted by category. The counts are exact; client names, figures, and personal matters are deliberately withheld. The shape is the point — roughly a third of the week went into systems, infrastructure, and admin: the work that makes the next week faster. That is the compounding half of the ledger, and it is the half most people never schedule.
Session logs only retain about 30 days, so the longer arc is reconstructed from version-control history across 31 repositories — a shipping-cadence proxy, not a token measurement, and it undercounts everything that never touches a repo. The signal still holds: this way of working begins in January, ramps through spring, and is now compounding into systems and automation. 299 commits across 31 repositories in about six months.
SOURCE — 266 local session transcripts, parsed line by line. Every assistant turn carries an exact token-usage record and a UTC timestamp.
AGENT-HOURS — within each session, time between consecutive events is summed when the gap is ≤15 minutes; longer gaps count as breaks. Sessions are summed independently, so parallel terminals add up. This is engaged agent-time, not wall-clock.
WALL-HOURS — the union of active intervals across all sessions in a day, so overlapping work is counted once. This approximates real hands-on time.
LEVERAGE — agent-hours ÷ wall-hours. Above 1.0× means parallel work; 2.49× means about two and a half hours of output per hour of attention.
TOKENS — "processed" sums input, output, and both cache types (cache reads dominate, because context is re-read every turn). "Generated" counts output only — the text and code actually produced.
STREAMS — sessions counted by distinct transcript with at least one real exchange; parallel runs counted from sub-agent transcripts. Completion is inferred from a clean session end, not verified task success.
PROMPTS — human directives only. Claude Code writes pseudo user-messages into the transcript for its own bookkeeping (slash-command echoes, local-command output, system reminders); counting those inflated this figure by 28% in the first pass, so anything machine-generated is filtered out. Short replies like "ok" are real and kept.
REDACTION — category counts are exact and unmodified. Individual session detail, client identities, and figures are withheld by design.
HONESTY — the measured window is 32 days. The annualized row is a projection and the six-month arc is reconstructed; both are labeled as such rather than presented as measurements.
Nothing here was hand-tracked. No timer, no time-sheet, no habit app. The measurements were sitting in log files the whole time — I just had never read them. If you use Claude Code, yours are sitting there too.
Paste the prompt below into a Claude Code session. It works on anyone's logs, produces the same metrics, and takes a couple of minutes.
Analyze my local Claude Code session logs and build me a productivity telemetry report. DATA SOURCE Parse every *.jsonl file under ~/.claude/projects/ recursively. Each line is a JSON event. The fields that matter: timestamp - ISO 8601, UTC type - "user" | "assistant" | "system" message.model - which model answered message.usage.input_tokens message.usage.output_tokens message.usage.cache_creation_input_tokens message.usage.cache_read_input_tokens Files inside a subagents/ subfolder are parallel sub-agent runs, not main sessions. Write a script to parse these - there are likely hundreds of files. Do not read them by hand. METRICS 1. Agent-hours - within each session, sum the gap between consecutive events where that gap is <= 15 minutes (longer gaps are breaks). Sum sessions independently so parallel terminals add up. This is engaged agent-time. 2. Wall-hours - the union of active intervals across all sessions per day, so overlapping work is counted once. This approximates my real hands-on time. 3. Leverage - agent-hours divided by wall-hours. Above 1.0 means I ran work in parallel. This is the headline number. 4. Streams - main sessions (distinct transcripts with at least one real exchange) plus sub-agent runs. 5. Tokens - report "processed" (input + output + both cache types) and "generated" (output only) SEPARATELY. Cache reads will dominate; do not let them masquerade as work produced. 6. Tool calls, prompts issued, assistant replies, active days. 7. Model split - assistant turns by model. BREAK DOWN BY day, week, the full window, and a daily average. Show the weekly trend so I can see whether I am accelerating or plateauing. ACTIVITY LOG Extract the first real human prompt from each session (skip system text and anything starting with "<") to reconstruct what I actually worked on, then cluster it into themes. RULES - Measure, do not estimate. Every number must trace back to the logs. - Tell me plainly what you could NOT measure. These logs retain roughly 30 days, so do not imply a longer history than exists. If you reconstruct anything from another source such as git, label it clearly as reconstructed, not measured. - State the honest caveats: agent-hours are not my wall-clock hours, and "completed" can only be inferred from a clean session end, never verified task success. OUTPUT A single self-contained HTML dashboard - inline CSS, inline JS, inline SVG charts, no external libraries. Then tell me the three most interesting things the data says about how I work, including anything unflattering.
You need Claude Code — the terminal or desktop app, not the chat website. The prompt reads files on your own machine, so a browser session cannot do it. Your numbers will look nothing like mine, and that is the point: the useful part is not the total, it is the ratio and which direction it is moving.
One warning. The raw report will quote your own prompts back verbatim — which means client names, figures, and personal details. Mine did. Read it before you send it to anyone, and ask for a redacted cut if you plan to share it. This page is that redacted cut.