Claude Code Context Bloat Is Mostly Self-Inflicted

Claude Code gives you a lot of rope: a million-token window, subagents, compaction, MCP tools, and increasingly aggressive automation. That is useful until the session starts carrying its own history like dead weight. The practical question for builders is not whether Claude can hold more context. It is whether you should let it.

Anthropic’s own docs are blunt about the core failure mode: performance degrades as the window fills, and a clean restart often beats trying to salvage a messy thread. In other words, context management is not a polish task. It is part of the operating model. ^{1, 2}

Start by shrinking what stays “always on”

The easiest mistake is treating CLAUDE.md, project rules, and long prompt files as a permanent dump site. Claude Code Docs say CLAUDE.md is loaded at session start, so every extra workflow-specific paragraph sits in context even when irrelevant. That makes “helpful” instructions expensive if they are always present. ³

Anthropic’s guidance points the other way: keep the always-on system prompt minimal, and move procedural detail into on-demand skills or tools. The broader context-engineering literature says the same thing more generally: context should be pulled, not pushed. ^{4, 5}

"Your CLAUDE.md file is loaded into context at session start. If it contains detailed instructions for specific workflows (like PR reviews or database migrations), those tokens are present even when you're doing unrelated work."

— Claude Code Docs ³

A good heuristic is to reserve persistent context for identity, house style, and high-level constraints. Everything else should be conditional. If a rule only matters in one workflow, it probably does not belong in the always-on layer. Claude Code’s docs also note that specialized instructions can live in on-demand skills, which keeps the base session smaller. ⁶

Prefer retrieval over hoarding

A recurring theme across the sources is that Claude Code works better when it can discover context just in time. Anthropic describes the model using lightweight identifiers, then pulling files or data only when needed, rather than front-loading everything. That approach reduces both token spend and the chance that irrelevant material crowds out the current task. ⁴

This is also where MCP and tool design matter. If a tool definition is huge, or if a workflow forces the model to repeatedly re-read the same static material, you are paying for the privilege of reminding the model what it already knows. Anthropic’s docs say CLI tools are often more context-efficient than MCP servers because they avoid per-tool listing overhead. ⁶

For codebases with lots of structure, the winning move is usually a small resident map plus targeted retrieval. Keep the file tree, architecture notes, and a few durable decisions handy. Pull full files, logs, or dependency details only when the current step needs them. ^{5, 7}

"The practical rule that falls out: context should be pulled, not pushed. Anything pushed into every request must earn its place permanently."

— Altix Code ⁵

Use subagents to quarantine noise

Subagents are one of Claude Code’s best-built-in defenses against context bloat because they give you separate windows. Anthropic says they are useful when you only need the conclusion, not the whole trail of tool output. That is the key distinction: keep investigative chatter out of the main thread unless it has lasting value. ^{2, 8}

The cost angle matters too. 1 Minute Signal coverage of Nate Herk’s Roast Room system says the creator prefers subagents over broader agent teams because they are cheaper while preserving distinct voices. That is the right mental model for Claude Code as well: separate windows are a containment strategy, not just a convenience feature. ⁹

In practice, use subagents for things like repo exploration, spec verification, and one-off summaries. Bring back only the final answer or the small set of facts you actually need to continue. That keeps the parent session clean and limits the chance that stale tool output starts steering later decisions. ^{2, 10}

"Subagents run in parallel with your main agent but have a completely separate context window."

— Claude Code 101 ⁸

Reset earlier than feels natural

One of the strongest bits of official advice is also the least glamorous: start fresh more often. Anthropic’s best-practices docs say a clean session with a better prompt almost always outperforms a long session with accumulated corrections. That is not a bug in Claude Code. It is how long-context systems behave. ^{1, 11}

The newer docs make the same point more operationally. Claude Code supports /clear, /compact, and /rewind so you can reset, compress, or jump back without dragging every failed attempt forward. Anthropic recommends a new session when a new task begins, and especially when a thread has drifted into repeated corrections. ²

