Surface cumulative re-read cost in /context: 97.7% of tokens read across 608 sessions were re-reads, and 60% of sessions account for 93% of it

What I'd like

Surface cumulative re-read cost in /context (or /cost), alongside the current fill percentage.

Right now the UI answers "how full is the window." It does not answer "what has this session cost me in re-reading," which on my data is where nearly all token spend actually goes — and unlike window fill, it never goes down.

Why

I measured 608 working sessions from my own transcripts (~174k usage records, Aug 2026, Sonnet 5 / Opus 5 / Opus 4.8 / Fable 5):

=== what the model read ===
  re-read context:  38,450,880,423   97.7%
  cache writes:        893,647,401    2.3%
  new content:          21,745,161    0.1%

=== cost of a long session ===
  1,768 tokens of re-read per token of new content

  sessions peaking >200k: 364 of 608 (60%)
  they account for 93% of all re-reading
  median session peak: 227,712

The distribution is the point: sessions that peak above 200k are 60% by count but 93% of all re-read tokens. Caching keeps the bill survivable — it cuts the re-read cost by ~90% — but what remains is still 77% of my total input cost, and it grows linearly with session length regardless.

The information needed for this is already in the transcript. cache_read_input_tokens per call is exactly "context re-read on this request." Nothing new needs to be computed or stored — only summed and displayed.

Concretely

In /context, one extra line:

Re-read this session: 38.4M tokens (97.7% of input) · ~1,768 per token of new work

Or in /cost, splitting what's already reported into re-read vs new.

Why this changes behaviour

A fill percentage suggests the resource is the window, and that staying under it is free. It isn't: at 60% of a 1M window you are re-reading 600k on every subsequent step. The fill gauge goes back to zero after compaction; the money already spent does not.

Showing the cumulative figure makes the actual tradeoff visible at the moment it matters — when deciding whether to keep going or to dump state and restart clean.

There is a quality argument for the same threshold, independent of cost: NoLiMa (arXiv 2502.05167) finds 11 of 12 tested models drop below 50% of their short-context performance at just 32k tokens, without signalling difficulty. But the cost side is the one that is already measurable from data the tool has on hand.

Scripts

Two stdlib-only scripts that produce the numbers above from ~/.claude/projects/*/*.jsonl, MIT, if useful as a starting point: https://gist.github.com/Socialpranker/9b0e92a2f327570c1cbaed8b003ff1bb

Caveats

• This is one machine, one user. I have no external validation — if the ratio differs wildly for others, the case for surfacing it weakens.
• Summing cache_read + cache_creation + input per call is correct per the caching docs (non-overlapping parts of one number), and I verified subagent records (isSidechain) are not leaking into the main chain: 0 of 83,434 calls above 200k came from sidechains.
• That said, #82863 reports transient ~2x inflation of these same usage totals on retried requests. I scanned 174,276 consecutive main-chain readings across 607 sessions for that self-correcting spike pattern and found 0 occurrences, and none of my 19 compact points exceed the window — so my aggregates look unaffected. But if that bug is real and intermittent, any feature built on these fields should reconcile retries rather than sum them.