Preflight Checklist
Problem Statement
Token usage visibility is the #1 most-requested feature category in Claude Code issues. At least 10+ open issues request overlapping subsets of the same core need:
The data already exists — every Claude Code session writes detailed JSONL transcripts under ~/.claude/projects/ with per-message usage objects containing input_tokens, output_tokens, cache_creation_input_tokens, and cache_read_input_tokens. But there is no built-in way to query or aggregate this data.
Proposed Solution
A built-in claude usage subcommand (or claude-usage standalone) that provides unified token usage analytics. I've built a working prototype that demonstrates feasibility by parsing the existing JSONL transcripts — no API changes or new data collection required.
1. Summary view (default)
$ claude usage
============================================================
Claude Code Usage (last 7 days)
============================================================
Sessions: 19
Duration: 3080 min (51.3 hrs)
Messages: 1356
────────────────────────────────────────────────────────────
Input tokens: 9.6K
Cache write: 3.5M
Cache read: 151.0M
Output tokens: 392.2K
Total tokens: 155.3M
────────────────────────────────────────────────────────────
Est. cost: $282.52
============================================================
2. Plan status + today/weekly overview
$ claude usage --plan
============================================================
Claude Code Plan Status
============================================================
Plan: Max
Rate Limit: Max 20x
Extra Usage: Disabled
Active Now: 4 session(s)
============================================================
Today This Week
────────────────────────────────────────────────
Sessions 6 19
Messages 736 1356
Tokens 91.4M 157.1M
Est. cost $186.01 $286.02
3. Live monitoring dashboard
$ claude usage --watch 5
============================================================
Claude Code Live Monitor
Updated: 21:27:11 Refresh: 5s Ctrl+C to quit
============================================================
Active sessions: 4
User messages: 701
Model: claude-opus-4-6
────────────────────────────────────────────────────────────
Input tokens: 6.2K
Cache write: 1.8M
Cache read: 88.4M
Output tokens: 231.7K
Total: 90.4M
Delta: 25.3K (+25,312)
────────────────────────────────────────────────────────────
Est. cost: $184.32
============================================================
Today This Week
────────────────────────────────────────────────
Sessions 6 19
Tokens 91.4M 157.1M
Est. cost $186.01 $286.02
Session Project Min Msgs In Out Cost
──────────────────────────────────────────────────────────────────
20cd51f1 cli-tools 547 698 90.1M 231.5K $183.23
27e3a24c cli-tools 0 1 59.7K 64 $0.08
4. Flexible filtering
$ claude usage -d 1 # Today only
$ claude usage -d 30 --daily # Daily breakdown for last month
$ claude usage -p my-project # Filter by project
$ claude usage --sessions -v # Per-session with summaries
$ claude usage --watch 10 -p project # Live monitor, filtered
Why this should be built-in (not a third-party tool)
- The data is already there. Every JSONL transcript contains complete
usage objects. No new collection needed.
- 10+ issues requesting fragments of this. A single unified command resolves all of them.
- Cache-aware cost estimation matters. Claude Code heavily uses prompt caching — cost estimates that ignore
cache_creation_input_tokens and cache_read_input_tokens are wildly inaccurate. A first-party tool can get this right.
- Plan metadata is already local.
~/.claude/.credentials.json has subscription type and rate limit tier. ~/.claude.json has extra usage status. Combining these into a single view is trivial but only Anthropic can do it correctly.
- Live monitoring enables cost-conscious usage. Users currently have zero feedback about consumption velocity during long sessions. The
--watch mode shows token delta per refresh cycle, letting users see exactly how much each interaction costs.
Implementation notes from the working prototype
Data source: Parse ~/.claude/projects/*/*.jsonl (top-level only, skip subagents/). Each line with message.usage contains the token counts. Session metadata (project, model, timestamps) comes from the same files.
Cost model: Input, output, cache_write (1.25x input price), cache_read (0.1x input price), per-model pricing lookup.
Active session detection: Files modified within last 30 minutes.
Performance: Parsing 20+ transcript files (some 100MB+) takes ~2-3 seconds on first load. For --watch mode, this is acceptable at 5-10s intervals. Could be optimized with seek-to-end for incremental parsing.
What's NOT possible from local data (and that's OK):
- Plan usage percentage (rate limit utilization) — only available via API response headers (
anthropic-ratelimit-unified-*-utilization), not cached locally
- Billing-accurate costs — the prototype provides estimates, not invoices
Alternative Solutions
/cost command — Exists but only shows current session. No history, no aggregation, no cross-session view.
- Console/Admin Dashboard — Requires browser, separate login, admin permissions. Not accessible during active coding.
- OpenTelemetry — Heavy setup, meant for organizational monitoring, not personal usage tracking.
- Statusline hacks — Several issues request exposing tokens to statusline scripts. That's a workaround for not having a proper usage command.
Priority
High — This consolidates the most-requested feature category across 10+ open issues.
Feature Category
CLI commands and flags
Use Case Example
Solo developer on Max plan:
"I want to know if I'm burning through my daily allocation too fast. claude usage --watch shows me real-time consumption velocity, and claude usage --plan gives me today vs. this week at a glance."
Team lead:
"I need to understand which projects consume the most tokens so I can allocate budget. claude usage -d 30 --daily -p frontend gives me a monthly breakdown for a specific project."
Cost-conscious user:
"Before I start a large refactoring session, I check claude usage -d 1 to see what I've already used today. After the session, I compare to understand the cost of that specific task."
Additional Context
Working prototype: ~700 lines of Python, zero dependencies beyond stdlib. Parses existing JSONL transcripts that Claude Code already writes. This is not a "build it from scratch" proposal — it's "expose data you already have."
Related issues this would resolve or subsume:
#31564 #13891 #13892 #10593 #18550 #1109 #15931
Preflight Checklist
Problem Statement
Token usage visibility is the #1 most-requested feature category in Claude Code issues. At least 10+ open issues request overlapping subsets of the same core need:
The data already exists — every Claude Code session writes detailed JSONL transcripts under
~/.claude/projects/with per-messageusageobjects containinginput_tokens,output_tokens,cache_creation_input_tokens, andcache_read_input_tokens. But there is no built-in way to query or aggregate this data.Proposed Solution
A built-in
claude usagesubcommand (orclaude-usagestandalone) that provides unified token usage analytics. I've built a working prototype that demonstrates feasibility by parsing the existing JSONL transcripts — no API changes or new data collection required.1. Summary view (default)
2. Plan status + today/weekly overview
3. Live monitoring dashboard
4. Flexible filtering
Why this should be built-in (not a third-party tool)
usageobjects. No new collection needed.cache_creation_input_tokensandcache_read_input_tokensare wildly inaccurate. A first-party tool can get this right.~/.claude/.credentials.jsonhas subscription type and rate limit tier.~/.claude.jsonhas extra usage status. Combining these into a single view is trivial but only Anthropic can do it correctly.--watchmode shows token delta per refresh cycle, letting users see exactly how much each interaction costs.Implementation notes from the working prototype
Data source: Parse
~/.claude/projects/*/*.jsonl(top-level only, skipsubagents/). Each line withmessage.usagecontains the token counts. Session metadata (project, model, timestamps) comes from the same files.Cost model: Input, output, cache_write (1.25x input price), cache_read (0.1x input price), per-model pricing lookup.
Active session detection: Files modified within last 30 minutes.
Performance: Parsing 20+ transcript files (some 100MB+) takes ~2-3 seconds on first load. For
--watchmode, this is acceptable at 5-10s intervals. Could be optimized with seek-to-end for incremental parsing.What's NOT possible from local data (and that's OK):
anthropic-ratelimit-unified-*-utilization), not cached locallyAlternative Solutions
/costcommand — Exists but only shows current session. No history, no aggregation, no cross-session view.Priority
High — This consolidates the most-requested feature category across 10+ open issues.
Feature Category
CLI commands and flags
Use Case Example
Solo developer on Max plan:
"I want to know if I'm burning through my daily allocation too fast.
claude usage --watchshows me real-time consumption velocity, andclaude usage --plangives me today vs. this week at a glance."Team lead:
"I need to understand which projects consume the most tokens so I can allocate budget.
claude usage -d 30 --daily -p frontendgives me a monthly breakdown for a specific project."Cost-conscious user:
"Before I start a large refactoring session, I check
claude usage -d 1to see what I've already used today. After the session, I compare to understand the cost of that specific task."Additional Context
Working prototype: ~700 lines of Python, zero dependencies beyond stdlib. Parses existing JSONL transcripts that Claude Code already writes. This is not a "build it from scratch" proposal — it's "expose data you already have."
Related issues this would resolve or subsume:
#31564 #13891 #13892 #10593 #18550 #1109 #15931