How CC Token Meter turns local Claude Code transcripts into token, cost, cache and project-level insights — without sending your data anywhere
AI coding tools are changing how quickly software can be built, but they also introduce a new engineering resource to understand: tokens.
Once I started looking at Claude Code usage more closely, I realized that a total token number wasn't particularly useful.
I wanted to know:
Which project is consuming the most?
Which sessions are unusually expensive?
Is prompt caching actually working?
How is usage changing over time?
And most importantly: is there anything I can change?
That became CC Token Meter.
Instead of intercepting Claude Code requests or introducing another cloud service, CC Token Meter works from the session data Claude Code already stores locally.
The architecture is intentionally straightforward:
Claude Code transcripts → local parser → private usage index → analytics → local dashboard
From there it can derive token and estimated-cost activity, project and branch attribution, cache behavior, historical trends, budgets and optimization insights.
The privacy boundary was just as important as the analytics. Transcript access is read-only, the dashboard is loopback-only, no telemetry is collected, and no Anthropic API key is required.
The larger idea behind the project is that as AI becomes part of the development stack, AI usage itself needs observability.
Not simply a counter showing what was consumed, but tooling that helps engineers understand where resources are going and whether their workflows can be improved.
CC Token Meter is open source, and this is still the beginning.
Top comments (0)