Claude Code burns ~15–20% of your tokens on a 3-word status line

Discussion overview

The thread focused less on the tiny status message itself than on what it reveals about Claude Code’s accounting model: repeated context passes, short cache lifetimes, aggressive compaction, and a harness that users cannot fully control. Several readers argued that cached transcript reads should make the overhead cheap, but others stressed that even discounted reads compound when the same long context is replayed repeatedly. A five-minute cache window makes the cost especially sensitive to timing, so a seemingly harmless background update can become an expensive fresh prefill.

The headline’s 15–20% figure did not survive scrutiny unchanged. One hands-on test found the behavior limited to subagents rather than ordinary workflows, with roughly 8% overhead in that user’s sessions; another reported only 3% across a broader deployment. Even so, commenters saw an unavoidable multi-percent burn as hard to defend when it cannot be disabled. Some noticed recent quota behavior improving, attributing it to more aggressive context compaction or an experiment, while others still reported subscriptions exhausting unusually fast. The sharpest criticism was institutional: an inference vendor that owns the coding harness benefits when its product sends more tokens. A minority still considers Opus uniquely useful for difficult delegation, but increasingly routes routine coding and review through leaner or competing tools.

Points of disagreement

The core dispute is whether the status-line overhead is a costly systemic tax or a narrow, mostly cached implementation detail. Defenders say it primarily affects subagents, cached reads are cheap, and observed overhead can be only a few percent; critics answer that repeated long-context reads and cache expiry turn even discounted tokens into substantial quota loss, especially when users cannot opt out.