Start with cost, not vanity usage

Token totals are useful only when they are tied to money, sessions, and outcomes. A dashboard should answer what changed since yesterday and which work caused the change.

• Show tokens and dollars together.
• Break out model and project where possible.
• Keep a visible date range so weekly spikes are not mistaken for daily behavior.

Watch the 5-hour and weekly limits

Claude Code usage feels unpredictable when the dashboard only shows historical totals. The practical view is a pace meter that tells you whether the current session is likely to hit a limit.

• Show active-session burn.
• Flag fast growth in context.
• Separate background activity from explicit prompts when the data supports it.

Add project-level accountability

The most actionable dashboard row is usually the project, not the user. A migration, test-fix loop, or large refactor can explain a spike better than a single aggregate number.

• Group sessions by working directory.
• Name expensive conversations.
• Compare similar tasks across days.

Use whoburnedmore as the baseline

whoburnedmore reads local coding-agent logs and turns them into a shared burn view. It is a good first dashboard because it starts with one command and keeps the source code local.

• Run the command after a heavy session.
• Use public mode for friendly accountability.
• Use local mode when you only need private diagnostics.

Which official surface answers which question

Claude Code now ships several usage views. They measure different things, so choose the one that matches your question before you build anything custom.

• Am I about to hit a limit? Use /usage plan bars, or a status line script that reads rate_limits.five_hour and rate_limits.seven_day.
• What did this session cost? The /usage Session block estimates it at list price from local token counts, and it resets when /clear starts a new session.
• What is eating my plan? The /usage attribution breakdown and its recommendations. Press f to apply the fixes it can (v2.1.305 or later).
• How do I work? /insights writes an HTML report on up to 200 recent sessions to ~/.claude/usage-data/report.html.
• How is my team doing? On Teams and Enterprise, the claude.ai analytics dashboard shows daily active users, sessions and contribution metrics. A spend report with CSV export shows usage-credit spend per user and per model.

Build a team dashboard from exports, not screenshots

For more than a handful of developers, pull numbers programmatically. On the Claude Console (API billing), the Claude Code Analytics API returns daily per-user metrics with an Admin API key. On Enterprise, the Enterprise Analytics API returns per-user usage and cost across Claude surfaces. On Bedrock, Google Cloud or Microsoft Foundry, Anthropic's analytics do not see your traffic. There, OpenTelemetry export from each machine is the documented way to get per-user tokens and cost. If your organization pays contracted rates, set the modelPricing managed setting (v2.1.242 or later) so /usage, the status line and OpenTelemetry report your rates instead of list price.

Where whoburnedmore fits

whoburnedmore covers the cross-tool, day-by-day view that Claude Code's own screens do not. Claude Code's /usage figures cover only the machine you run it on. whoburnedmore puts Claude Code beside Codex, Cursor, GitHub Copilot CLI, Gemini CLI and the other local agents it reads, as daily totals. Use --local for a private HTML dashboard, or --dry-run to inspect the exact payload before anything is uploaded.