Token usage dashboards for coding agents, compared

the short version

There are four different places to find out what a coding agent has spent, and they disagree with each other on purpose, not by mistake. Each one trades granularity, latency and privacy differently, and none of the four is strictly better than the others. The right choice depends on which question you are actually asking: what did this session cost, what did this week cost, or what is being spent right now.

What follows is each category on its own terms, then a short answer for which one to reach for and when.

three axes that matter

Every one of these tools can be placed on the same three axes, and doing that first makes the rest of the comparison mechanical rather than a matter of taste.

• Granularity. What is the smallest unit it can tell you about: one API call, one session, one day, one billing period? A tool that only reports totals cannot tell you which of four parallel agents burned the money.
• Latency. How long between a token being spent and that spend showing up somewhere you can see it? Instant, on the next command you run, or next-day after a batch job on a vendor's servers.
• Privacy. Does the data required to compute the number ever leave your machine? A local file read and a network call to a third party are different trust boundaries even when they produce the identical figure.

None of the four categories below wins on all three. That is the actual shape of the decision, not a gap waiting for a fifth tool to close.

1. the built-in cost command

Most agent CLIs ship a command that reports what the current session has cost, reading it straight from state the process already holds in memory. Claude Code has /cost; other CLIs expose the equivalent under a usage or stats subcommand.

> /cost
Total cost:            $2.17
Total duration (API):  4m 32.1s
Total duration (wall): 11m 8.4s

This is the fastest possible answer to "what has this session cost so far" because there is no file to read and no request to make. It is also the narrowest: close the session and the number is gone with it, and there is usually no way to ask it about yesterday, about a different project, or about four sessions at once. It answers exactly one question well.

2. local transcript parsers

Claude Code and comparable CLIs write a JSONL transcript per session to disk, and that transcript contains every token count and model name needed to reconstruct the bill. A local parser reads those files directly and computes spend without asking anything of a server. The mechanics of doing this correctly are involved, since five token classes price differently and transcript lines duplicate, but the read itself is local from start to finish.

npx claude-code-spend --by day --by project

The trade against the built-in command is speed of access: you run a command instead of getting a number for free inside the tool you're already using. The gain is scope. A local parser can answer "what did last week cost across every project," which the session-scoped command structurally cannot, and it does so without a single byte of transcript content leaving the machine.

What it still cannot do

It is a report, not a display. You run it and get a snapshot as of that moment; it does not sit in view while an agent is still working. For a running total, you would run it in a loop, which is a workable habit and also exactly the gap the next two categories close.

3. vendor-hosted dashboards

Some tools upload usage data, and sometimes more than usage data, to a hosted service that renders a dashboard: charts by day, by team member, by project, often with account-wide rollups a local tool cannot produce because it only sees one machine's files.

The aggregation is the genuine advantage here: a team lead comparing spend across five engineers' machines cannot get that view from any local tool, because no single local tool has visibility into another person's disk. The cost is that you are trusting a third party's ingestion pipeline and retention policy with data about your work, which is a real decision and not a formality, particularly on a codebase under an NDA.

4. an always-visible meter

The fourth category is a number that sits in view continuously while an agent runs, most naturally a menu-bar app rather than a browser tab you have to remember to check. This is the only one of the four that can influence a decision before the spend happens rather than reporting it after, since a dashboard you have to open has already lost the moment.

The mechanism is the same local read as category two, watching the same transcript files for changes and updating the display as new lines land, rather than waiting for you to run a command. That keeps the privacy property of a local parser while adding the immediacy a report cannot have: granularity down to the individual agent, latency close to the write itself, and nothing sent anywhere to get it.

Skribbl is built in this category: a menu-bar app and canvas that shows live spend per agent while several are running side by side, reading local transcripts the same way the open-source parsers do. Try it, or see how the meter works.

which one, when

None of these replace each other, and most people who run agents daily end up using more than one.

• Checking one session you just ran. The built-in command. It is already there and it is instant.
• Reconciling last month's spend, or auditing a specific project. A local transcript parser. It has the full history and the granularity to break it down.
• Comparing spend across a team. A vendor-hosted dashboard, accepting that the data leaves individual machines to make that rollup possible, and reading the vendor's retention terms first.
• Watching several agents run right now without babysitting terminals. An always-visible meter, because it is the only category built to be looked at while the money is still being spent rather than after.

The three axes trade against each other consistently: broader scope tends to cost either privacy, by leaving the machine to aggregate, or immediacy, by batching into a report you have to go open. Picking a tool is picking which of those two you would rather give up for the question you are actually asking today.