agentacct turns coding-agent logs into a local truth layer for cost, evidence, and attribution

Coding agents are getting more useful, but the evidence around their work is still messy.

Most teams can see that an agent consumed tokens and changed files. That is not the same thing as understanding what actually happened, what the run cost, whether a machine check passed, or how confidently those facts can be tied back to a specific task. The usual fallback is screenshots, anecdotes, or whatever the terminal still happens to show.

agentacct is interesting because it treats that gap as a product problem instead of a reporting problem.

The repo reads the local session logs that tools like Claude Code and Codex already write, combines them with work records and machine checks, and presents the result in a localhost dashboard that stays on your machine. That framing matters. It means the project is not asking developers to trust another hosted observability layer before they can even inspect what their agents did.

It is trying to build usage truth, not just usage charts

The best idea in agentacct is right in the README language: the project is explicit about what it can prove, what it estimates, and where attribution is missing.

That sounds small, but it is a real product distinction. A lot of tooling in this category rushes to show neat totals and polished graphs while being vague about the quality of the underlying joins. agentacct goes the other direction. Imported token counts are labeled as client-reported, cost is labeled as a pricing-table estimate rather than an invoice, and every join between usage and recorded work carries a confidence label such as exact, high, medium, or low.

For builders, that is the part worth paying attention to. Good agent tooling should not only summarize activity. It should preserve the uncertainty around that summary so people know when to trust it and when to investigate further.

The repo cares about the work, not only the spend

Another strong choice is that agentacct tries to connect token usage to the work itself.

The README describes Tasks, recorded work steps, and machine checks that can show whether something was actually verified. That is much more useful than a plain cost dashboard. If an agent burned tokens but never produced a passing test, that distinction should be visible. If a task includes evidence from a machine check, that should also be visible.

This is where the project starts to feel more product-minded than many observability side projects. It is not only asking, "How much did the agent use?" It is asking, "What did that usage produce, and how much of the story can we substantiate with evidence rather than self-reporting?"

That is a much better framing for teams who are trying to make agent workflows accountable inside real software delivery.

Local-first is not just a privacy line here

agentacct's local-first posture also feels more substantive than a generic privacy slogan.

The dashboard binds to 127.0.0.1, the state lives in local files, and the repo is clear that there is no phone-home telemetry, no account, and no requirement to hand over provider API keys. For a tool that reads coding-agent session logs, that boundary is important.

Those logs can contain unfinished reasoning, internal paths, bug details, and operational context that many teams would never want pushed into a cloud analytics system by default. Keeping the system local changes the trust model immediately. It makes the product easier to evaluate because the default question stops being whether you are comfortable exporting sensitive workflow traces and becomes whether the local evidence model is actually useful.

That design choice also aligns with the kinds of users most likely to care. Developers adopting coding agents often already have several cloud services in the loop. A local truth layer that sits on top of existing logs is a cleaner pitch than asking them to create one more external dependency just to understand their own runs.

The confidence-label idea is quietly powerful

The confidence labels may be the most important feature in the whole repo.

One of the hardest parts of agent-heavy development is that the trail between prompt, tool action, file change, and verified result is often incomplete. Systems usually respond in one of two bad ways: either they expose raw logs and make humans reconstruct everything, or they overstate certainty and produce dashboards that look authoritative without earning it.

agentacct appears to aim for a more honest middle ground. It still performs joins across evidence streams, but it labels how strong those joins are. Missing attribution is treated as preferable to incorrect attribution.

That is a very healthy product instinct. When tools flatten uncertainty away, they encourage false confidence. When they surface uncertainty clearly, they give teams a better basis for deciding whether a workflow is ready for broader use.

The integration story is pragmatic

The repo is also smart about where it starts.

Instead of pretending to support every agent environment equally from day one, the README scopes current support by capability and calls out stronger live-observed paths for Claude Code and Codex. That kind of restraint usually makes an early project more credible, not less.

The onboarding story is pragmatic too. Install the package, run onboarding from a repo root, let it detect local coding-agent logs, and start a dashboard. There is even a demo mode for people who want to understand the flow before pointing the tool at their real data. That reduces friction without hiding the fact that the project is still alpha.

I also like that the documentation spends time on operational edges like setup, lifecycle commands, capability matrices, and truth tables. Projects that document the boring parts well tend to understand their real job better than projects that only optimize for the hero screenshot.

Where builders should stay realistic

There are still obvious constraints.

The value of agentacct depends on how much reliable evidence the supported clients expose locally, and on how consistently the surrounding integrations record meaningful work steps and checks. Even with good joins, no dashboard can manufacture certainty that the source systems did not provide.

The repo is aware of that, which is part of why it stands out. It does not pretend the current state of agent observability is solved. It tries to make that state inspectable and usable without hiding the rough edges.

That is a more durable place to start. Teams do not need another glossy AI control panel nearly as much as they need a trustworthy local record of what the agents actually did, what it likely cost, and where the evidence trail breaks.

Why this repo is worth watching

agentacct is worth watching because it treats coding-agent accountability as a systems design problem.

It combines local session logs, work records, machine checks, and confidence-aware joins into a product surface that helps developers inspect agent work without surrendering their data to yet another service. That is a practical, grounded contribution to the current agent tooling wave.

If more open-source projects in this space adopt the same standard of honesty about proof, estimates, and missing attribution, the whole category gets better.

Repo

GitHub: https://github.com/mikehasa/agentacct