Claude Code Usage Analytics: Local Tools vs Official Dashboards (2026)

Why two layers of metrics matter

When you want Claude Code to run “cleaner,” you are usually looking at more than one kind of number. Official analytics for Team/Enterprise/Console answer organizational questions: accepted lines, suggestion accept rate, activity trends, and—where enabled—GitHub contribution metrics. Personal Pro/Max workflows and day-to-day friction (repeated failures, bloated config, stuck loops) are better served by local analyzers that read transcripts and live configuration on disk.

📑Table of Contents

1. Official analytics vs local analysis: split the jobs
2. What cclens surfaces (doctor, waste, failures, optimize)
3. Adjacent tools: ccusage, cc-lens, session-analyzer, custom hooks
4. Rollout steps and a one-week observation checklist
5. Author Perspective
6. FAQ
7. Summary

What this article covers

This article cross-checks Anthropic’s first-party docs and Help Center, the primary lambdalisue/cclens README, ccusage and adjacent tools, plus independent write-ups from Shipyard and READYFOR.

The goal is a practical choose-and-combine map—not a rewrite of a discovery blog post. Bookmark popularity is a discovery signal only, not factual evidence for adoption.

Learning outcomes

---

Official analytics vs local analysis: split the jobs

Do not expect one dashboard to solve both team adoption KPIs and personal session friction. Official surfaces are strong for org reporting; local tools are strong for history, inventory, and failure patterns.

What official dashboards answer

Anthropic’s English docs (Track team usage with analytics) describe Team/Enterprise dashboards at claude.ai/analytics/claude-code with:

• usage metrics (accepted lines, suggestion accept rate, DAU/sessions)
• contribution metrics (public beta)
• leaderboards
• CSV export

Contribution requires an Owner to enable analytics and a GitHub admin to install the Claude GitHub app. ZDR orgs get usage only—no contribution.

Attribution rules (conservative by design)

Attribution is intentionally conservative:

• high-confidence matches only
• effective lines after normalization longer than three characters
• a session window from 21 days before merge through two days after
• exclusions for lock/generated/build-like paths
• a claude-code-assisted label on merged PRs

Help Center scope (Team/Enterprise/Console)

The Japanese Help Center article (Claude Code usage analytics, last updated 2026-07-01 in the captured notes) confirms the same audience boundary: Team/Enterprise owners and API Console roles.

• Usage tab: accepted lines, accept rate, activity, top commands, CSV
• Value tab: estimated productivity, cost per commit, estimated annual value with adjustable assumptions
• Contribution metrics: public beta

Individual Pro/Max plans do not get the organizational dashboard. The first Claude Code version with the feature set noted there is v2.0.28.

In-session commands and the Pro/Max gap

In-session /usage (aliases /cost /stats) and /context help with the current window and context pressure. They are weak for cross-session history and config inventory.

Shipyard’s independent review (How to track Claude Code usage + analytics) compares Console, slash commands, historical ccusage, and real-time monitors such as cmonitor, and calls out the Pro/Max gap where per-token Console detail is limited.

Source

Official-layer matrix

Layer	Primary surface	Best question	Typical user	Limit
Official Team/Enterprise	claude.ai/analytics/claude-code	Accepted lines, accept rate, DAU/sessions, leaderboard	Owner/Admin	No org dashboard for personal Pro/Max
Official contribution (beta)	GitHub app + claude-code-assisted	Conservative PR/line attribution, ROI narrative	Team/Enterprise + GitHub admin	Unavailable under ZDR; not on API Console GitHub path
Official Console	platform.claude.com/claude-code	Accepted lines, accept rate, spend, per-user	API customers	No contribution; estimates are not the invoice

Session and cost local matrix

Layer	Primary surface	Best question	Typical user	Limit
In-session slash	/usage /context	Current session quota and context pressure	Everyone	Weak for history and config inventory
Cost history CLI	ccusage	Daily/session/project token and USD estimates	Pro/Max individuals to multi-CLI users	Not real-time; not a billing ledger
Real-time	cmonitor etc.	Live tokens / limit ETA	People burning quotas	Not deep friction/config optimization

Friction, quality, and custom local matrix

Layer	Primary surface	Best question	Typical user	Limit
Friction/config lens	cclens	waste/inventory/failures/stuck, doctor, optimize	Anyone with local transcripts	Not billing ground truth; local read-only model
Quality metrics	claude-session-analyzer	Behavioral ratios such as Read:Edit	People tracking quality signals	Different system from cclens
Custom pipeline	SessionEnd hooks etc.	Session recaps and repeated corrections	In-house teams	Ops cost

