Claude Code Usage Monitor: ccusage, ccflare, and Hooks

A Claude Code usage monitor tracks token consumption, burn rate, cost estimates, and time-to-limit projections. Five community tools (ccusage, Claude-Code-Usage-Monitor, ccflare, claude-doctor, ccstatusline) all rely on parsing local Claude Code JSONL session files because that was the only public surface most predate. ClaudeFast Code Kit ships a status-line monitor built on the latest Claude Code hook APIs that reads live model, context fill, and 5-hour budget state directly, plus ContextRecoveryHook that recovers ~15,000 tokens per session at the source.

Quick verdict: Five community tools parse local JSONL files to reconstruct usage after the fact. ccusage is the historical analyzer. Claude-Code-Usage-Monitor is the live fuel gauge with ML-based predictions. ccflare is the web dashboard. claude-doctor is diagnostics. ccstatusline puts JSONL-derived metrics in the status line. ClaudeFast Code Kit ships a status-line monitor on the current Claude Code hook APIs (live model, context fill, 5-hour window state, backup state) plus ContextRecoveryHook that cuts the underlying spend by ~15,000 tokens per session.

Why Usage Monitoring Matters in 2026

Three forces made monitoring urgent in 2026. First, the Claude Code v2.1.89 release in March 2026 caused widely-reported 3 to 50x faster rate limit consumption, with Max 20x plans exhausted within 70 minutes of reset for some users. Second, the April 4, 2026 policy change blocked Pro and Max subscribers from using third-party agent frameworks, concentrating subscription spend in the official Claude Code path. Third, plan-tier math shifted: Pro caps near 44,000 tokens per 5-hour window, Max5 at 88,000, Max20 at 220,000.

Claude Code ships three native views: /usage shows the current 5-hour billing window, /context shows context fill percentage, and claude.com/console shows team aggregates (Team and Enterprise plans only). For individual Pro and Max users, four gaps remain: historical trend data, per-project attribution, live burn-rate prediction, and alerts before you hit the limit.

The community tools below fill those gaps via JSONL parsing, the public surface that has worked for two years. ClaudeFast Code Kit fills the same gaps via the latest Claude Code hook APIs (which read state directly, no JSONL detour) and adds a separate gap nobody else addresses: reducing the underlying spend through ContextRecoveryHook.

Quick Win: Get a Monthly Breakdown in One Command

npx ccusage

That parses your local Claude Code JSONL session files and prints daily, monthly, and per-project usage with cost estimates. No API key required, no cloud dashboard, no signup. Below, the four other monitoring tools worth knowing.

What Each Tool Does

1. ryoppippi/ccusage

The most-installed Claude Code analyzer. CLI tool that parses local JSONL session files and produces daily, monthly, and session-based usage tables.

What it does well:

• Daily and monthly breakdowns with model splits
• 5-hour billing window tracking
• JSON export for piping into other tools
• MCP server integration so an agent can monitor its own burn rate mid-session
• Per-project tracking when you run from different working directories
• Offline mode with cached pricing data

Install:

npx ccusage
# or globally
npm install -g ccusage

Best for: The accountant view. Run it weekly to see where your tokens went and adjust your patterns.

Latest version: 18.0.11 as of late April 2026.

2. Maciek-roboblog/Claude-Code-Usage-Monitor

Real-time terminal dashboard with ML-based burn-rate predictions. Beautiful Rich UI showing token consumption, cost estimate, and time-to-limit projections.

What it does well:

• Live token burn rate with predictions
• Multi-level warning system (yellow at 70%, red at 90%, critical at 95%)
• Updated plan limits: Pro (44k), Max5 (88k), Max20 (220k), Custom (P90-based)
• Runs persistently in a tmux pane or split terminal

Install:

pip install claude-monitor
# or
uv tool install claude-monitor

Runnable as claude-monitor, cmonitor, ccmonitor, or ccm.

Best for: The fuel-gauge view. Keep it open in a side pane during heavy sessions so you see the limit coming, not arriving.

3. ccflare

Comprehensive web UI dashboard for Claude Code usage. Same JSONL parsing approach as ccusage, but browser-based with charts and interactive filters.

What it does well:

• Interactive web charts for trends
• Multi-project comparison views
• Cost breakdown by model and tool
• Shareable URLs for team review

Install:

npm install -g ccflare
ccflare serve

Open http://localhost:3000 and your dashboard is live.

Best for: Teams or solo founders who want a richer view than terminal tables. The shareable URLs are useful for justifying spend in team retros.

4. millionco/claude-doctor (541 stars)

Diagnostic CLI for Claude Code sessions, not a usage monitor exactly but adjacent. Health checks for context, hooks, MCP, and configuration. TypeScript.

Why it's here: When usage is high but output is low, the cause is often broken config, leaky hooks, or runaway MCP calls. claude-doctor surfaces those before they show up as a token bill.

Install:

npx claude-doctor check

Best for: First-pass diagnostics when something feels off. Run it before assuming you need to upgrade your plan.

5. sirmalloc/ccstatusline

Customizable terminal status-line formatter for Claude Code. Displays model info, git branch, token metrics, session timers, and cost tracking in a compact bar.

Why it's here: The status line is the one place you'll actually look every minute. Most other monitors require you to context-switch. ccstatusline puts the same data in your peripheral vision.

Install: Configure via Claude Code's statusLine setting. Detailed setup in our statusline guide.

Best for: Anyone who wants passive awareness without an extra terminal pane.

Side-by-Side: Monitoring vs Reduction

The Stack That Actually Works

Three monitoring tools plus one reduction layer cover every case without overlap:

1. ccstatusline in the terminal status line for passive awareness
2. Claude-Code-Usage-Monitor in a tmux pane during heavy sessions for live predictions
3. ccusage run weekly for trend analysis and per-project attribution
4. ClaudeFast Code Kit's 5 hooks to cut underlying spend by recovering ~15,000 tokens per session before monitoring becomes urgent

ccflare and claude-doctor come out only when something breaks the pattern. The first three answer "where did my tokens go?" ClaudeFast Code Kit answers two different questions: "what's happening right now?" via the status-line monitor on the latest hook APIs, and "how do I burn fewer tokens in the first place?" via the 5 production hooks.

What Causes Surprise Spend

Usage monitors tell you the bill. They don't tell you why. Four causes account for most surprise spend:

1. Runaway MCP servers that call themselves recursively
2. Hooks that fire on every event instead of being matcher-scoped
3. Sub-agent loops where the parent re-spawns failed children
4. Long context that the parent never compresses before compaction

Three of those are config issues. The fourth is a design problem. ClaudeFast ClaudeFast Code Kit ships ContextRecoveryHook (one of 5 production hooks bundled in the Kit) which backs up session state on PreCompact and recovers approximately 15,000 tokens per session through context min-maxing. Combined with the SkillActivationHook (which loads only relevant skills per prompt instead of every skill on every prompt), the typical ClaudeFast Code Kit user sees their weekly limit shift from Tuesday to Friday, often Sunday. Monitoring tells you what burned. ClaudeFast Code Kit's hooks reduce what burns in the first place.

What to Read Next

• Statusline guide for ccstatusline-compatible status line setup
• Usage optimization guide for reducing burn before you need to monitor it
• Claude Code subscription guide for plan-tier math
• Best MCP servers list for MCP servers that don't leak tokens
• Context buffer management for the upstream cause of most surprise spend

Token bills are the easiest cost to monitor and the hardest to predict without these tools. Pick one from each form factor (CLI, TUI, status line) and you'll have signal at every part of your loop.