pkg.soopen package index
← All stories

Claudoscope and the missing view of agent work

Session viewers, usage reports, and runtime guards expose different parts of an AI coding workflow; the useful stack begins by keeping those boundaries clear.

Tools in this story

A dark control room where flowing code fragments pass through a luminous lens, usage gauges, and a protective checkpoint.

The transcript is becoming an operations surface

Coding agents leave more behind than a patch. Their local records can contain prompts, tool calls, plans, model usage, file edits, and the moments when a person had to intervene. That material is useful for debugging both the software change and the way the agent was directed, but raw transcript files are awkward to inspect repeatedly.

Claudoscope turns that local trail into a native macOS dashboard. Its upstream documentation describes views for sessions, touched files, costs, configuration health, and project activity. The app reads Claude Code and Cowork records already stored on the machine; its privacy statement says transcript content, prompts, code, and detected secrets are processed locally rather than uploaded. That boundary matters because an observability tool can otherwise become a second destination for sensitive development data.

Claudoscope is genuinely young. The repository and public releases began in March 2026, followed by a stable 1.0 release in July. The 1.0 notes describe a persistent local session index, optional cost alerts, lifecycle notifications, per-session file history, and configuration linting. Those notes also report testing against a corpus of roughly 3,000 session files. That is useful evidence of the workload the author designed for, though it is not an independent performance benchmark.

Three questions, three different tools

A viewer can answer what happened in this session? It cannot automatically answer every neighboring question. A practical local stack separates at least three jobs:

  • Claudoscope reconstructs and presents Claude Code or Cowork activity on a supported Mac.
  • ccusage aggregates local usage into daily, weekly, monthly, session, and active-block reports across multiple supported coding agents.
  • HOL Guard evaluates supported actions against local policy, routes ambiguous cases for approval, and records receipts where its integrations expose an enforcement point.

The distinction is temporal as well as functional. Claudoscope and ccusage primarily help after records exist, even when they update live. Guard aims to intervene before supported actions execute. None of them replaces a provider invoice, source control review, operating-system isolation, or the agent's native permission model. Treating them as interchangeable would hide the most important design constraint: each observes a different slice of the workflow.

Usage evidence without pretending it proves everything

There are early signs that developers want this visibility. Homebrew's cask API recorded 20 Claudoscope installs in its available 30-day window when this article was researched. That is a modest, manager-specific count, not a census; direct downloads and updates are outside it. The upstream repository also showed public issue and contribution activity, but stars are interest signals rather than proof of sustained use.

ccusage has a broader observable footprint. The npm registry reported 776,090 downloads for the package from September 11 through October 10, 2026. Downloads can include automation, repeated installs, and mirrors, so they should not be converted into user counts. They do show that terminal-first usage reporting is not merely a hypothetical need. Its JSON documentation also makes the integration story concrete: every report type can be emitted as structured data, with an option to omit cost fields while retaining token, model, date, and projection information.

HOL Guard is newer and should be evaluated by boundary rather than marketing breadth. Its setup guide documents different approval paths for different agents and explicitly preserves native controls. That variability is a caveat, but also a sign of an honest integration model: protection is only as strong as the events an agent exposes and the path that can actually block them.

A disciplined evaluation loop

Start with a narrow question instead of installing an entire observability stack at once. For session review, compare Claudoscope's reconstruction with a known transcript and the resulting Git diff. Check whether cost estimates agree closely enough with the provider's billing view for your models, and confirm that opt-in configuration changes produce recoverable backups. Apple Silicon and macOS 14 are current prerequisites.

For reporting, run ccusage against a small date range and inspect both the table and JSON forms. Unknown pricing can produce incomplete cost figures, while differing agent formats can limit cross-tool symmetry. For runtime policy, use Guard's documented dry-run and status checks first, then test one harmless action that should be allowed and one controlled action that should require review. Keep native permissions enabled.

The valuable pattern is observe, reconcile, then govern. A session viewer makes agent behavior legible, a usage reporter makes trends comparable, and a runtime guard can add policy at supported decision points. Keeping those roles separate makes the resulting evidence easier to trust—and makes it clearer where human review is still doing the real work.

Sources