If you have ever finished a heavy Claude Code day and wondered where the tokens went, where the time went, and which of your accounts did the work — that is the question the telemetry dashboard exists to answer. It is the panel that turns a wall of session JSONL into five numbers that fit on one screen.
This is a panel-by-panel walkthrough of the dashboard as it ships in current Power Claude. Each section names the metric, says what it counts, and tells you what it is useful for. Screenshot placeholders are called out where the visual is load-bearing.
What the dashboard is not
Worth saying once: nothing on this dashboard reaches a Neural-LLM server. The numbers are computed locally from ~/.power-claude/logs/handler.jsonl, ~/.power-claude/state/, and ~/.claude/projects/*.jsonl. The same files Claude Code writes are the same files Power Claude reads. There is no cloud aggregation step; the rendering happens in the VS Code webview on your machine.
If you want the network-level accounting of what does and does not leave the box, see What data leaves your machine. Everything in this article runs on data that stays on your disk.
Sessions: the unit of work
A session in Power Claude is a single Claude Code run with a stable session-id. It starts when Claude Code starts (or when you open a new conversation in the side panel) and ends at the next Stop hook. Sessions are the rows in the Insight Graph and the unit every other metric on the dashboard rolls up to.
The Sessions tile shows three counts: today, last 7 days, last 30 days. The numbers come from the session-index built by reading ~/.claude/projects/*.jsonl directory listings — one file per session, named by session-id. Each file's mtime is the session's last-activity timestamp.
What the count is useful for:
- Today: a sanity-check on actual engagement. Two sessions on a heavy day is normal; twenty is a sub-agent-heavy day where every fan-out fork counts as its own session.
- 7-day: the unit most rate-limit windows align to. Anthropic's weekly cap operates on a rolling 7-day window; a 7-day session count above your usual baseline is the first signal that you are approaching that cap before any threshold banner fires.
- 30-day: the smoothing window for the recommender. When the Cap-Hit Recommender suggests adding another account or upgrading a plan, it is computing from the 30-day distribution, not today's spike.
Rotation count: how often the pool worked
This is the metric the pre-emptive rotation engine was built to produce. The rotation count is how many times in the selected window an account-switch happened — either the standard rotation (one account exhausts, next picks up) or the Balanced Mode round-robin (every request goes to the least-loaded account, so "rotation" is the default state).
The number is split into two flavors:
- Pre-emptive rotations — switches that happened because the proxy read an
anthropic-ratelimit-header on a successful response and decided the account was approaching its limit. These are the rotations that prevented* a 429. - Reactive rotations — switches that happened on an actual 429. These should be a small fraction of the total. When they spike, it is a signal that the threshold buffer was too tight for the request mix that day (often correlated with very long input turns where the per-response header underestimated the next call).
A typical heavy day in Balanced Mode produces dozens to hundreds of pre-emptive rotations and zero or one reactive rotations. A heavy day in standard rotation mode with no Balanced multiplier produces a handful of pre-emptive rotations and a small number of reactive ones. The ratio is what tells you whether the pool is configured right.
The throttle waits avoided counter mentioned in the v0.x changelog is the cumulative form of the reactive-rotation number — it counts every time the smart-429 router routed around a Retry-After wait instead of sleeping it.
Total Claude-time: where the day actually went
"Total Claude-time" is the wall-clock time you spent in active Claude Code conversations across all sessions in the window. It is not CPU time and it is not token-consumed time — it is the duration from a session's first user message to its last Stop event, summed across every session.
The breakdown lives in the Session Detail view. For any session you can see:
- Wall-clock duration — first message to last Stop event.
- Active thinking time — time spent in
tool_useand assistant message turns where the model is actually doing work. - Tool-call duration — time spent waiting for local tool calls (file reads, shell commands, sub-agent spawns).
- Idle gap — time the conversation thread was open but neither you nor the agent was active. Often a coffee break or a build running in another window.
The total-Claude-time aggregate is the sum of wall-clock durations, with rotation events visible inline on the timeline so you can see when the pool worked under you. The active-thinking-time vs wall-clock-time ratio is a useful productivity signal: a 4-hour session where 3.5 hours was active thinking is a high-velocity day; a 4-hour session where 1.5 hours was active thinking and 2.5 hours was tool-call wait suggests either heavy shell work or a tool surface that could be tightened.
Success rate: did the session do what it intended
This is the metric the Snapshot Pills and auto-tags feed. Every session gets a completion-status assessment derived from three signals:
- Stop reason on the final assistant message. A clean
end_turnis the happy path. Atool_usestop with no follow-up means the session died mid-tool-call (network drop, OOM, process kill — the watchdog catches these). Amax_tokensstop means the session hit the per-response token cap and was truncated before finishing. - Pending tasks at the end. If the agent used the TodoWrite tool (or any tracker) and left items in a
pendingstate when the Stop fired, the session is markedended with pending tasks— it stopped politely but the work was not finished. (This is the case Auto-Nudge is built to prevent in the first place.) - Snapshot integrity. The session writes git refs at start and end (
refs/power-claude/sessions/<id>/{start,end}). Both refs resolving and the diff being reasonable for the session length is the OK state. Missing or unreachable refs is the Alert state.
The success-rate tile is the percentage of sessions in the window that hit the green-check completion state. On a healthy week with Auto-Resume and Auto-Nudge on it tends to sit in the high-90s. Sessions that ended in a pending-task state get tagged but are not counted as outright failures — you can search the Session Explorer for pending to see them all.
A success rate that drops noticeably is the signal to look at the next tile.
Top error categories: the histogram of what went wrong
This is the panel that earns its keep on bad days. The top-error-categories tile is a histogram of the failure modes the rotator and watchdog observed in the selected window, sorted by count. The categories Power Claude tracks (defined in the proxy's recoverableFailures.ts and rotator/classifier.ts):
usage-5h— Anthropic five-hour window exhausted on an account. The standard quota-hit case. Pre-emptive rotation should have handled most of these before they registered as errors; if this category is large, the threshold buffer was overshot.usage-weekly— seven-day window exhausted. Rarer thanusage-5hbut recovers more slowly. A non-zero count here is a signal to look at the recommender — you may have outgrown your current plan.server-error— Anthropic returned a 5xx. These are mostly transient and rotate around cleanly.server-error-escalated— 5xx that retried twice and still failed. These need attention.capacity— Anthropic returned a "capacity exceeded" error that is not strictly a rate limit. Usually transient.throttle— explicit per-minute throttle (429 with a shortRetry-After). These are what the smart-429 router routes around.all-accounts-exhausted— the entire pool was in cooldown simultaneously. The least-common bucket on a healthy day; the most-important bucket when it shows up.heartbeat-stale— watchdog detection: nolifecycle:heartbeatevent in N seconds and the JSONL is idle. Process kill, OOM, IDE crash, network drop.tool-truncation— session ended on astop_reason: tool_usewith no follow-up. Mid-tool-call death.ended-with-pending— clean stop but the agent left work undone. The Auto-Nudge bucket.
Each row in the tile is one category, the count for the window, and the timestamp of the most recent occurrence. Click any row to drill into the Session Explorer pre-filtered to sessions that hit that category.
This is the panel that closes the loop on the "what happened today" question. A high usage-5h count and a low throttle count means you are running out of the bigger windows — consider another account. A high throttle count and a low usage-5h count means Balanced Mode is doing its job catching per-minute throttles. A non-zero heartbeat-stale count is the watchdog telling you the editor itself is having a rough day. (See the Cap-Hit Recommender for how these counts feed the buy-more-accounts vs upgrade-plan suggestion.)
How the panels read together
The five tiles are designed for a single glance. The workflow most users settle into:
- Glance at sessions today. Is this a normal volume day or an unusual one?
- Glance at rotation count. Did the pool actually do its job, or did most of the day land on one account?
- Glance at total Claude-time vs active-thinking-time. Was the day productive, or was a lot of it tool-call wait?
- Glance at success rate. Did the sessions finish what they started?
- Look at the top error category. If the success rate dropped, this is where the explanation is.
The whole loop takes under a minute. The historical contrast (last 7 days, last 30 days) is one click away on each tile. Drilling into the Session Explorer from any tile is one more click. The Cap-Hit Recommender notification is the only thing that escalates a number to a banner; everything else stays where you put it.
What the dashboard does not try to do
Worth naming the design constraints, because they shape what you should and should not expect:
- No dollar figures unless you opt in. Cost estimation needs a plan-tier input (Pro vs Max vs API rates). The dashboard renders token counts and rotation counts by default; if you set your plan tier in settings it adds a cost overlay. The cost numbers are estimates — Anthropic's actual billing is the ground truth.
- No predictions beyond the Runout Forecaster's pool-survival ETA. The dashboard reports what happened. The Forecaster is the only forward-looking element, and even its math only treats reset times as authoritative (from the headers) — burn rate is an estimate from recent history.
- No model-quality scoring. The per-turn model-attribution feature surfaces which model answered (so you can spot silent Haiku downgrades), but it does not score whether the answer was good. That is a judgment call you make from the output.
- No cross-machine aggregation. Each install has its own dashboard. If you run Power Claude on a laptop and a desktop, they each show their own data. There is no cloud aggregation because there is no cloud.
The CLI mirror
For terminal-first workflows, the same data is reachable from pc:
pc list— current account pool with quota bars and reset timers (the Account Rotation Dashboard, in text).pc status— one-screen system summary (active mode, account count, today's rotation count, top error category).pc watch— live TUI of the same data the dashboard renders, with modal hotkeys to rotate, switch active, or trigger recovery.pc logs -f --level error— tail the event stream with the same categorization the top-error-categories tile uses.
Both surfaces run against the same ~/.power-claude/ data. Whichever you prefer, the numbers are the same. (See /docs/getting-started for the install and first-run flow.)
Download Power Claude to see your own first-day numbers, or browse /pricing for the account-count-to-cost math behind the rotation tile.
Quick Reference
Q: What counts as a "session" on the dashboard? A: A single Claude Code run with a stable session-id, from the first user message to the next Stop hook. Sub-agent forks count as their own sessions because they get their own session-ids.
Q: What is the difference between pre-emptive and reactive rotation? A: Pre-emptive rotation switches accounts before a 429 fires, based on the anthropic-ratelimit-* headers from the previous successful response. Reactive rotation switches after a 429 has already happened. On a healthy day pre-emptive should dwarf reactive — a spike in reactive means the threshold buffer overshot for the request mix.
Q: How is total Claude-time calculated? A: Wall-clock from the first user message of each session to the last Stop event, summed across the window. The Session Detail view breaks each session down into active-thinking, tool-call wait, and idle gap.
Q: Why might my success rate drop on a particular day? A: Look at the top error category. usage-5h dominating means quota exhaustion on individual accounts. tool-truncation means a session died mid-tool-call (often a network drop or OOM). ended-with-pending means clean stops with work undone — Auto-Nudge prevents most of these.
Q: Are the numbers comparable across installs? A: Within the same install yes; across installs not directly. Each dashboard reflects its own machine. There is no cloud aggregation because no telemetry leaves your box. To compare two installs, look at the same windows side-by-side manually.
Q: Does the rotation count include Balanced Mode round-robin? A: Yes. Every account-switch on a request boundary increments the rotation count, whether it was triggered by approaching the threshold or by Balanced Mode's least-loaded selector. The two are split out in the rotation timeline tile so you can see which mode generated which switches.
Q: What does a heartbeat-stale error mean in the histogram? A: The watchdog detected that the Claude Code process stopped emitting heartbeat events while the JSONL was idle. Most common causes: the editor was killed, the host OOMed, the network dropped mid-tool-call, or VS Code itself crashed. The session is recoverable by clicking "Resume" in the watchdog's QuickPick prompt.
Q: Can I export the dashboard data? A: Yes — Insight Bundle exports include the underlying session records (tool calls, diffs, cost breakdown, model attribution) as a self-contained archive. The format is for code review and incident investigation, not for any Neural-LLM ingestion. See Log Export for the export flow.