BURNLENSDocsDashboard

Scanning coding-agent logs

Verified against burnlens scan --help on 2026-09-03. For the shorter pitch rather than the reference, see the scan overview.

What it does

Coding agents already write a full session log to disk. burnlens scan walks those files, deduplicates the turns, routes each call through the pricing engine, and writes the result to ~/.burnlens/burnlens.db.

There is no proxy, no code change, and no signup. Importing session logs is local. After import, scan derives merged-PR outcomes for the current checkout through the GitHub CLI (gh) — the same path as burnlens outcome derive. If gh is missing, that is printed rather than skipped. --dry-run does not derive. It is retroactive — the first run prices history that already happened, which is why it produces a real number immediately rather than after a week of collection.

burnlens scan          # every agent it can find
burnlens repos         # top repos by cost
burnlens prs           # top PRs by cost
burnlens report -d 30  # spend by model, plus waste alerts

burnlens top is deliberately not in that list. It is a live viewer for traffic arriving through the proxy right now, scoped to today, and it refreshes until interrupted — so after a retroactive scan it shows an empty table and never exits.

What it reads

Agent--providerRead from
Claude Codeclaude~/.claude/projects/<project>/<session>.jsonl
Cursorcursor~/Library/Application Support/Cursor/.../state.vscdb
Codexcodex~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl
Gemini CLIgemini~/.gemini/tmp/<project>/chats/session-*.{json,jsonl}

Flags

burnlens scan --provider claude,codex   # 'all' (default), or a comma-separated subset
burnlens scan --since 2026-08-01        # only sessions modified at/after this date
burnlens scan --project burnlens        # substring filter on project basename (Claude Code only)
burnlens scan --dry-run                 # parse and print counts, insert nothing

Re-runs are idempotent. Already-imported records are skipped through a partial unique index on (source, request_id), so scanning on a schedule cannot double-count a session.

What the data can and cannot tell you

Scanned rows carry no prompt or response text — model, token counts, timestamps and the repo the session ran in, and nothing else.

When a checkout has an origin remote, the local display name is kept for humans but the economics join uses its canonical remote identity. That keeps two repos both named api separate across developers and renamed checkouts. A checkout without a remote falls back to its local name and is reported as such.

Cost is attributed per repository, not per branch or PR. Agent session logs record which repo a session ran in; they do not record which branch it belonged to. With several PRs in flight, per-repo spend divided by accepted outcomes is the honest reading of what one merged PR costs, and it is what burnlens outcome show reports.

A model with no pricing entry is imported as $ unknown, not $0. The session is still imported and the model name is logged so the gap is visible rather than silent — run burnlens pricing if a number looks too low. Any total derived from a scan is therefore a floor, not a ceiling. Storage still uses a sentinel 0 so sums do not invent a price; CSV export and Cost Confidence print unknown rather than $0.00.

Scan costs use today's bundled pricing table, not the prices in effect when the session ran. A March session scanned in August is costed at August rates. Cost Confidence classifies every scanned row as estimated for that reason, among others.

Scanned rows also carry no prompt segmentation, so the waste detectors that need it (oversized tool schemas, retrieval efficiency, history bloat) stay quiet on scan data. Those need proxy traffic — no scan and no upgrade can backfill a measurement that was never captured.

Next

After a scan that could reach gh, burnlens outcome show is the cost-per-merged-PR number. Re-run derive from another checkout with burnlens outcome derive. The importer paginates all closed PRs; use --since and --until for an event-time window. See the CLI reference. To meter production API traffic rather than agent sessions, see the proxy.

All documentation

  • Overview & install — What BurnLens is, how to install it, and which of the two entry points you want.
  • Scanning coding agents — Import Claude Code, Cursor, Codex and Gemini CLI cost history from local logs.
  • Proxy & tagging — Route production API traffic through the local proxy and attribute it with tags.
  • Budgets & enforcement — Daily key caps, control scope, concurrency guarantees, virtual keys, downgrade routing.
  • Cost evidence — Cost Confidence, Outcome Coverage and Verified Savings — how much of a number BurnLens can prove.
  • Known limitations — Where each figure stops being authoritative, stated plainly.
  • CLI reference — Every burnlens command, and where the config file and database live.

Something here wrong or missing? Open an issue or email support@burnlens.app.