Massive token burn: 80% → 11% in ~5 minutes on a single session

Summary

A single Claude Code session consumed context from ~80% to ~11% of the session budget in roughly 5 minutes, despite no individual tool call returning a large payload. The burn appears to come from turn volume + repeated cache-miss re-sends, not a runaway tool result.

Environment

• Claude Code CLI, macOS (Darwin 25.4.0)
• Model: Claude Opus 4.7 (1M context)
• Date: 2026-04-20
• Session ID: 8695a41b-71c2-4a0e-b1bf-0ea6a0972c67
• Account email: gorthidz@gmail.com

Observed behavior

Session transcript analysis (~/.claude/projects/.../8695a41b-*.jsonl):

• 760 assistant turns / 556 user turns in one session
• Tool-use counts: 225 Bash, 71 Edit, 55 Read, 49 TaskUpdate, 32 TaskCreate, 27 Grep, 22 WebFetch, 17 Write, 5 Agent
• Largest single tool_use payloads: ExitPlanMode 25 KB, Write 24 KB
• Tool results stayed small (avg 769 chars, max 25 KB, total ~400 KB)
• No single \"giant blob\" — but every new turn re-sent the growing transcript

Expected behavior

Token consumption should be roughly proportional to new content per turn. Cache-miss amplification on a >1 MB transcript across 225 rapid Bash iterations should not drain ~70% of a session budget in 5 minutes.

Hypothesis

Once a session crosses a few hundred turns, cache-miss re-sends of the full transcript dominate token cost. There does not appear to be an in-CLI warning or automatic compaction threshold that fires before the user notices the drain.

Asks

1. Can the CLI surface a proactive warning (or auto-compact suggestion) when per-turn token cost crosses a threshold?
2. Is there a known issue with cache invalidation on long sessions that would cause repeated full re-sends?
3. Billing clarity: for sessions that burn through context this fast, is there a path to review/refund?

Happy to share the .jsonl transcript privately if useful.