Telemetry: what your board can already tell you
Pekan has a new workspace tab, Telemetry, sitting between Roadmap and Timeline. It answers the questions a kanban board is uniquely placed to answer and almost never does: where work actually piles up, how long it really takes, how often it comes back from review, and how far token estimates land from reality.
The headline number on most boards will be an uncomfortable one, and that is the point. On the board this was built against, the median task sat in Review for 8.4 days across 195 completions, nearly the entire 8-day median cycle time. Every other stage was measured in minutes or hours. That single bar reframes where the delay lives: not in agents doing the work, but in the wait for a human to look at it. The slowest stage with an adequate sample is flagged as the bottleneck; a single slow outlier never earns the label, because a verdict drawn from one observation is not a verdict.
The Flow tab is built entirely from data your board already has. Every metric is derived from column-move history and the actuals agents report when they close a task, so it is dense from the first time you open it: no instrumentation to switch on, no waiting period, nothing to configure. Time in stage, throughput, cycle time, review rework rate, tokens per day split by agent, estimate versus actual, and the token-heaviest tasks are all read back out of history that has been accumulating since the board was created.
Numbers are reported the way the rest of Pekan reports them: honestly. A rate with nothing in its sample reads "No data", never "0%". Every stage bar carries the number of observations behind it. The token panels state how many completions actually reported usage (184 of 231, say), so a partially-reported board is never mistaken for a cheap one. And because those token figures are self-reported by the agent that closed the task rather than metered at the provider, they are labelled as estimates and never converted into a dollar figure. A confident-looking cost derived from a guess is worse than no cost at all.
The estimate-versus-actual chart plots on a log scale, which turned out to matter more than expected: misses on a real board span a task finishing at a twentieth of its estimate to one finishing at fifty-seven times it. On a linear scale every large miss pins to the same full-width bar and the difference between twice and fifty times disappears. The tile above it reports the median ratio rather than a share-within-a-band, because "4.2× the estimate" tells you what to multiply your next estimate by, while "7% on target" only tells you things are bad.
Alongside the view there is a new MCP tool, record_run, which lets an agent report one finished run: provider, model, outcome, and token usage. Runs launched from the desktop were already captured, but a Claude Code or Codex session driving the board from a terminal was invisible to that lifecycle, which is why the Runs tab reads empty on most boards. Agents should call it when a unit of work finishes, and should omit usage entirely when the provider did not report any: an unknown cost is stored as unknown rather than as zero. Newly scaffolded projects get this written into their agent instructions automatically.