Claude Code is the best terminal tool I have used in years, and it has a strange blind spot: it remembers everything and shows you nothing.
Every session you run gets written to a JSONL transcript under ~/.claude. Every prompt, every response, every tool call, every token count, every model switch, every sub-agent it spawned. Months of it. And the only window the CLI gives you into that archive is /cost, which tells you about the session you happen to be sitting in right now.
So you end up with a monthly invoice and no way to connect it to anything you could actually change. Which model is that number? Which project? Was the eight hour autonomous run worth what it cost? Is that skill you installed last week making things better or quietly doubling your tool errors?
The data to answer all of that is already on your disk. It is just unreadable. A week of serious use is hundreds of megabytes of nested JSON that nobody is going to open.
Agento reads it for you. It is a single Go binary, MIT licensed, free, and it runs entirely on your own machine. No account, no API key, no server, nothing uploaded. It reads ~/.claude, caches what it finds in a local SQLite file, and gives you a dashboard.
One note before the screenshots: everything shown here comes from a generated sample dataset, not from a real machine. Your numbers will look different anyway. What matters is which questions the dashboard can answer.
Two commands
brew install shaharia-lab/tap/agento
agento web
On Linux or Windows, grab the binary for your platform from GitHub Releases, put it on your PATH, and run the same command. It starts on port 8990 and opens your browser.
There is no configuration step. Agento authenticates through the Claude Code CLI you already have installed, so if claude runs in your terminal, Agento works. The first scan takes a while on a large history, because it is reading every transcript you own, and it runs in the background while you use the app with a progress counter. After that it updates incrementally.
The chart that changes how you think
Start with cost broken down by model, and put tokens broken down by model right next to it.
They rank the models in different orders. Often in completely opposite orders.
A cheap, high volume model can dominate every usage chart you look at and still be a rounding error on the bill. A premium model you reach for a handful of times a day can be most of what you actually pay. On the sample corpus I built for these screenshots, one backend accounted for the overwhelming majority of tokens and a small fraction of the cost.
That gap exists because "tokens" is not one thing. Fresh input, output, cache reads and cache writes bill at wildly different rates. Any tool that shows one token number and multiplies it by one price is telling you something untrue.
Agento splits the four apart and prices each one per assistant message, at the model that message used and the date it was sent. Not per session at the first model it saw. That distinction matters more than it sounds like it should, because a long session drifts across models and a rate can change mid month.
The practical rule: read the cost chart, not the token chart. Almost everyone instinctively reads the token chart.
Caching is most of the economics
The insights page leads with what prompt caching saved over the period: what the same work would have cost if every cached token had been billed as fresh input. It is explicitly labelled an estimate, because it prices a counterfactual, but the order of magnitude is not subtle.
Which means the habits that break caching are expensive habits, and they all look like good hygiene:
- Killing a session and starting fresh because it feels cleaner
- Restarting after every small change
- Splitting one task across five short sessions instead of one long one
Every restart re-pays for context you already bought. Nobody thinks "I'll start a fresh session" is a spending decision. It is one.
There is a per model view of the same thing, which turns out to matter if you point Claude Code at a non-Anthropic backend. Some of them serve very little from cache, so context gets re-billed as fresh input on every turn. That is a model selection consideration with nothing to do with the model's headline price, and it is invisible until you see cache hit rate charted per model.
Is your delegation actually saving anything?
If you lean on sub-agents, this is the one to check.
Delegation is supposed to be a cost lever: the orchestrator runs on a strong model, the searching and reading and summarising goes somewhere cheap. But sub-agents inherit the parent's model unless you say otherwise, so it is entirely possible to believe you have routed the grunt work to a cheap model while every delegated run quietly uses the expensive one.
You can only see this if the tool credits a sub-agent's tokens and cost to the model the sub-agent ran on, rather than to the model that delegated. Agento does, and it was a deliberate fix rather than an accident of design. Crediting delegated spend to the delegating model made the one chart that should answer "is delegation routing work to cheaper models?" structurally incapable of answering it. On the reference corpus, 18.3% of delegated tokens were being charted under the wrong model before that was corrected.
Are you getting faster, or just busier?
This is the part I find hardest to answer on instinct, and it is where the tool earns its keep.
The metrics worth watching, all shown against the equivalent preceding period so you read direction rather than magnitude:
- Turns per session. How often you had to step in. Fewer turns for the same work means your prompts and agent definitions are carrying more weight.
- Steps per turn and longest autonomous chain. How far the agent gets before it needs you. This is the number that distinguishes supervising from babysitting.
- Tool calls per session and tool errors per 100 calls. The error rate is an early warning signal, and when it jumps it is almost never the model. It is a skill, a stale instruction, or a badly configured MCP server.
- Active duration. More on this below.
- Your own response time, charted next to how long you waited on Claude. That one is humbling.
Underneath sit breakdowns by tool, by skill, by plugin, by MCP server, by MCP tool and by sub-agent. That is how you find out which of your skills is burning the most tool calls, which is a very direct route to rewriting one and deleting another.
The insights page is marked experimental, and the app says so plainly, because several of the formulas are heuristics. The trends are informative even where the absolute numbers are arguable.
Four things that were harder than they look
Since this is dev.to, the implementation details are probably more interesting than the feature list. These are the four places where the obvious approach produces a number that is confidently wrong.
Duration has to mean active duration. Claude Code sessions are resumable, so the span from first event to last event counts every idle day in between. One session picked up after 28 days carried 82% of the dashboard's average duration figure: 476 minutes shown against a 17 minute median. So Agento sums the gaps between events and ignores any gap longer than a threshold you configure (10 minutes by default, adjustable from 1 to 240 because the right answer depends on how you work). The raw span is still stored and still shown as secondary context, because "first seen to last touched" answers a different, real question.
Pricing has to be effective dated, and honest about what it doesn't know. The catalog is editable from the Settings UI and ships with rates for several providers beyond Anthropic, because plenty of people point Claude Code at Kimi, GLM or Qwen. Cache creation is split by TTL, since the five minute and one hour tiers bill differently. Qwen tiers its pricing by context length, so a rate can carry bands. And a model with no published rate is reported as unknown rather than being quietly priced as something similar, so a partial total is disclosed as a floor instead of presented as complete. A deliberate zero, like a synthetic or embedding model, is a separate flag from an unknown one.
Cache hit rate needs exactly one definition. There used to be two in the codebase: cacheRead / (input + cacheRead), which pins near 100% and tells you nothing, and cacheRead / (cacheCreation + cacheRead), which sits around 74%. The one that survived counts the read share of every input side token, fresh input plus cache writes plus cache reads, because it is the only version under which a backend with no prompt caching scores 0 rather than being excused from the chart.
Activity charts have to bucket across a span. The heatmap counts a session in every hour between its start and its last activity, sharing its tokens out by overlap. The first version bucketed at the end timestamp, which quietly turned "activity by hour of day" into a map of when work stopped.
None of these are exotic. They are just the difference between a dashboard you can act on and a dashboard that looks plausible.
Drilling into one session
The dashboards tell you that something changed. To find out why, you open the session.
The list is searchable and filterable by project, model, date and cost, paged in SQL rather than in the browser so it stays usable at thousands of sessions. Every row carries the branch, the permission mode, and any pull requests that session touched.
Open one and you get the full transcript plus that session's own metrics, and a journey view: a step by step timeline of every message, tool call and result in order, with each sub-agent's steps nested underneath the Task call that spawned it.
That nesting is what makes a long autonomous run legible. When a four hour session costs three times what a similar one did, the journey view usually shows you which delegated branch went sideways in about a minute.
Privacy, since it's the obvious question
Claude Code transcripts contain your source code and your prompts. Any usage analytics tool that uploads them is a non-starter for most people and every company.
Agento is a single binary that runs on your machine. It reads ~/.claude, writes a SQLite cache to ~/.agento/agento.db, binds to 127.0.0.1 by default, and has no server component and no account. If there are projects you would rather keep out of the numbers entirely, you can hide them from all reporting in Settings, and hiding is not deleting, so unhiding is instant.
It also indexes multiple Claude config directories, which matters if you keep a work account and a personal account separate. Analytics reads the union of them; a given run targets exactly one.
The rest of it
The dashboards are the part I open every week, but Agento is a broader tool. It also does agent building with an explicit tool allowlist, persistent multi-chat conversations streamed over SSE, cron scheduled agent runs with job history, Telegram triggers, and in process MCP integrations for Google, GitHub, Slack, Jira and Confluence. All of it in the same binary. If that is more interesting to you than the analytics, the README covers it.
Try it on your own last thirty days
brew install shaharia-lab/tap/agento
agento web
You already have the data. It took me one evening of looking at mine to change five things about how I work, none of them dramatic, all of them compounding: keep sessions alive longer, compare models on cost rather than token volume, verify where delegated work actually goes, split long autonomous runs, and treat a rising tool error rate as a prompt bug rather than a model problem.
The repo is at github.com/shaharia-lab/agento. It is MIT licensed and free. If it turns out to be useful, a star genuinely helps other people find it.
I would be curious what surprises you in your own numbers. The cost versus tokens gap is the one that gets everybody.
Top comments (0)