Everything the dashboard shows, and what it actually means.

01Overview

"Anything wrong? What's the headline?" — localhost:5173/

The KPI strip, left to right:

• Effective hourly wage — blended $/hr (total cost ÷ active hours) with per-model chips. Per-model rates use each model's own inference time, so they are independent rates, not shares of the blended number.
• Cache ROI — estimated $ saved by serving context from cache at 0.10× the input rate instead of full price, with the effective discount %.
• Total cost — denominated by the header's Cost basis. Under Estimated it reads recorded (Claude Code's own estimate) with the dashboard's token-priced estimate underneath; under Effective it is your real subscription fee amortized over actual usage. See the three cost bases.
• Projected EOM — the month-end forecast with its ≈95% band; appends "low-confidence (early)" until there's enough history to trust the trend.
• Top ticket — the costliest ticket in range, plus what % of spend is ticket-tracked. Click → Outcomes.
• Cost / commit — recorded cost ÷ commits from the metrics signal.
• Plan ROI — list-price usage ÷ the flat subscription price (only when scope = all groups). Click → Budgets.
• Anomalies — count of unusually costly sessions; turns red when non-zero. Click → Budgets.
• Sessions / Tokens in / Tokens out / Avg events per turn.

Below the strip:

• Context-tax share — the signature widget. One 100%-stacked bar splitting estimated spend three ways; in the caption's words: "remembering (cache read) + rebuilding (cache write) is the tax of carrying context; new I/O is the productive work." Expect the tax to be most of the bar — that's the finding, not a bug (why).
• Wage by model — ranked $/hr bars. Bar length is proportional to the rate, not total spend, "so a rare but pricey model still reads expensive"; total cost, tokens, and turns ride along as text.
• Spend over time — estimated cost by token type, bucketed hourly (24h), daily, or weekly (30d/All once there's enough data). The dashed Projected line extends the recorded-cost trend, but only as far as the range you're looking at, and it's dropped entirely if it would dwarf the actuals — the full projection always lives on the Projected-EOM tile and the Budgets page.

02Allocation

"Who is spending?" — localhost:5173/allocation

Showback and unit economics per group and user, from the email → group mapping managed on Configuration → Groups:

• Spend by group / by user — ranked recorded-cost bars. Clicking a group sets the global scope, which filters every other page too. Usage from emails in no group lands in a loud red (unassigned) bucket with a warning banner — the point is that unmapped spend should nag until you map it.
• Top movers — each group's spend vs. the immediately preceding equal-length window (unavailable for range = All, which has no preceding window).
• Cost per unit of shipped work — per group: $/commit, $/KLoC (lines added + removed), and $/accepted file edit, from Claude Code's metrics counters. The counters only exist while telemetry was enabled, so early ranges undercount.
• Cohort views — the session-cost histogram (fixed $ bins; surfaces the long tail of a few expensive sessions) and the cross-session tool & activity profile.

03Efficiency

"What's wasted, and what do I do about it?" — localhost:5173/efficiency

• Productive-token share — the efficiency score: 100 − context-tax %, i.e. the share of estimated spend that went to new I/O rather than carrying context, with a Kubecost-style letter grade. Read the score caveats before taking a "D" personally.
• Ranked savings (estimated) — each row is one recommendation with an estimated $ for the range: one row per performance tier, avoid warm-cache rebuilds (content invalidations — cache drops that timing can't explain), and reduce rejected work. All figures are explicit upper bounds from list-price estimates; each row's note says which corners were cut. The rows are ranked, not additive — the tier rows don't overlap each other (every model sits in exactly one tier), but they do overlap the other two, which slice the same spend a different way, so summing the column double-counts. Take the top one first.
• Per-tier rows — every model carries a performance tier, and each tier's row reprices that tier's whole spend at the tier's cheapest member you can still call: "Frontier-tier spend $2,725 → $2,064 at claude-opus-4-8." Expand a row for the per-model breakdown and the scoring of every candidate in the band. Token counts transfer 1:1 inside a tokenizer family; across families they are adjusted (or, cross-provider where no parity has been measured, carried over unadjusted) and the row wears the APPROX chip. Cache traffic reprices at the target's own cache terms — which matters, because OpenAI and DeepSeek have no cache-write step, so cache-creation tokens bill there as ordinary input. Targets are priced at standard (non-introductory) rates so an estimate survives a price flip, retired models are never offered as targets, and a tier whose cheapest member is already what you run produces no row at all rather than a $0.00 one.
• What a tier actually is. A 10-point band of published SWE-bench Verified scores — Frontier 90%+, Advanced 80–90%, Workhorse 70–80%, Basic under 70% — and nothing more. Two models in a band scored within ten points of each other on one eval; it does not mean they do your work alike. A tier row is an argument to go and test a swap, never evidence one is safe. The page carries the caveats behind the tooltip on each row; the full write-up — sourcing rules, the open-weights and peak-pricing caveats, and the counterfactual arithmetic — lives in docs/design/performance-tier-methodology.md.
• Models with no published score are excluded loudly — named with their spend, and producing no recommendation. There is no default score and no default band.
• Cost vs benchmark score — one compact chart: blended $/MTok against each model's SWE-bench Verified score, with the models you actually ran highlighted. Down and to the right is better. "Blended" means each model's standard rates weighted by this range's own token mix and its own cache multipliers — deliberately not a headline input rate, since agentic traffic is overwhelmingly cache reads and providers price those between 0.10× and 0.50× of input. Scores come from different harnesses and different years, so horizontal distance is indicative rather than exact.
• Cost of rejected work — recorded cost of the turns containing rejected tool calls, with a per-tool breakdown. Upper bound: the whole turn is counted, not just the rejected call.

04Outcomes

"What did the spend ship?" — localhost:5173/outcomes

Per-ticket economics, powered by the ticket-capture hook (see branch-per-ticket) and enriched from Jira when credentials are configured — without them the page still works: tickets render from telemetry alone, minus status and story points.

• Tracked vs untracked spend — what fraction of recorded spend a ticket claims. In the caption's words: "Untracked spend is work no ticket claims — keep it loud."
• Cost by epic — tracked cost rolled up to each ticket's parent epic; tickets without an epic land in a loud (no epic) bucket.
• Cost per ticket — cost, sessions, turns, tokens, dominant actual model, Jira status/points, and $/pt per ticket.
• Spend per story point — tracked cost ÷ story points over done tickets only (in-progress tickets still accrue cost against their estimate, so counting them would understate).
• Cost by issue type — tracked cost by Jira issue type.

05Skills & Agents

"What do skills and spawned agents cost?" — localhost:5173/agents

Two tabs on one page: Skills first, Sub-agents second.

Skills — user-invoked (/slash) skills only. A slash command's turn is that skill's work — everything after /skill, subagent spawns included, is what invoking it cost — so each invocation is priced as its full turn's recorded spend, with no qualifier chip. Skills Claude loads on its own (proactive or nested activations) are excluded: they're often incidental to turns they didn't drive, and the telemetry has no per-skill request linkage to split a turn honestly.

• Spend & activity by skill — invocations, cost, $/invocation, tokens, and duration p50/p95 per skill.
• Model mix per skill — invocations stacked by the turn's dominant model (a skill runs on whatever model the session is using).
• Source split — where each invoked skill is defined: bundled/builtin (shipped with Claude Code) vs. project/user settings vs. plugin.
• Recent skill invocations — one row per /slash invocation, newest first, with a deep link to the session on Session Metrics.

Sub-agents — spend and activity for agents spawned by the Task tool (built-in Explore / general-purpose / Plan, plus custom project/user/plugin agents). Cost honesty is the tab's organizing rule: built-in cost is exact (every cost row names its type), while per-custom-name and per-instance cost is estimated by a model + time-window join — those values wear the EST chip, and APPROX additionally marks concurrent same-model instances whose split is ambiguous.

• KPI row — invocations, agent spend and its share of all spend, avg cost/invocation, cold-start tax, and share of turn cost.
• Spend & activity by agent type / Model mix per type / Source split — the roster, per-type cost tiers, models, and where each agent is defined.
• Cold-start tax — a spawned agent shares no prompt cache with its parent, so its first request pays full input price and writes its own cache. Structural, not avoidable; a fan-out of many one-shot agents pays many cold starts.
• Cost by custom agent name (estimated) — the exact all-custom total with its per-name split recovered heuristically.
• Recent subagent invocations — one row per completed subagent, with session deep links.

06Budgets & Alerts

"Are we on plan?" — two pages: localhost:5173/budgets and localhost:5173/alerts

Budgets has two tabs. The read-only Overview tab:

• Monthly budgets — calendar-month budget vs. recorded month-to-date, per scope, from config/budgets.json (edit them in the Budgets tab). Red is reserved for actual overage; orange for a confident forecast trending over; a short or ramping fit shows "projection too early to call" instead of an alarm (why).
• Subscription ROI — the flat plan fee vs. what the recorded usage would have cost at API list prices. The caption is the definition: "Claude Code's own list-price estimate of the usage, not money actually spent; there's no per-token invoice on a subscription."
• Forecast detail — daily recorded spend with the naive linear projection to month end and its ≈95% residual band.
• Anomaly feed — sessions whose recorded cost sits ≥2σ above the mean. Each row deep-links to that session on Session Metrics; dismissals persist locally in the browser.

The Budgets config tab is a CRUD table (organization total, per-group budgets, and the flat subscription plan price). New Budget writes to config/budgets.json; edits are validated server-side (the group must exist, the amount must be positive). When month-to-date actuals cross 80% and 100% of a budget, the evaluator fires an in-app notification (once per budget × threshold × month). Read-only in demo mode.

Alerts (its own page) has two tabs. Alert Subscriptions — session-scoped alerts on a per-session metric (Accumulated Cost, Tokens In/Out, Averaged Cache Efficiency, Agentic Depth per turn, Events per turn). The New Subscription form takes a name and a positive trigger value; Scope (Session) and Notification Type (In-App) are shown but locked in v1. A background evaluator checks recently-active sessions every ~5 min and fires the first time a session crosses the threshold (once per subscription × session).

Alert Notifications — a table of everything that has fired, subscription and budget thresholds alike; the action opens the session on Session Metrics (subscription) or the Budgets page (budget). The same notifications drive the header bell with its unread count. Demo mode displays seeded budgets, subscriptions, and notifications but is read-only — creating, editing, and deleting need live data.

07Session Metrics

"Why did this session cost what it did?" — localhost:5173/metrics

The per-session diagnostic leaf, and the page most useful to an individual user. Pick a session from the selector (the list honors the global scope). Every chart is indexed by turn number, not wall-clock time — turn 0 is the bucket for session-scoped startup events. Four sections:

Cost & tokenomics

• Accumulated cost by token type — stacked estimated cost (input / output / cache write / cache read) with Claude Code's recorded cost as a dashed overlay, so estimate-vs-recorded is readable at a glance.
• Cost burn rate — recorded cost ÷ turn wall-clock hours, per turn.
• Context tax per turn — the three-way split per turn. "A tall rebuilding band is a cache miss — cross-check the idle-gap chart for the cause."
• Cache savings (estimated) — cumulative $ saved by cache reads vs. full input price.

Cache health — the cold-start triage kit:

• Cache hit efficiency — cache-read share of prompt-side tokens, per turn.
• First-request cache efficiency — the same rate for each turn's opening request only. "A dip here while the turn-average stays high is a cold start — the cache was rebuilt on the opening request, then later warm reads hid it in the average."
• Idle gap before turn — inter-turn idle seconds on a log axis; red bars exceed the 5-minute cache TTL. Read the last two together: red gap + big rebuild = TTL expiry; warm gap + big rebuild = content invalidation (in this codebase's own data, the dominant invalidation was file edits — a harness serialization quirk documented as DISC-9 in notes.md).

Agentic activity

• Duration per turn — wall-clock split into model wait vs. everything else (empirically, long turns are overwhelmingly model-latency-bound).
• Agentic depth per turn — API round-trips vs. tool calls.
• Events per turn by event name — the full telemetry stream stacked per turn; a tool-heavy turn can be hundreds of events.
• Tool usage mix — session-level tool call counts.
• Lines added / deleted per turn — from ~60 s delta exports with no turn id, so counts are approximate near turn boundaries.

Context window

• Context window breakdown — what each turn's final request context was made of (system tools / MCP tools / system prompt / injected context / user messages / assistant output / tool activity). Bar height is the request's real prompt-side tokens; the split is estimated by character share. "Injected context" is where CLAUDE.md, memory files, and hook output actually live. Turns that switched model get a ⇄ marker: the prior model's thinking blocks are dropped from the prompt on a switch (a stack dip, silently), and the model-scoped prompt cache rebuilds. Needs file-mode raw bodies; sessions captured without them show a notice instead.

08Diagnostics

"Is the pipeline itself healthy?" — localhost:5173/diagnostics

A read-only ops view of ClickHouse, from its own system.* tables — deliberately caption-heavy, doubling as a ClickHouse teaching page. No range or scope: it's about the database, not the spend. Top to bottom: server resources, collector liveness (is data still arriving?), the schema-mismatch quarantine (telemetry rows that didn't match the documented event schema), table/view inventory, storage and compression, merges and mutations, and the slowest recent queries.

In demo mode the page also leads with how old the synthetic corpus is and the command that refreshes it — demo data is a snapshot and nothing reseeds it, so this is where you find out that the shorter ranges have quietly aged out.