Repo of the day: agentacct, what coding agents really cost

🔍 What agentacct is

agentacct is a Python tool (>= 3.11, macOS and Linux; Windows only via WSL) installed with pipx that does one thing: it makes coding-agent work visible. It is not a proxy, it does not intercept API calls and it never asks for a provider key: it reads, read-only, the session files the clients already write locally, imports them into a plain-file store and serves a localhost dashboard with tokens per agent, model and day, pricing-table cost estimates and tasks reconstructed with their work steps.

The project's keyword is honesty. Tokens imported from the logs are labeled `client_reported`; costs are declared pricing-table estimates, never invoices; a passing test is `Verified` evidence, while the agent's own claim (“I fixed the bug”) stays labeled `Agent reported`. And when the link between usage and work cannot be proven, agentacct shows the gap instead of inventing the attribution.

repo       mikehasa/agentacct
what       local-first dashboard: what agents did and what it cost
how        Python >= 3.11 · pipx install agentacct · dashboard on 127.0.0.1:8765
sources    Claude Code and Codex session logs (read-only) + work over MCP
extra      no account, no cloud, no telemetry, no API keys
license    MIT · ~470 stars in under a week · early alpha

⚙️ How to install it and try it safely

Installation is one pipx command plus a once-per-machine onboarding: `agentacct onboard` detects the coding-agent logs on the machine, sets up the global store, runs a first usage sync and starts the dashboard at `http://127.0.0.1:8765`. One well-documented detail: MCP servers and hooks bind at session start, so the first recorded task will come from the next agent session, not from the one that ran the onboarding.

If you want to look around before touching real data there's `agentacct demo`: a local walkthrough in a throwaway temporary store, with no keys and no paid API calls. The managed runtime is controlled with `start`, `status`, `stop` and `repair`, and if you prefer a per-repository install you can run `agentacct onboard --scope project`.

# Install (once per machine)
pipx install agentacct
agentacct onboard        # detects logs, sets up the store, starts the dashboard

# Dashboard: http://127.0.0.1:8765
# Then open a NEW agent session in any repo

# Just want to look around first? Safe walkthrough in a temporary store:
agentacct demo

🧭 How it works: two evidence streams and a labeled join

The architecture keeps two streams separate. The first is “usage truth”: tokens read from the clients' own session files, imported exactly as the clients report them. The second is “work meaning”: the sections and events the agent records over MCP while it works (`agentacct_record_section`, `agentacct_record_machine_check`), plus machine checks like test runs.

The join between the two streams does not guess: it goes through real session and transcript ids. For Claude Code, a hook installed at onboarding captures the ids at session start and on every tool call; for Codex, the link is evidenced from the client's own session logs at import time. Every attribution carries a confidence label — `exact`, `high`, `medium` or `low` — and when the proof isn't there, the dashboard shows the unattributed data instead of forcing the link.

🏠 Local-first for real: privacy as architecture

The project's sharpest choice is that there is no hosted version of anything: no cloud dashboard, no account, no automatic sync, no telemetry. State is plain local files, the dashboard binds to `127.0.0.1` and the tool never asks for, stores or echoes provider API keys. Even the monitoring is explicitly non-silent: agentacct only reads the local session files of detected clients and never watches unrelated processes started outside its integrations.

It's a stance that flips the industry default, where agent-observability tools are almost always born as SaaS. Here the question “where do the data about my development sessions end up?” has a short answer: nowhere, they stay on the machine.

🏢 Why it's interesting, for developers and SMBs

For developers, agentacct turns a feeling into numbers: how many tokens that subagent-heavy workflow really burns, how a long session compares to many short ones, which model is eating the week's budget. And the notion of evidence is precious day to day: the difference between “the agent says it fixed it” and “the test passed, and it's on record” is exactly the control you need when delegating a lot of work to the machine.

For an SMB bringing agents into its development processes, this is about cost governance and accountability. Usage-based plans make agent spend a real budget line, but without visibility it's impossible to see what drives it; a dashboard that stays in-house also avoids shipping to a third-party SaaS the metadata of development sessions — which say a lot about the code being worked on. With one honest caveat: agentacct shows pricing-table estimates, not invoices; for contractual spend, the provider's portal is the source of truth.

⚠️ Limits and caveats before adopting it

The project is explicitly early alpha and interfaces may change. Support is “per capability, not per logo”: Claude Code and Codex have the most complete observation paths today, while other clients (Cursor, OpenCode and the like) have narrower, explicitly scoped paths — the per-client matrix in INSTALL.md and `agentacct capabilities agents` tell the truth for your machine.

Transparency cuts the other way too: costs remain local estimates (there is no access to subscription invoices), tokens are whatever the clients report in their own logs, and onboarding touches the clients' user configuration — hooks and MCP in `~/.claude`, `~/.codex/config.toml` — all documented in detail together with the uninstall procedure, but worth knowing before running it on a work machine.

• Early alpha: interfaces and store may change between releases; the store has already moved path once historically.
• Estimates, not invoices: costs come from a local pricing table and are labeled as estimates; real spend is certified by the provider.
• Per-capability support: Claude Code and Codex well covered; other clients have narrower paths, declared in the matrix.
• Requirements: Python >= 3.11, macOS or Linux; Windows only via WSL.
• Touches client config: onboarding installs hooks and an MCP server in the user configuration; removal is documented.

✅ Where to start

The path I suggest has three steps. First: `agentacct demo`, to understand what the dashboard shows without touching real data. Second: the real onboarding on a development machine, followed by a few days of normal work with Claude Code or Codex — that's when tasks start filling up with work steps and evidence. Third, the most interesting read for anyone designing tools: the truth table in `docs/usage-truth-table.md`, which documents precisely what each observation path can and cannot prove.

The broader signal is that the agent ecosystem is entering its accounting phase: after the race to make agents work, comes the question of what they produce and at what cost. That one of the first serious tools to answer it is local, read-only and obsessed with data provenance is good news for how this category is taking shape.

More articles from the blog