← Reddit

I burned 246M tokens in 22 hours on Claude Code and measured exactly where every one went. The answer surprised me.

Reddit · IndividualEngine8579 · July 26, 2026
An analysis of 246 million tokens consumed during a 22-hour Claude Code session found that actual output comprised only 0.13% of total consumption, with the remainder consisting of context being repeatedly read and rewritten. Cache invalidation—particularly cache writes triggered by actions like pasting images or switching models—emerged as the true cost driver, accounting for 65-75% of actual costs despite representing only 14% of raw tokens. The most productive work window was also the cheapest, indicating that cost tracks context size rather than actual productivity.

Detailed Analysis

A Claude Code power user's forensic breakdown of 246 million tokens consumed across 22 hours of work has surfaced a finding with significant implications for how developers understand — and manage — their usage costs on Anthropic's coding tool. Building a delivery app across four simultaneous iOS simulator sessions, the author hit rate limits far faster than expected on a $100 Max plan, burning 46% of a five-hour window in roughly 20 minutes. Rather than accept vague explanations, they had Claude parse its own session transcript data, stored locally in JSONL logs, to reconstruct exactly where every token went. The result: actual generated output — code, explanations, commit messages — accounted for just 0.13% of total token consumption. The remaining 99.87% was overhead from context being re-read and rewritten on nearly every tool call, a mechanic largely invisible to users who only see a token counter ticking upward.

The more consequential discovery concerns *which* kind of context movement actually drives cost. Cache reads, which let Claude Code reuse previously processed context cheaply, bill at roughly one-tenth the rate of fresh input. Cache writes, by contrast, bill at 1.25x to 2x depending on whether the session uses a 5-minute or 1-hour cache TTL. Because Claude Code defaults to long-lived sessions with 1-hour TTL caching, and because raw token counts obscure this rate asymmetry, the author had spent time optimizing the wrong variable — worrying about total context size when the real drain was cache *invalidation*. Though cache writes made up only 14% of raw tokens in the measured session, they accounted for 65-75% of actual billed cost once reweighted for true rates. Concrete triggers for these expensive invalidations included pasting a single screenshot into an active session (one instance rewrote a 589,235-token prefix, roughly a thousand normal turns' worth of write cost), switching models mid-session, and spawning subagents that carry large context payloads — each of which forces a full rewrite of the cached prefix because those variables are baked into Claude Code's cache key.

This matters because it reveals a gap between how Anthropic's pricing and caching architecture actually behaves and how users intuitively model their own consumption. Most developers reasonably assume that "using less context" or "compacting more often" would control costs, but the article demonstrates that auto-compact — which only triggers near the context ceiling — can let a session sit at 570,000 tokens for hundreds of calls, paying maximum cache-write freight the entire time, while manual `/compact` invocation cut per-call cost by roughly 10x in the author's tests. This is a meaningful, actionable insight for the large community of developers using Claude Code for extended, multi-file, multi-agent engineering sessions, where subagent orchestration and long-running context are increasingly the norm rather than the exception.

The piece also serves a broader diagnostic function within the ongoing debate over Claude Code rate-limit complaints, distinguishing between usage that is genuinely explained by a user's own workflow (image-heavy, multi-agent, long-session work) and usage that reflects server-side metering anomalies Anthropic has previously acknowledged and patched. By publishing a reproducible measurement script — deduplicating transcript records by message ID to avoid a 2x overcounting trap that the author found in "every" similar community-posted script — the analysis gives other users a way to determine which bucket their own experience falls into, rather than relying on anecdote. This reflects a broader trend in the AI coding-assistant space: as usage-based and cache-aware pricing models grow more architecturally complex, the burden increasingly falls on sophisticated users to reverse-engineer billing mechanics themselves, using the AI tools in question to audit their own metering. It also underscores a maturing tension in agentic coding tools generally — between the convenience of large persistent context windows and multi-agent workflows, and the often-hidden cost multipliers those same features introduce.

Read original article →