agentacct: Work Receipts for Claude Code, Codex, and OpenCode Sessions

The gap agentacct fills between agent logs and what you can prove

Coding agents already write session logs to disk. Those logs are awkward to read: each agent uses its own format, and none of them answers the question you actually have after a long session, which is what the agent did, what it cost, and whether anything independently confirms the work. agentacct is built for that question. It targets people running Claude Code, Codex, OpenCode, or Hermes locally, typically solo developers or small teams who want a per-task audit trail without shipping transcripts to a hosted service.

The design decision that shapes everything else is the separation of decision from evidence. The README states it plainly: an agent reporting done never raises the evidence bar. Completion claims land under a Reported tab, and Verified is reserved for tasks where every live check passes and postdates the newest recorded work. That is a stricter rule than most cost dashboards apply, and it means a receipt can legitimately show a finished-looking task that is not verified.

How the store is built: log ingestion, joins, and evidence tiers

The data flow starts with read-only ingestion. agentacct detects the local coding-agent logs on your machine, imports them into a global store, and joins usage records with the work each session records as it goes. Every join between usage and recorded work carries a confidence label (exact, high, medium, or low). When a link cannot be proven, the README says agentacct shows the gap rather than a guess, and absence is a named state rather than a dash or a zero.

Evidence is graded by independence from the agent that did the work. The README gives the ordering: an agent's own claim, then a self-reported check, then a hook-observed exit code, then CI. That tier travels as a pip shape everywhere it appears (hollow, half, filled, ringed), so the same visual vocabulary shows up in the receipts workbench, in a task's step list, and in the terminal dashboard. Cost figures carry a similar marker: a tilde prefix marks an estimate, and a bare dollar sign is reserved for reported figures.

Two components sit behind the interface. Onboarding starts a managed background sync and a local JSON API bound to 127.0.0.1:8765, described as the machine-readable lane that native shells and scripts poll. The macOS app, the TUI, and that API all render the same Task-primary view, which is why the README can claim parity across the three surfaces.

Installing agentacct and reading your first Work Receipt

The CLI needs Python 3.11 or newer on macOS or Linux. Windows is supported only through WSL. The README gives pipx as the primary path, with uv as an alternative and a plain venv fallback documented in INSTALL.md.

pipx install agentacct
agentacct onboard   # once per machine (global by default)
agentacct tui       # the live terminal dashboard

Onboarding runs once per machine. By default it writes zero files into your repository, detects your local agent logs, sets up a global store, and runs a first usage sync. If you would rather keep state per project, the README documents `agentacct onboard --scope project` instead.

One sequencing detail matters: MCP servers and hooks bind at session start, so the session that ran onboarding cannot become the first recorded Task. Open a new agent session in any repository after onboarding finishes.

To read a single task as an audit record outside the dashboard, the README gives this command:

agentacct receipt <task>

Onboarding also starts the local JSON API on http://127.0.0.1:8765, which is what the native app and any scripts you write poll. `agentacct stop` stops it. If you prefer a native window, the signed and notarized macOS app bundles the CLI, requires macOS 14 or later, and on first launch installs the bundled CLI and instruments the agents it finds. The README also offers a paste-into-your-agent install prompt, which the repository truncates; the full text lives in the README itself.

Where the evidence model gets in your way

The verification rule is the feature and the friction. A task only reads Verified when every live check passes and postdates the newest recorded work. If your workflow has no CI and no hook-observed exit codes, most of your tasks will sit at the lower tiers permanently, and the dashboard will look pessimistic about work that is in fact fine. That is the intended behaviour, but it means the tool rewards teams with machine-checkable pipelines far more than teams that verify by reading a diff.

There are harder constraints. Windows is supported only via WSL, so a native Windows shop is out. The package classifier is Development Status 3 - Alpha, which is consistent with the release cadence: v0.10.0, v0.10.1, and v0.10.2 all landed within three days in late August 2026, and pyproject.toml already carries version 0.10.9. Rapid minor releases at 0.x are a normal sign of churn, not a defect, but you should expect the CLI surface and the store schema to move.

The plan-consumption feature is explicitly beta. It estimates what fraction of a weekly Claude plan each task consumed, learning the rate from your own recorded limit history, and shows a figure only once it can calibrate to your account. Until then it says it is still calibrating. If you want that number to be exact today, it will not be.

agentacct against OpenTelemetry-style agent tracing

The obvious alternative is instrumenting your agents with OpenTelemetry spans and shipping them to a collector, or using a hosted LLM observability product that ingests traces and shows cost per call. The difference in approach is where the evidence comes from and where the data goes. Trace-based tools record what the agent process reports about itself, and they typically assume a backend. agentacct reads logs the agents already wrote, keeps state in plain local files, and treats the agent's self-report as the weakest tier rather than the primary record.

That trade cuts both ways. A trace pipeline can capture spans from services that write no local session log, and it can aggregate across a fleet of machines. agentacct is per-machine by construction: onboarding sets up a global store on one host, the only listener is the loopback API, and there is no cloud sync. If you need a shared view across ten developers, agentacct as documented does not give you one, and you would be exporting from the local JSON API yourself.

Licence, maintenance cost, and what upgrades involve

agentacct is MIT licensed, and pyproject.toml declares the licence with an SPDX identifier plus a separate LICENSE file. MIT is permissive, so the practical constraint is not the licence text but the absence of any warranty, which is standard. Nothing in the repository suggests a dual licence or a commercial tier. This is a description of what the files say, not legal advice.

The last push to the default branch was on 2026-08-28, and the most recent release listed is v0.10.2 on the same date. The repository is not archived. Maintenance cost for an adopter is mostly upgrade risk. The TUI pins textual to >=8,<9 with a comment explaining that the cap exists so a breaking Textual release cannot silently break a PyPI install, which is a reasonable guard but also a signal that the UI layer is version-sensitive. The sdist deliberately excludes tests, and the pyproject comment notes that a shipped suite would lack conftest.py and its store pin and real-store tripwire, so running pytest from an unpacked sdist is not the intended path. Install from PyPI or the macOS app, keep the store backed up as plain files, and read CHANGELOG.md before each minor bump.

Editorial conclusion

Adopt agentacct if you run Claude Code, Codex, OpenCode or Hermes on macOS or Linux and want per-task cost and evidence without sending logs anywhere. Skip it if you need Windows-native support, a hosted multi-user view, or a stable API surface while the package is still classified 3 - Alpha. Before trusting a receipt, check the Sources pane for import health, confirm the cost basis marker on each figure, and read the evidence tier rather than the lifecycle tab.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes