← Reddit

Token Consumption and /compact

Reddit · Fluid_Ad_688 · July 28, 2026
So i'm just using claude-code since a month (the basic pro plan) I started with sonnet 4.6 (low), and a week after stayed on Opus4.8 (low) because i used less token since less errors I'm using a few .md memory files to keep th eproject in place, and usually

Detailed Analysis

A Reddit user's detailed account of unexpected token consumption spikes while using Claude Code highlights a recurring friction point in how developers experience Anthropic's usage-based pricing model. The poster, a Pro plan subscriber who transitioned from Sonnet to Opus for coding tasks, reports that despite receiving a "blessed" 50% increase in weekly token allowance, their consumption rate nearly doubled for comparable workloads. Most strikingly, a single `/compact` operation—designed to condense a 650k-token conversation—consumed 30% of their 5-hour usage limit and 3% of their entire weekly allocation, despite compaction ostensibly existing to reduce context bloat rather than add to it.

This complaint touches on a structural tension in how large language model coding assistants manage long-running sessions. The `/compact` command works by having the model summarize prior conversation history into a condensed form, which itself requires a substantial inference pass over the existing context—meaning the "savings" from compaction are backloaded into subsequent turns, not the compaction event itself. When context windows balloon to hundreds of thousands of tokens (as with the user's 650k-token conversation), the summarization pass necessarily processes a proportionally large amount of data, and with Opus-tier pricing being significantly higher than Sonnet, that cost can be substantial even for a single operation. The user's confusion is understandable: intuitively, a compression tool "reducing" context shouldn't itself be a major expense, but the mechanics of how transformer-based summarization works mean the reduction only pays off going forward, not retroactively.

The broader question the poster raises—whether something changed in Anthropic's token accounting or rate-limiting behavior without clear communication—reflects a common pain point among power users of subscription-based AI coding tools. Unlike pay-per-token API access, Pro and Max plan users operate under opaque usage caps that can feel inconsistent day to day, especially as model versions update (the user references moving from Sonnet 4.6 to "Opus 4.8," reflecting the rapid cadence of point-release model updates) or as underlying serving infrastructure, caching behavior, or prompt-processing efficiency shifts. Without granular usage dashboards showing exactly where tokens are spent (context loading, tool calls, thinking tokens, output generation), users are often left reverse-engineering their own consumption patterns through trial and error, as this poster is doing.

This case also underscores a workflow dilemma common to persistent, memory-file-based coding sessions: the tradeoff between maintaining continuity in a single long conversation (which risks costly compaction cycles and context drift) versus starting fresh sessions more frequently (which risks losing project-specific context that `.md` memory files are meant to preserve). As AI coding agents increasingly aim to support multi-day or multi-week projects, this tension between session continuity and token efficiency is likely to remain a central design challenge—both for how Anthropic prices and rate-limits Claude Code, and for how developers structure their own context-management practices to avoid unpredictable cost spikes.

Read original article →