I built yald, Yet Another LLM Dashboard, because I wanted to understand where my coding-agent tokens were going. The records were already on my machine, but a useful explanation needed more than a total. I wanted to compare activity, see cache usage, and understand the shape of a build session. The tool reads local records without changing the source logs.
The first difficulty is that the sources describe different events. An OpenCodex request ledger can include operational information about a request. A Claude Code transcript provides a different view of a conversation and its usage. Putting both in one dashboard requires a common representation, but it does not make the original records equally informative.
Missing is a value worth preserving
Claude transcript-derived rows do not supply latency, time to first token, quota, or failure fields. Those metrics must remain unavailable for that source. Filling them with zero would make the chart tidier while telling the wrong story: an unrecorded request duration is not an instantaneous request. The same distinction applies to a missing failure record and a confirmed successful call.
Cache activity needs that context too. A large token total can include repeated cached input rather than an equally large amount of new work. Breaking categories apart makes the figure more useful for investigating a workflow. It still does not turn token volume into a measure of software quality, productivity, or the value of a completed project.
Make the report’s boundary visible
- Choose an explicit half-open time window: include its start and exclude its end.
- Name the timezone so a day or build phase has a reproducible meaning.
- Keep source filters and phase totals consistent with the overall report.
- Redact before sharing and prefer curated aggregates to raw conversations.
Portable reports make this useful beyond the live dashboard. I used the tool for a published retrospective on building The Commons, where phases of the day gave the usage a story to follow. This article keeps the explanation at the aggregate level. A report should let someone inspect how a number was assembled without exposing the prompts, project details, or identities inside the underlying sessions.
The public v0.1.0 GitHub preview includes a packaged artifact. The source and preview are the concrete things to point to; registry publication is a separate step. For me, the useful result is a dashboard that can answer a question and show where its evidence stops. That boundary is part of the product, just as much as the chart.