Usage: 91% of a Max subscriber's spend is context re-reading, with no in-product signal (25% of weekly limit in <1 day)

Summary

A Max 20x subscriber consumed 25% of a weekly usage limit in under one day. Investigating locally, 91% of that consumption was context re-reading, not work: sessions grow until they sit at the 1M context ceiling, and from then on every single API call re-reads ~1M cached tokens.

Nothing in the product surfaces this. /usage reports a percentage, but not that each tool call now costs ~$0.50 in cache reads before doing anything. Determining the cause required writing three scripts and parsing ~1.9 GB of local transcripts.

This is not a bug report about incorrect behavior — the mechanics work as designed. It is a report that the default is expensive, the cost is invisible, and the user only discovers it after their limit is gone.

Measured data (local transcripts, 72h window)

Cost figures are list-price equivalents computed from usage fields in ~/.claude/projects/**/*.jsonl, using each message's own model rate (cache read at 0.1x, cache write at 1.25x).

Cost composition — 48h

| Component | Cost | Share | Tokens |
|---|---:|---:|---:|
| Cache read | $1,121 | 59.8% | 2,250,856,326 |
| Cache write | $585 | 31.2% | 94,436,437 |
| Output | $169 | 9.0% | 6,946,029 |
| Input (new) | $0.73 | 0.0% | 149,647 |
| Total | $1,876 | | |

91% of spend is context being re-processed. Actual generation is 9%.

Sessions sit at the context ceiling

Peak cache_read_input_tokens observed on a single request, per session:

| Session | Cost | Peak context |
|---|---:|---:|
| A | $287 | 1,848K |
| B | $121 | 994K |
| C | $106 | 995K |
| D | $349 | 992K |
| E | $356 | 952K |

Opus 5 has a 1M context window. Most long-lived sessions saturate it, so a steady state is reached where every request re-reads ~1M tokens ≈ $0.50 before any work happens.

Cost per user instruction

| Session | User messages | Assistant messages | Ratio | Cost / instruction |
|---|---:|---:|---:|---:|
| A | 9 | 423 | 47x | $8.1 |
| B | 26 | 825 | 32x | $10.3 |
| C | 10 | 276 | 28x | $10.6 |
| D | 40 | 830 | 21x | $8.9 |

One instruction fans out to 20–47 API calls; each pays the ~1M-token re-read. Average cost per instruction: ~$8.9.

Ruled out

I checked these before filing, so they are not the explanation:

• Unattended/runaway execution — hours with token spend but zero user input: $0.00 / 0.0%. Every hour of spend has user messages in it.
• Scheduled tasks — the one Claude-invoking scheduled task had no runs in the window.
• Uncounted subagents — no separate subagents/ transcript trees; subagent usage is already in the main records.

What is missing from the product

1. No context-fill indicator. Nothing shows that a session is at ~1M tokens and that every subsequent call carries a fixed ~$0.50 floor. The user's first signal is the usage limit.
2. /usage shows the "how much" but never the "why." A percentage with no attribution — no per-session breakdown, no cache-read share, no "this session is your biggest consumer."
3. autoCompactWindow defaults to a value that lets context saturate, and is not surfaced anywhere a cost-sensitive user would find it. Setting it to 200000 drops the per-call floor from ~$0.50 to ~$0.10 — an ~80% reduction — with the conversation still continuing via compaction. That is a large, easy win hidden behind an undocumented-in-practice key.

Suggestions

• Show context fill and its marginal cost in the UI, or warn once when a session saturates its window.
• Give /usage a per-session breakdown with a cache-read share, so "where did my week go" is answerable in-product.
• Reconsider the default autoCompactWindow, or prompt the first time a session would benefit from compaction.

Environment

| Item | Value |
|---|---|
| Plan | Max 20x |
| Surface | Claude Desktop (Windows) + terminal CLI |
| Engine | 2.1.229 (Desktop) / 2.1.234 (npm CLI) |
| Model | 92% claude-opus-5, 6.9% claude-opus-4-8, 1.1% claude-sonnet-5 |
| OS | Windows 11 Pro 26200 |

Related: #87366 (long-session stall; same underlying "sessions grow unbounded" theme).