Detailed Analysis
A Reddit post titled "Compaction is Hot Garbage" has surfaced a detailed, semi-empirical critique of Claude Code's native context-compaction feature, along with a set of alternative approaches the author tested against it. The core complaint is familiar to anyone running long-horizon coding agents: when a session's context window fills up, Claude Code's built-in `/compact` summarizes and discards prior context, and the agent frequently loses track of what it already knew about a codebase. This forces it to re-explore files, re-read directory structures, and rediscover prior decisions—burning tokens and money on work it had effectively already done. The author's frustration is compounded by the common advice to "just write better handoff files," which they point out is essentially manually reimplementing the compaction step that should be handled automatically.
To quantify the problem, the author ran a controlled experiment across 100 SWE-Bench Verified tasks, comparing the baseline native `/compact` against several custom context-management strategies: a deterministic method that simply retains anything the agent actually touched or edited and discards the rest; a neural-network-based trimming approach (labeled "nn," using an unspecified tool called "Parsec"); and variants of each augmented with a lightweight LLM summarization pass ("dir") meant to preserve inferred directives and intent. The headline result wasn't a dramatic jump in task solve rate—all methods hovered in a statistically indistinguishable range around 43-49 out of 100—but a stark difference in efficiency. The baseline agent spent roughly 140k tokens re-exploring context after each compaction event, while every trimming method cut that to around 20k tokens, translating into meaningfully lower per-task costs (dropping from $2.37 to as low as $1.30 in the best case). The author ultimately favored the deterministic "keep what was touched, drop the rest" method for its simplicity, since it captured most of the benefit without the added complexity of neural trimming or summarization passes.
This matters because context management is quickly becoming one of the defining bottlenecks in agentic coding workflows, especially as developers push Claude and similar models toward longer, multi-day, multi-session projects rather than single-shot prompts. As repositories grow and tasks span more files and more back-and-forth, the way an agent's working memory is pruned and preserved has an outsized effect on both cost and continuity of reasoning. A summarization-based compaction approach, while token-efficient in the moment, risks losing the specific, ground-truth details (which files were edited, what decisions were made, why) that matter more to task continuation than a general narrative summary. The deterministic "touched-files" heuristic the author champions is essentially a proxy for relevance grounded in actual agent behavior rather than a model's guess at what mattered.
More broadly, this post reflects a growing grassroots pattern among power users of Claude Code and similar tools: building custom scaffolding—memory files, external trimming logic, orchestration layers—to compensate for perceived gaps in how frontier model providers handle long-running agentic state. It echoes similar community-driven workarounds seen in other agent frameworks, where users treat context window management, not raw model capability, as the primary lever for improving real-world coding performance. Anthropic and competitors like OpenAI have been investing in longer context windows and improved memory features, but posts like this suggest that raw context length is only part of the equation; the mechanism by which context is pruned or compacted when limits are reached may matter just as much, if not more, for maintaining agent coherence across long sessions. As agentic coding tools mature, expect increasing pressure for providers to either open up more granular control over compaction behavior or adopt smarter, more selective retention strategies natively, rather than leaving it to end users to reverse-engineer solutions like the one described here.
Read original article →