The board draws agent sessions on per-user lanes and derives every metric from timestamps and counts. No guesswork, no self-reporting. Here is each concept in the order the board draws it.
A solid segment is one run of the agent: from your prompt until the turn stops. Pauses of ≤ 1 min merge into the same segment, so a quick tool retry doesn't shred a run into confetti.
Idle of ≤ 10 min between runs draws as a dotted connector and counts as wait: you were there, watching the agent. Idle longer than 10 minutes is a break: the gap draws blank, counts zero wait, and the next segment starts fresh.
Taking a breather every hour fully resets the clock. That is by design: resting is not penalized. The metrics measure how effective you are in the zone, not hours online.
You can only wait on one session at a time. When several sessions idle at once, the overlapping stretch is attributed serially by resume order: the first session you return to owns that stretch, the next one counts only from that resume onward, and so on.
Colored dots mostly counted toward wait. Gray dots were mostly covered by another session's wait. The result: running many agents in parallel never inflates your wait total.
Stripes over the session color mean subagents were working: the session delegated work to parallel agents. It stays on the same track (one session, one track). Subagent time, call count, and errors are listed separately in the session popup, and subagent errors never count against the main line.
A session keeps one track from its first to its last activity. The track frees 30 min after the session's last activity, and new sessions fill from the topmost free track. A user's peak track count is their peak concurrency: how many agents they actually ran at once.
How much work one instruction buys: minutes the agent ran per prompt, shown with input size (median prompt characters) and output tokens per prompt. A high number means prompts that carry; a low number with long sessions means the engineer is steering stroke by stroke.
Output counts generated tokens only. The big TOKENS number includes cache reads (roughly 98% of it) and measures context, not output. Don't compare the two.
Prompts that just delegate to a ticket ("do PROJ-123") are excluded from the input-size median, so ticket-driven workflows aren't misread as one-word prompting.
Agent minutes divided by time with at least one agent running. That equals the average number of concurrent agents while running. Leverage 1.0× means one agent at a time, always. Leverage 2.6× means the engineer keeps multiple lanes busy while each one runs.
The run:wait bar uses average episode length, not totals. Thinking time before a session's first prompt is invisible to the data, so a totals-based share would overstate run. Totals and episode counts are shown underneath the bar for cross-checking.
errors = failed tool calls. Actions the engineer declined are excluded: that's their decision, not rework.
redundant reads = the same file re-read with no edit in between. Treat it as a noisy signal: re-reads after context compaction are legitimate.
rework = three or more consecutive edits to one file including a failure. This is the strongest of the three signals for a session spinning in place.