ClawMetry reads the session files your coding agents already write

The problem is a long agent run that looks busy and is not

The README opens with the failure mode in one sentence: an agent can make a hundred tool calls without making progress. That is the gap ClawMetry is aimed at. A coding agent that loops, retries a failing command, or burns context on the wrong file looks identical to a productive one if all you watch is the terminal scroll. The project's answer is to read the session files and logs the agents already write, then put the timeline, the tool calls and whatever token and cost data the runtime exposes into a single view. The intended user is someone running coding agents on their own machine or fleet who wants to tell a working run from a stuck one without adding an SDK or changing how the agent runs. It is not a hosted APM product, and the README is explicit that it reads the files read-only and changes nothing about how the agents execute.

No SDK, no instrumentation: it parses what the runtime already leaves on disk

The architecture described in the README is a reader, not an agent of its own. ClawMetry locates the session files and logs each runtime writes, parses them, and normalises the result into a common dashboard model. The stated data flow is: agent writes session file, ClawMetry reads it read-only, dashboard renders the timeline, tool-by-tool replay, token and cost breakdown, and trajectory signals such as looping and repeated failures. Because there is no instrumentation step, the ceiling on what you can see is set by the runtime, not by ClawMetry. The README concedes this directly: runtimes expose very different data, and some publish no cost at all, with docs/compatibility.md documenting which is which per runtime. The project also ships an interceptor for agents built on an SDK rather than a named runtime, described in docs/SDK_TRACKING.md, which is the one path where tracking is not purely passive. The dashboard covers sessions and transcripts, cost and tokens per runtime, model, session and day, a live flow diagram, a reasoning and tool-call event stream, context-window utilisation with compaction versus forced overflow, memory and skills loaded, health and logs, alerts routed to Slack, Discord, PagerDuty, Telegram or Email, and approvals.

Install is one pip command and one binary name

The documented install is `pip install clawmetry && clawmetry`, which starts a local server at http://localhost:8900. There is no config file mentioned in the README and no key required for the open source path. If the machine has no agents installed yet, `clawmetry --sample` opens the dashboard on three labelled synthetic sessions, which is the honest way to evaluate the UI before you have real data. The `clawmetry connect` subcommand is the only thing that sends session data off the machine, and the README says it is opt-in. Two things run by default and are opt-out: an anonymous install ping and a PyPI version check. Neither carries session content according to the README, and every destination is inventoried in docs/EGRESS.md, which the project says was rebuilt from a wire capture rather than from reading comments. That last detail is worth crediting, because egress documentation assembled from source comments tends to drift from what the binary actually does.

The free and paid split is the first thing to check

This is the part of the README most likely to disappoint a reader who skimmed the headline. The open source `pip install clawmetry` reads OpenClaw, NVIDIA NemoClaw and Goose with no account, no key and no network call. The other 27 runtimes, including Claude Code, Cursor, GitHub Copilot, OpenAI Codex, Gemini CLI and Aider, are read by a closed-source companion package called clawmetry-pro, which arrives with a 7-day trial or a paid plan. The README points to docs/ENTITLEMENTS.md for the exact split. The description on the repository says 30 runtimes while the README body says 31 and the topic list and runtime list both enumerate 31 entries, so the count is inconsistent across surfaces. None of that is a defect in the software, but it means the phrase zero-config observability for 30 AI agent runtimes describes the paid product more accurately than the MIT-licensed one. If your fleet is Claude Code plus Cursor, the open source package is a viewer for three runtimes you may not use.

Observing a tool call is not the same as blocking it

The README raises this itself as one of two limits worth knowing before judging the output: observing an action is not the same as being able to block it, and docs/APPROVALS.md documents which controls are real per runtime. The approvals feature is described as pausing risky tool calls before they run and approving from your phone, but the README does not claim that works uniformly across all 31 runtimes, and the pointer to a per-runtime document implies it does not. That is the correct way to frame it, and it is also the boundary that matters most for anyone buying this as a governance tool rather than a dashboard. A runtime whose session file is written after the tool call completes can be observed but not interrupted. If blocking is the requirement, the per-runtime approvals document is the deciding artefact, not the feature bullet.

Where a passive log reader is the wrong tool

ClawMetry cannot show you what the runtime never writes down. The README is candid that some runtimes publish no cost data at all, which means the cost and token views degrade to empty or partial panels depending on which agent you are looking at. Context blowout has the same shape: the feature page documents a per-runtime map of what the project cannot see, which is an admission that the window-utilisation view is incomplete on some runtimes. If your agent is a custom loop that writes no session file and you do not route it through the SDK interceptor, there is nothing to read. And if you need real-time enforcement, budget caps that actually halt a run rather than alert on it, or audit-grade retention with a defined schema, a log-tailer is the wrong category of tool. Alerts here are routed to Slack, Discord, PagerDuty, Telegram or Email, which is notification, not enforcement. The project is also releasing at a pace visible in the release list, with three versions inside roughly six hours on 2026-09-10, which is worth noting if you pin dependencies for stability.

OpenTelemetry and Langfuse solve a different half of the problem

The obvious comparison is OpenTelemetry, which is listed in the repository topics and is the standard answer for LLM observability. The difference is where the data comes from. OpenTelemetry expects your application to emit spans through an SDK and an exporter, so you get a schema you control and a backend you choose, at the cost of instrumenting the code. ClawMetry inverts that: it takes the agent's own session files as the source of truth, so there is nothing to instrument, but the schema is whatever each runtime happens to write and the coverage varies by runtime. Langfuse sits closer to the OpenTelemetry model, a hosted or self-hosted backend that your code calls into, with tracing built around your application rather than around third-party agent binaries. If you are building the agent, OpenTelemetry or Langfuse give you consistent, queryable traces. If you are running other people's agents and cannot modify them, the file-reading approach is the only one that works without a fork. The two are not substitutes, and a team running both custom agents and off-the-shelf ones may end up with both.

MIT licence, a pro companion, and a fast release cadence

The repository is MIT licensed, which permits commercial use, modification and redistribution of the open source package. That licence does not extend to clawmetry-pro, which the README describes as closed source; the two are separate artefacts with separate terms, and docs/ENTITLEMENTS.md is where the project draws the line. Nothing here is legal advice, and anyone embedding ClawMetry in a product should read the entitlement document and the licence text rather than rely on a summary. On maintenance cost, the visible signal is the release list: v0.12.857, v0.12.856 and v0.12.855 all landed on 2026-09-10, with the last push to main at 13:58 and the newest release at 14:01. A version number in the 800s on the patch position suggests a high-frequency release process, which cuts both ways. You get fixes quickly, and you also inherit a moving target if you pin versions or vendor the dashboard. The repository is not archived and carries a security policy and an OpenSSF Scorecard badge, both of which indicate an active project rather than a dormant one. What the supplied material does not tell you is the upgrade path between minor versions, whether the session-file parsers break when a runtime changes its format, or how much of the parsing logic lives in the closed companion. Those are the questions to ask before standardising on it.

Editorial conclusion

Adopt ClawMetry if you run OpenClaw, NVIDIA NemoClaw or Goose and want a local dashboard without writing instrumentation code, or if you are willing to pay for the clawmetry-pro companion to cover Claude Code, Codex or Cursor. Do not adopt it expecting the open source package alone to monitor those 27 runtimes. Before committing, check docs/ENTITLEMENTS.md for the exact free versus paid split, docs/compatibility.md for which runtimes publish cost data at all, and docs/APPROVALS.md to confirm whether the runtime you care about supports blocking a tool call or only observing it.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vivekchand/clawmetry on GitHub