22 billion cached tokens read back. 86 million output tokens. 89,000 tool calls. 315 hours of active session time, spread across a dozen projects I could no longer keep straight in my head.
I had no way to see any of it. From inside a Claude Code session you cannot tell which project consumed the most tokens, how much work your subagents did while you were not watching, or whether a quick refactor turned into a six hour day.
So I built Claude Lens. A local, offline dashboard that reads your Claude Code history and shows you where the work went.
I built almost all of it with orchestrated agents. Then I pointed it at my own data, and it found eleven bugs in the first few minutes that 1,200 passing tests never caught.
What it actually shows
Tokens, by model and by project. The metric I use most is cache read ratio. 99.9% of my input tokens came back from cache instead of being re-sent, which says more about how my sessions are structured than any dollar figure does.
Work rhythm. When I actually work, how long sessions run, which days turned into marathons. One day hit 23 hours and 40 minutes of active time. I did not need a dashboard to feel that. Seeing it plotted is still clarifying.
Subagent activity. This is the part I could not get any other way. When an agent spawns subagents, that work is invisible from inside Claude Code. Claude Lens draws it as a timeline. Each subagent is a bar, positioned where it ran, as wide as the time it took. The screenshot below is the execution trace of the agents that built the app: story-implementer, story-scoper, story-reviewer, and general-purpose, orchestrated under one main loop.
The whole flow in one picture. Which projects fed which models, and which models drove which tools and skills.
Per project effort. Every project is a card: sessions, output tokens, tool calls, active time, and a sparkline of files touched. The detail I did not expect to need is grouping. Two of my projects are the same repo I moved between folders, so Claude Code saw them as two. The app lets me say they are one, and the history stitches back together.
What is installed versus what I use. Over time I accumulated skills, agents, and CLAUDE.md files across projects and lost track of what was pulling its weight. The Harness Manager maps them per project and flags the dead weight: a skill with zero invocations, an empty CLAUDE.md with a full backup beside it.
What it will not do is offer a one click delete on unused. That judgment is only as good as the history it can see, and deleting a skill is not something to make easy. It shows me. I decide.
The rule the whole thing is built on
The app reports. The person decides. That line settled most of the design arguments I had with myself while building it.
It is why the Harness Manager flags unused skills and stops there. It is why the two folders holding one repo only merge when I say they are one project. And it is why no number in the app is allowed to be plausible and wrong. A dashboard you cannot trust is worse than no dashboard, because a wrong number gets acted on and a missing one gets questioned. Every metric is defined once, in one place. Estimates are labeled as estimates. Incomplete data is marked incomplete instead of zero filled.
The cost figure is the clearest case. I pay a flat monthly subscription, and the dashboard does not know that. What it shows is a modeled equivalent: what the same token volume would have cost at published API rates in effect on the day the tokens were used. Roughly $18,000 across the whole history. That is a sense of scale, not a bill, and I have no way to reconcile it against what Anthropic actually spends serving me. It is in the app because token volume is easier to reason about with a unit attached, it is labeled as an estimate, and records it cannot price are shown as unpriced rather than rounded to zero.
If you build with agents, that is the lesson worth taking. Synthetic fixtures only test the failure modes you already imagined. Real data finds the ones you did not. Get the real thing in front of real data as early as you can.
How it is built
Local and offline. It reads your ~/.claude folder and writes to an embedded SQLite database on your machine. The only network call in the app is an optional, user triggered price table refresh. No telemetry.
It reads your history and never modifies it in place. Deletes and moves happen only through explicit, confirmed, backed up, undoable actions.
It retains history after Claude Code clears its own, so long term totals do not silently shrink.
Electron, React, TypeScript, SQLite. macOS, source only. Clone, npm install, npm run dev.
Who it is for
If you run long agentic coding sessions and have wondered where all of it is actually going, this is that answer on a second monitor, updating while you work.
It is open source. If you are tracking your own agent runs some other way, I would like to see how you are doing it.