Usage stats: the "Lord of the Rings" comparison is a vanity metric - no baseline, no breakdown, no action

What I'm reporting

The Claude Code usage dashboard shows a line comparing my token usage to a book:

"You used ~282x more tokens than The Lord of the Rings."

It's entertaining, but it is a vanity metric. It gives a magnitude without any of the things that would let me make a decision.

Why it isn't actionable

1. No baseline. 163M compared to what? My previous month? The median user on the same plan? My plan's ceiling? Without a denominator, "282x" has magnitude but no sign - I can't tell whether it's normal, high, or low.

1. No breakdown. The aggregate hides what actually matters: input vs. output, cache reads (cheap) vs. fresh writes (expensive), resent context vs. new content. Only the breakdown shows where the waste is. A large token count is mostly context resent every turn, which is a very different problem from writing a lot.

1. No economic unit. Tokens aren't the decision unit - cost per completed task is. 163M tokens can be excellent or terrible depending on what they produced. The dashboard doesn't know what I shipped, so it doesn't try.

1. No action. Nothing on this screen leads to "therefore do X" - not compacting sessions, not switching models, not trimming redundant context. Comparing to The Lord of the Rings suggests nothing at all.

What I'd rather see in the same screen space

• Tokens per session: median and p95. The tail sessions are where the waste lives; the mean hides them.
• % of input served from cache. A direct proxy for context efficiency, and the one number a user can actually move.
• Week-over-week trend. Am I getting better or worse?

Three numbers that answer "am I getting better or worse, and where do I change something?" As it stands, the dashboard tells me how much went through the pipe, not whether any of it was well spent.

Context

Heavy daily user: 203 sessions, ~163M tokens across 30 active days. The data needed for all three suggested metrics is already in the local .jsonl transcripts (per-turn input / output / cache-read / cache-creation), so this is a presentation choice, not a data-availability problem.