The trap is to keep “fixing” a thread after the model has already gone down the wrong path. Claude Code docs suggest that if you need more than two corrections on one issue, you should clear and re-prompt instead of letting the conversation accrete more mistakes. That advice is less about etiquette than economics: every extra turn is more history to carry. ¹¹

"A clean session with a better prompt almost always outperforms a long session with accumulated corrections."

— Claude Code Docs ¹¹

Audit what your prompts are really doing

Anthropic’s newer cost-management docs are explicit that prompt caching and auto-compaction are now part of the baseline. But they also warn against assuming that automation alone solves the problem. The /usage command, skill diagnostics, and cache summaries exist because teams need visibility into where tokens go. ^{6, 12}

That visibility matters even more after model updates. Anthropic’s token-counting docs note that Claude 4.7 and later use a newer tokenizer that can produce about 30% more tokens for the same input. So if you have not re-measured your prompts recently, your old mental model may already be stale. ¹³

The practical takeaway: audit before you optimize. Find the static files, repeated instructions, and verbose tool definitions that keep getting reloaded. Then decide what belongs in persistent context, what belongs in a skill, and what can be fetched only when a task demands it. ^{3, 14}

Compaction helps, but it is not a cleanup strategy

Claude Code’s auto-compaction and server-side compaction are useful, but they are not magic. Anthropic describes compaction as summarizing earlier parts of a conversation so work can continue past the limit. That preserves continuity, but it does not restore a session to a pristine state. ^{15, 16}

That distinction matters because compaction can also drop things you still need. Backgrind’s note is especially sharp here: after a compact, the next edit is disproportionately likely to violate a rule the agent can no longer see. Put differently, compaction can keep the session alive while silently weakening its guardrails. ¹⁶

If you care about long-running work, structure your rules so the important ones survive compaction. Keep essential conventions at the project root, make skill bodies concise, and avoid scattering critical instructions across nested files that may not be visible after a compact. ¹⁶

Costs are lower when the model sees less

There is a cost story underneath all of this. Anthropic’s API docs say prompt caching is the main lever for repeated content, and batch processing can cut costs by 50% for work that can wait. But for interactive coding, the bigger wins usually come from avoiding unnecessary reprocessing in the first place. ^{17, 18}

That means three things in practice:

• keep repeated instructions short and stable
• avoid re-sending large, static artifacts
• use tools to summarize, filter, or retrieve data instead of stuffing it into every turn ^{10, 19}

Programmatic tool calling is a good example. Anthropic says it can avoid multiple round trips through the model and materially reduce billed input tokens in multi-tool workflows. That is exactly the sort of pattern that keeps context windows from filling with intermediate debris. ¹⁹

Likewise, Claude Code’s recent changes around idle compaction and file mentions are aimed at the same problem: don’t make the next turn pay again for what the system could have compacted or avoided loading. ^{20, 21}

"Token exhaustion is largely a self-inflicted management problem rather than a lack of raw capacity."

— 1 Minute Signal coverage of AI News & Strategy Daily | Nate B Jones ²²

What teams should actually do next

If you are building on Claude Code, the simplest operating rule is this: treat the context window as a working set, not an archive. Start with the smallest durable prompt that still shapes behavior. Put workflows behind skills or tools. Use subagents for exploratory work. Clear aggressively between unrelated tasks. And measure usage often enough to notice when “helpful” context starts becoming expensive context. ^{1, 4, 6}

For most teams, the biggest savings will come from boring discipline rather than clever prompting:

1. shrink CLAUDE.md and project-wide rules
2. move procedure into on-demand skills
3. use subagents for anything disposable
4. compact or clear before the session becomes archaeology
5. watch /usage and token-counting output so you know what changed ^{3, 11, 13}

1 Minute Signal coverage of Nate Herk’s work makes the cautionary point well: the value is in the structure of the debate, not any inherent expertise in the model. Claude Code is similar. The system will help if you design the harness well, but it will not rescue a workflow that keeps feeding it its own leftovers. ^{9, 23}

"Aggressive, recurring audits of your AI prompts are now a functional necessity rather than a maintenance task, as models evolve to interpret complex instructions differently over time."

— 1 Minute Signal coverage of Nate Herk | AI Automation ²⁴