Where the time and the tokens went

Where the numbers come from. The coding agent writes every session to disk as it goes - every prompt, every tool call, and the exact token usage the model reported for each reply. This page is an aggregate of 1,141 of those session files and 2,301 sub-agent transcripts. Nothing is sampled and nothing is estimated.

“New tokens” versus the big number. 77.5bn tokens were read or written in total, but 76.1bn of that is cache reads - the same conversation being re-read on every turn, which is cheap and says nothing about how much work happened. The charts use new tokens: 1.0M in, 234M written, and 1.1bn of context cached for the first time. That is the honest measure of effort, and it is about 2% of the raw total.

Hours. Time is counted gap by gap between consecutive records in a session, and any gap longer than 5 minutes is treated as the session sitting idle - a window left open overnight books five minutes, not nine hours. Agent hours add those up per session. Wall-clock hours merge overlapping sessions first, so they measure the developer's actual day. Both are published, because two or three sessions commonly run at once and quoting only the larger number would overstate this by about 2.5×.

How work is filed under a part of the game. Each prompt, plus everything the agent then did because of it, is scored against a list of terms for each area - proper nouns and asset names weigh heavily, loose words barely at all, and what the developer actually typed counts three times what the agent's tool calls do. Anything that does not clear the bar is filed under cross-cutting, which is 8.9% of the total.

How wrong is it? Measurably, and more than you would like. An adversarial audit sampled 40 classified segments, recovered the original prompt for each and judged it: the area is right about three times in four. These are the specific weaknesses, and they are quoted as a share of tokens rather than of segments, because the charts are drawn in tokens and the hardest calls are the biggest pieces of work - quoting segment counts made the classifier look roughly twice as reliable as it is.

• 40% of the spend was a close call - the runner-up area scored within a quarter of the winner.
• 48% was decided by the agent's file paths alone, because the prompt itself named no subject. The prompt outweighs tool calls three to one, but only when it says something.
• 16% matched nothing before the next rule ran.
• 7% inherited its subject from the prompt before it, because a great many prompts are “carry on”, “yes”, “now the other one”. Only a prompt the classifier itself pinned may pass its subject on, and only within half an hour - an earlier version let those chains run fourteen deep and drift three days from the last real subject.

So: the shape of this chart is trustworthy and the ordering of the big areas is real. An individual row is not gospel, and a session that jumped between three subjects is filed under one of them.

The gap in late August is a usage limit, not a holiday. The busiest day in the whole record is immediately followed by three days of nothing. That is not a break and not a hole in the data: the weekly quota ran out, and work resumed the morning it reset. It is the clearest thing on this page - build at that rate and you do not run out of ideas, you run out of allowance.

What it does not measure. The record starts 13 August 2026, which is as far back as the stored transcripts go - the project is older than that, and the devlog reaches back further than this page does. Transcripts get pruned eventually, so from now on each day is archived as it is measured and the chart keeps its own history. It counts the agent's time, not the developer's: hours in Blender, in the editor, or playing the thing to find out what is broken are not in here. And a token is not a pound - this runs on a subscription, so these counts measure work done, not a bill.

The full dataset behind this page is tracker.json, and the charts are drawn with Chart.js, served from this site rather than a CDN.