This local dashboard finally explains Claude Code token usage

Claude Code subscribers get a usage bar, but little insight into what’s driving it. Paweł Huryn built a lightweight local dashboard that reads Claude Code’s JSONL logs, stores them in SQLite, and charts tokens, models, time ranges, and estimated costs.

April 9, 2026

•

Tool

TL;DR

Problem: Claude Code progress bar lacks per-model, per-project, and token-source breakdowns
Log data available: JSONL under ~/.claude/projects/ with per-session/per-turn tokens, cache, model, timestamps
Dashboard approach: Scans JSONL, loads into SQLite, serves charts on localhost:8080 using Python standard library
Filters and views: Model (Opus/Sonnet/Haiku), time range (7d/30d/90d/all), cost estimates via Anthropic API pricing
Retroactive ingestion: First run imports all historical logs; subsequent runs append incrementally
Example findings: 30 days showed 440 sessions, 18,000 turns, $1,588 estimated, plus 700M-token cache spike anomaly

Subscription users of Claude Code get a usage progress bar, but not much context behind it—no per-model breakdown, no per-project view, and no way to understand where token consumption is actually coming from. Paweł Huryn ran into that wall and responded with a pragmatic fix: a local dashboard that reads the logs Claude Code already writes on disk and turns them into usable charts.

The key detail is that Claude Code appears to log per-session and per-turn token data under ~/.claude/projects/ as JSONL, including input tokens, output tokens, cache reads, cache creation, model name, and timestamps. The information exists; it’s just not surfaced in the product UI.

A local “glass box” for Claude Code usage

Huryn’s dashboard works by scanning those local JSONL files, loading them into a SQLite database, and serving visualizations on localhost:8080. Since it’s built on Python’s standard library, it’s positioned as a lightweight tool that can run without pulling in extra dependencies.

The dashboard includes a few practical filters that map closely to how people actually budget AI-assisted coding time:

Filter by model (Opus, Sonnet, Haiku)
Filter by time range (7d, 30d, 90d, all time)
Display cost estimates based on current Anthropic API pricing (as described in the thread)

It also processes history retroactively: the first run ingests the entire existing log set, then subsequent runs build on that database.

What the logs revealed in one real dataset

Huryn shared a snapshot of personal usage over the last 30 days: 440 sessions, 18,000 turns, and an estimated $1,588 in API-equivalent costs. Most notably, one day showed a cache spike to 700M tokens, which Huryn described as a visible cache bug occurring two days in a row—exactly the kind of anomaly that a single “% used” bar can’t explain.

Replies to the thread echoed a common theme: once work spans multiple projects, agents, or client contexts, token observability becomes operational, not just nice-to-have.