When context windows first hit 100K tokens, the reaction was "great, now we can just load everything." When they hit 200K, that reaction intensified. In practice, teams that treat large context windows as abundant produce worse results than teams that treat context as a scarce resource. Not because the models can't handle long context — they can — but because attention degrades before capacity does, and every token loaded competes with every other token for that attention.
Context is a budget, not a capacity. Treating it as capacity leads to the same mistake as treating memory as capacity in software engineering — you can fill it, but the system runs worse than if you'd been disciplined. This post is the framework we use to allocate context deliberately, plus the specific pruning strategies that made our large-context sessions perform better than our small-context ones.
Why context isn't capacity
Modern LLMs handle 200K token contexts. That doesn't mean they use all 200K tokens equally well. Three well-documented effects work against you:
Attention degrades with context length. Not linearly, but real. Content in a 180K-token context has less effective attention than the same content in a 20K-token context. This isn't a claim about "the model can't find it" — the model can retrieve it. It's about influence on generation. Content loaded but not attended to is worse than content not loaded, because the model still had to process it while paying less attention to what mattered.
The middle gets forgotten. The classic "lost in the middle" pattern: content at the beginning and end of long contexts gets more attention than content in the middle. If your important guidance is buried in the middle of a 100K-token context, it may effectively not be there.
Cost scales with tokens loaded, not just tokens used. A session with 150K tokens of input costs 3x a session with 50K tokens of input, even if the actual work involves the same generation output. Loading tokens you don't need is pure waste.
Together, these effects turn context length into a spending trade-off. Load more, get more coverage but less-focused attention and higher cost. Load less, risk missing important context but get sharper focus and lower cost. The right balance is task-dependent; treating it as "just load everything" is almost always wrong.
The priority-tier framework
When we started thinking of context as a budget, we needed a framework for allocating it. Ours has four tiers, allocated in priority order:
TIER 1: CRITICAL (target: <10% of budget)
- The specific task or question
- Constraints and definitions of "done"
- Directly-referenced files/data
TIER 2: HIGHLY RELEVANT (target: 20-30% of budget)
- Files the task will modify
- Immediate dependencies of those files
- Domain-specific guidance for this task
TIER 3: CONTEXTUALLY USEFUL (target: 30-40% of budget)
- Broader codebase context
- Related patterns from similar work
- Historical decisions relevant to this area
TIER 4: NICE-TO-HAVE (target: cut hard)
- General style guides
- Full architecture overviews
- Everything else that "might be useful"The percentages aren't rigid — they're anchors. The point is: Tier 1 is always small, Tier 4 gets cut first when budget pressure appears, and Tier 2/3 are where most of the budget goes for most tasks.
Applying the tiers to a real session
Consider a session for "fix a bug in the user authentication flow." Applying tiers:
- Tier 1 (5% of context): The bug description, the specific error message, the failing test.
- Tier 2 (25% of context): The auth flow code (3-4 files that will be modified), plus the interfaces they consume.
- Tier 3 (35% of context): The user model definition, session handling code, recent PRs that touched this area.
- Tier 4 (cut): Full codebase style guide, unrelated services, architecture doc for the whole system.
- Remaining 35%: reserved for the conversation itself — messages and tool outputs during the session.
What we DON'T do: load "everything auth-related" plus "everything user-related" plus "everything session-related" plus "the general style guide." That would fill context to 90%+ and dilute attention across content that doesn't need to influence this specific bug fix.
The categories of context that bloat sessions
In practice, four categories of content tend to over-consume context budget:
Bloat source 1: Full-directory loads
"Load all files in src/auth/" when only 2-3 of them are relevant to the specific task. This is the most common single bloat source — engineers treat "load the whole directory" as the safe default because they're not sure what's needed.
Better pattern: start with a focused set (the files you think you need), let Claude request more if needed. The extra roundtrip is cheaper than the context tax of loading everything preemptively.
Bloat source 2: Historical conversation carrying
Long sessions accumulate history. By hour two of a session, the first hour of conversation may not be relevant to the current task — but it's all still in context, still consuming budget, still competing for attention.
Better pattern: start fresh sessions for logically-separate tasks. If you're switching from "debug auth bug" to "add new feature," don't keep the debug session going. Fresh context; cleaner attention; often better output.
Bloat source 3: MCP and skills ambient load
Every configured MCP and every ambient-loaded skill costs context on every session. See the MCP pruning post and CLAUDE.md post for the details. This is systemic bloat that affects all sessions; fixing it once helps every future session.
Bloat source 4: Speculative includes
"This might be relevant" additions. Someone asks Claude to fix a bug, and includes the API docs, plus the config docs, plus the deployment guide, "just in case." Almost none of it gets used; all of it costs attention.
Better pattern: include the specific thing you need for the specific task. If Claude needs more, it can request more (or you can add more). Speculative inclusion is a false economy — the cost of the extra context outweighs the saved roundtrip.
Pruning strategies
When you're over budget (or want to be more efficient), several pruning strategies work:
Strategy 1: Structured summarization
Instead of loading the full 800-line file, load a structured summary: exported functions, key data types, brief description of each function's purpose. 200 tokens instead of 3000, capturing 80% of what most tasks need.
Trade-off: the summary might miss the specific detail this task needs. If it does, Claude can request the full file. Iteration cost < context tax.
Strategy 2: On-demand loading via tools
Rather than pre-loading files into context, expose file-reading as a tool. Claude reads files it needs, when it needs them. Sessions start with minimal context; grows as needed.
This is what Claude Code does by default — the Read tool, Grep tool, Glob tool let Claude discover context dynamically. Sessions that skip pre-loading and let Claude discover are usually more efficient than pre-loaded ones.
Strategy 3: Explicit context resets
For long sessions, explicit "let's clear context and start fresh with just X, Y, Z" resets. Functionally equivalent to starting a new session but preserves the useful learning from the previous portion.
Some Claude Code deployments support this via commands. Others require actually starting fresh. Either way: recognize when accumulated context is hurting more than helping and reset deliberately.
Strategy 4: Compress not eliminate
Sometimes the content genuinely matters but the size doesn't need to be full. A 5000-token architecture doc can often be compressed to a 500-token summary that captures the essentials for most tasks. The full doc stays available (as a linked resource); the compression covers most sessions.
A discipline we've found valuable: at the end of each session, ask Claude to list "what context was actually used for producing the output." Compare to what was loaded. The gap between loaded and used is what to prune next time. Usually you'll be surprised how much of the loaded context wasn't referenced.
The measurement that convinced us
The specific measurement that changed our team's intuition about context: we ran the same 20 tasks in two modes.
Mode A ("load everything relevant"): pre-load all files that might be relevant. Average context per task: 65K tokens.
Mode B ("start focused, expand as needed"): load only clearly-necessary files. Let Claude request more via tools. Average context per task: 22K tokens.
Results across the 20 tasks:
- Task quality: Mode B slightly higher (12/20 rated better vs 5/20 for Mode A, 3 ties).
- Task latency: Mode B 30% faster on average (less input to process).
- Task cost: Mode B 55% cheaper (less input tokens).
- Task success rate: 18/20 for both modes (2 failed in Mode B needed manual re-run with more context; 2 different tasks failed in Mode A due to confused attention).
The failures differed: Mode B failed by not having enough context; Mode A failed by having too much context to attend to properly. Different failure modes, similar aggregate rate. But Mode B was much cheaper and faster on the successes — a net win despite occasional context-shortage retries.
The mental shift
The hardest part of this framework isn't the mechanics. It's the mental shift from "context is abundant, load broadly" to "context is scarce, load precisely."
The abundance framing feels natural because context windows keep getting bigger. If they were 4K tokens (as they were in early 2023), scarcity would be obvious. At 200K, scarcity feels theoretical. But the same principle applies — attention degrades, cost scales, focus matters. The absolute threshold moved; the discipline didn't become obsolete.
Teams that hold onto the "load everything" habit as windows grew are the ones paying most for the least output quality. Teams that maintain context discipline get the productivity benefit of large windows (more headroom for the important content) without the attention penalty (loaded content that competes with focus).
Big context windows are abundance for content that matters. They're not abundance for content in general — loading indiscriminately still degrades attention on what matters.
The starting practice
If you're currently loading context abundantly, try one week of budgeted context. Pick the tier framework. Load only Tier 1 and Tier 2 for each task. Let Claude request more via tools when needed. Compare quality, cost, and latency to your baseline.
Almost certainly, the results will be at least as good — usually better — while costing meaningfully less. The abundance instinct is wrong even at 200K tokens. Budgeted context is one of the highest-leverage practices for both cost and quality that a team can adopt.
Get cctk running in one command
85 slash commands, 12 subagents, 12 MCP integrations, 12 hooks. All the patterns from this post are shipped in cctk.