Context Budget Mastery
Master the art of managing Claude Code's context window for maximum productivity.
Goal
Help users understand exactly where context is consumed, plan sessions that avoid hitting limits, and recover gracefully when context gets tight.
Context Window Sizes
| Model | Context Window | Practical Limit | |-------|---------------:|----------------:| | Opus 4.6 | 200,000 tokens | ~180,000 usable | | Sonnet 4.6 | 200,000 tokens | ~180,000 usable | | Haiku 4.5 | 200,000 tokens | ~180,000 usable |
The ~20k overhead comes from system prompt, tool definitions, and framework messages that are always present.
Token Arithmetic
What consumes context
Every request to Claude includes ALL of the following:
| Component | Loaded When | Typical Size | Cached? | |-----------|-------------|-------------:|---------| | System prompt | Every turn | 3-5k tokens | Yes (after turn 1) | | CLAUDE.md (all levels) | Every turn | 2-20k tokens | Yes (after turn 1) | | Rules (unconditional) | Every turn | 1-10k tokens | Yes (after turn 1) | | Rules (path-scoped) | When matching files opened | 0-5k tokens | Partially | | Skill descriptions | Every turn | 1-5k tokens | Yes | | MCP tool schemas | Every turn | 2-15k tokens | Yes | | Conversation history | Every turn (grows) | 5-150k tokens | Partially | | Tool results (latest) | Current turn | 0-10k tokens | No |
The growth problem
Context grows with every turn because conversation history accumulates:
- Turn 1: ~30k (system + CLAUDE.md + rules + skills + MCP + message)
- Turn 5: ~50k (+ 4 turns of Q&A and tool calls)
- Turn 15: ~100k (+ tool outputs, file reads)
- Turn 30: ~180k (approaching limit — auto-compact triggers)
Fixed vs. variable budget
Fixed overhead (always loaded):
System prompt ≈ 4,000 tokens
CLAUDE.md files ≈ 5,000 tokens (varies)
Unconditional rules ≈ 3,000 tokens (varies)
Skill descriptions ≈ 2,000 tokens (varies)
MCP tool schemas ≈ 5,000 tokens (varies)
─────────────────────────────────────────────────
Total fixed overhead ≈ 19,000 tokens
Variable (grows with session):
Conversation history = grows per turn
Tool results = per tool call
Loaded skill bodies = when skills activated
Path-scoped rules = when matching files read
Your effective working budget = 200,000 - fixed overhead - safety margin
Anchor Budget Math
What are anchors?
Anchors are pieces of context you want to survive /compact. Without anchoring, compaction summarizes everything, potentially losing critical state.
Calculating anchor budget
Rule of thumb: anchors should consume < 10% of your context window.
Context window: 200,000 tokens
Target anchor budget: 20,000 tokens (10%)
Available for conversation: 180,000 - fixed overhead
What to anchor
Priority anchoring targets:
- Current task definition and constraints
- Key decisions made during the session
- File paths and line numbers of changes in progress
- Error messages being investigated
- Architecture notes discovered during exploration
What NOT to anchor
- File contents (can be re-read)
- Full conversation history (that's what compact summarizes)
- Tool output (can be regenerated)
- Generic instructions (already in CLAUDE.md)
Compact Strategies
When to compact
| Signal | Action | |--------|--------| | Auto-compact triggers (system message) | Let it happen, but consider manual compact first | | Context utilization > 70% | Good time for proactive compact | | Shifting to a new sub-task | Compact to clear old context | | After a long research phase | Compact before implementation | | After reading many files | Compact to summarize findings |
Focus strings
When compacting, provide a focus to guide summarization:
/compact Focus on the auth middleware refactor: keep the API contract, test failures, and migration plan
Good focus strings:
- Name the specific task
- List what must survive
- Mention key file paths
Bad focus strings:
- Empty (default summarization may miss important details)
- Too broad ("keep everything important")
- Too narrow ("only keep line 42 of auth.ts")
What survives compact automatically
- CLAUDE.md content (re-read from disk)
- Rules files (re-read from disk)
- Skill descriptions (re-injected)
- MCP tool schemas (re-injected)
- Auto-memory notes (persisted to disk)
What does NOT survive compact
- Conversation details (summarized, not preserved verbatim)
- Tool outputs (lost unless anchored)
- In-progress reasoning (summarized)
- File contents you read (must re-read)
Progressive Loading
The 82% savings pattern
Skills use progressive loading:
- At startup: only frontmatter (name, description, triggers) loaded — ~50 tokens per skill
- When activated: full skill body loaded — ~500-2000 tokens per skill
With 30 skills:
- All loaded: 30 × 1000 = 30,000 tokens
- Progressive: 30 × 50 + 3 active × 1000 = 4,500 tokens (85% savings)
Applying progressive loading to your content
- Keep CLAUDE.md focused on routing and short rules
- Move reference material to skills (loaded on demand)
- Use path-scoped rules (loaded only for matching files)
- Use
@pathimports for large documents (loaded but can be excluded)
Large Codebase Patterns
When a repo is too big for one session
Signs you need to partition:
- Reading more than 30-40 files per session
- Context fills up before implementation starts
- Frequent auto-compaction interrupts
Partitioning strategies
- Module-by-module: tackle one module per session
- Research then implement: research session → notes → implementation session
- Subagent delegation: main context stays clean, subagents explore
- Multi-session plan: plan in session 1, implement in session 2-N
Using subagents for context isolation
Main context: task planning, implementation
└── Subagent 1: research existing patterns (Haiku)
└── Subagent 2: explore test coverage (Haiku)
└── Subagent 3: review dependencies (Haiku)
Each subagent gets its own 200k context window. Only summaries return to main context.
Anti-Patterns
| Anti-Pattern | Problem | Fix |
|-------------|---------|-----|
| CLAUDE.md > 500 lines | Eats working budget every turn | Split into rules and skills |
| 10+ unconditional rules | High fixed overhead | Path-scope where possible |
| All skills model-invocable | Description tokens add up | Use disable-model-invocation: true for manual-only skills |
| Too many MCP servers | Schema tokens accumulate | Disconnect unused servers (/mcp) |
| No compaction strategy | Hit limit unpredictably | Compact proactively at 70% |
| Reading entire large files | Each read adds thousands of tokens | Use Grep to find specific content |
| Ignoring auto-memory | Re-discovering the same facts each session | Let auto-memory persist findings |
Quick Reference
Context health check
/cost → see current token usage
/compact → manually compact context
/memory → see what CLAUDE.md/rules are loaded
/mcp → see MCP server token costs
/model → check/change current model
Rule of thumb targets
| Metric | Target | |--------|--------| | Fixed overhead | < 25k tokens (12.5% of 200k) | | Working budget | > 150k tokens | | Compact trigger | 70% utilization | | Anchor budget | < 20k tokens | | Skills active at once | ≤ 5 | | MCP servers connected | ≤ 5 |