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.

•
Tool
This local dashboard finally explains Claude Code token usage

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.

Setup and availability

Install steps shared in the thread:

  • git clone the repo
  • cd claude-usage
  • run a Python command that starts the dashboard (Windows: use python instead of python3)

Huryn also noted it can be run in Docker on a Linux host, then accessed via the local web UI on port 8080.

Source: https://x.com/PawelHuryn/status/2041595776074236328?s=20

Continue the conversation on Slack

Did this article spark your interest? Join our community of experts and enthusiasts to dive deeper, ask questions, and share your ideas.

Join our community

Related Articles

Gas Town aims to orchestrate 30 Claude coding agents at once

Gas Town aims to orchestrate 30 Claude coding agents at once

Steve Yegge has published Gas Town, a Go-based orchestrator for running large fleets of Claude-style coding agents in tmux. It pairs role-based workers with Git-backed Beads and MEOW workflows to keep tasks, merges, and handoffs durable—if you can handle the cost.

1 shared tag