Sources

• Claude Code analytics (EN docs)
• Claude Code usage analytics (JA Help)
• Shipyard (as of August 2026)

Bottom line

Use official analytics as the primary surface for org KPIs; use local tools as the primary surface for personal cost and friction. Combine when needed—do not collapse the questions.

---

What cclens surfaces (doctor, waste, failures, optimize)

What the lens is for

cclens is a lens on time, tokens, and effort waste—not a replacement invoice.

Per the lambdalisue/cclens README, it reads session transcripts and live configuration into a local SQLite store (cclens.db), stays read-only, and does not send data out.

• Counts are usage signals, not a billing ledger
• The store is a regenerable cache

Install paths

Common install paths:

1. Try: nix run github:lambdalisue/cclens -- doctor
2. Keep: nix profile install, or flake + just build / cargo build --release
3. Claude Code plugin: /plugin marketplace add lambdalisue/cclens → /plugin install cclens@cclens
4. Skills: /cclens:doctor, /cclens:optimize, /cclens:query

Command map

• doctor — prioritized health (what to fix first, cost, config worth pruning, looks healthy)
• analyze — incremental extraction
• sql — read-only SQL (stdin supported)
• optimize — passes findings to interactive claude via a private temp path (not CLI argv)
• curated views: waste, inventory, failures, stuck, usage, prompts, and more (--format json on all commands)

Data sources and breaking renames

It reads:

• ~/.claude/projects transcripts
• ~/.claude/*
• project .claude/ / CLAUDE.md

Around 2026-07-10, breaking renames landed without aliases:

• summary→doctor
• wedges→waste
• surfaces→inventory
• baseline→overhead
• friction→failures
• thrash→stuck

Old cheat sheets break; rebuild the DB after schema changes.

A practical loop

A practical loop is:

1. Run doctor to pick one fix
2. Corroborate with failures / waste
3. Optionally run optimize

Because optimize can launch Claude Code, it may spend extra tokens. Prefer one change family per week over continuous full-surface optimization.

---

Adjacent tools: ccusage, cc-lens, session-analyzer, custom hooks

cclens is not the only valid entry point. Choose by primary question.

Cost and friction tools

Tool	Primary job	Quick start	Data	Strength	Weak fit
cclens	Friction/config/waste lens	nix/cargo/plugin	~/.claude + project config	doctor/optimize, SQL, JSON	Multi-CLI cost rollup as primary
ccusage	Token/USD history	npx ccusage@latest report daily	Local usage logs across CLIs	Multi-CLI, cache split, offline pricing, JSON	Config inventory / failure patterns
cmonitor	Real-time quota	pip/uv cmonitor	local	Limit ETA	Deep historical friction analysis

Dashboard, quality, and custom ops tools

Tool	Primary job	Quick start	Data	Strength	Weak fit
Arindam200/cc-lens	Local dashboard	npx cc-lens	~/.claude/ family	UI, 5s refresh, no telemetry	cclens-style optimize flow
lucemia/claude-session-analyzer	Quality benchmarks	Python / plugin	session JSONL	Read:Edit-style tables	Config cost inventory
READYFOR custom	Session recaps / repeated nits	SessionEnd hook	transcript_path	118-session ops lessons	Not a packaged product

Comparison sources

• ccusage.com
• Arindam200/cc-lens
• lucemia/claude-session-analyzer
• READYFOR on Zenn
• Shipyard (as of August 2026)

ccusage for spend shape

ccusage aggregates local usage logs across many agent CLIs (Claude Code, Codex, Gemini CLI, and peers).

• keeps data local
• separates cache create/read
• supports JSON plus offline pricing

It is the low-friction answer when the first question is spend shape.

cc-lens and session-analyzer

Arindam200/cc-lens starts a local dashboard with npx cc-lens and no telemetry. It is a separate implementation from lambdalisue/cclens—similar names, different product shape (UI vs doctor/optimize/SQL).

lucemia/claude-session-analyzer quantifies session quality signals such as Read:Edit ratios. README benchmarks include >6 good / <2 degraded. Use it when behavioral quality is the primary metric.

READYFOR field notes

READYFOR’s public write-up treats official /insights as useful for cross-session overview but insufficient for immediate session retrospectives. Their SessionEnd hook pipeline produced the following field notes:

• 118 reports in 12 days
• top repeated nits included PR template mismatches (18) and commit granularity (15)
• about 40% of 177 improvement suggestions skewed toward adding CLAUDE.md rules
• they argue hooks/skills automation often works better
• batch analysis can reach ~150k tokens

If you build something similar, copy the recursion guard (CLAUDE_SESSION_ANALYSIS=1) and background/timeout design before scaling to a team.

Selection heuristic

Selection heuristic:

1. Org KPIs / GitHub ROI → official analytics
2. How much did we spend (personal / multi-CLI) → ccusage (± cmonitor)
3. What is wasteful and what should change → cclens (± session-analyzer)
4. Kill repeated team nits → custom hooks or operationalize cclens optimize

---

Rollout steps and a one-week observation checklist

Use this as a minimal operating procedure. Success depends on keeping a single primary goal.

Steps 1–4: pick goal and first tool

1. Pick one goal: A cost visibility / B friction reduction / C org adoption KPI. Do not chase all three at once.
2. Confirm official eligibility: Team/Enterprise/Console vs Pro/Max. If ZDR, assume contribution is unavailable.
3. Satisfy local prerequisites: transcripts under ~/.claude/projects; decide secret handling for shared machines.
4. If cost-first, start with ccusage: npx ccusage@latest report daily and note project skew.

Steps 5–8: observe and scale carefully

5. If friction-first, start with cclens: nix run github:lambdalisue/cclens -- doctor or install the plugin → analyze → failures / waste / inventory.
6. One-week rule: change at most one family (drop an unused skill, trim always-on weight, fix the top failure path). Avoid full rewrites every day.
7. Judge effect: rerun a similar task and compare failure counts, stuck signals, /usage burn, and subjective lead time. If nothing moved, change the metric before adding tools.
8. Team rollout: prototype personally first; add recursion guards and timeouts before shared hooks.

Adoption checklist

• ✓ Goal is exactly one of A/B/C
• ✓ Official dashboard plan eligibility confirmed
• ✓ Local log privacy/retention decided
• ✓ Either ccusage or cclens chosen as primary
• ✓ Agreement to fix only the top doctor/failures item first
• ✓ Anthropic billing/plan UI is billing ground truth; CLI numbers are signals
• ✓ Breaking renames (doctor, etc.) captured in a cheatsheet

Constraints

• cclens/ccusage numbers are signals/estimates, not final invoices
• optimize may consume extra tokens
• Old command names such as summary / friction are invalid after renames
• Discovery-post popularity is not an adoption reason

---

Author Perspective

Three decision criteria

Three decision criteria keep the choice stable:

1. Whether the question is org-dashboard accountability or local friction/cost signals
2. Whether observation targets can be fixed to one item before adding another tool
3. Whether secret-handling policy can differ between personal and shared machines when local transcripts are in scope

Common misreads

Expecting one surface to answer cost, friction, and org ROI together is a common miss. Public docs and third-party field reports mainly show that accountability metrics and improvement signals sit on different layers.

READYFOR’s skew toward CLAUDE.md additions is a useful caution that more rules text is not always the highest-leverage fix.

“No network upload” also does not mean “no secrets on disk”—treat local transcripts as sensitive even when the analyzer is read-only.

---

FAQ

Q1. Are official analytics enough on Pro/Max alone?

• Org dashboards target Team/Enterprise/Console
• Individuals mainly use /usage//context plus local CLIs (JA Help / Shipyard)

Q2. Should I install cclens or ccusage first?

• Cost history first → ccusage (npx one-liner)
• Config waste/failure patterns first → cclens
• Combining is often rational

Q3. Does cclens send data externally?

• The README describes read-only local analysis with no send path and a local SQLite store
• Still treat transcripts as sensitive

Q4. Are contribution metrics inflated?

• EN docs describe a conservative underestimate
• high-confidence matches only, large rewrites excluded, generated artifacts excluded

Q5. Can /insights alone drive team improvement?

• READYFOR treats it as good for overview, weak for session-level retros, and pairs it with hook-based recaps
• Avoid CLAUDE.md-only remediation bias

Q6. Are cc-lens (Arindam) and cclens the same project?

• No. One is a dashboard UI; the other is a doctor/optimize/SQL CLI lens
• Verify the repository before installing

---

Summary

• Official surfaces own org KPIs; local tools own personal friction and cost signals
• cclens answers “what should we fix,” ccusage answers “what did we spend,” official analytics answer “who is adopting how”
• Next action: one goal → one primary tool → one weekly change → confirm money on the billing UI
• Use first-party docs and independent implementations as decision evidence; treat discovery posts as entry points only

For adjacent configuration work, see Keeping Claude Code and Codex configs in sync, CLAUDE.md design patterns, and OpenAI Codex plugin for Claude Code.