Your Agent's Context Fills Up Before You Type: What to Trim First

Most advice about coding agents is about what you type. But by the time you type your first prompt, the agent's context window is already partly full: instruction files, memory, tool names, skill descriptions. Then every file it reads, every test run and every long log adds more, and all of it is re-sent with every request.

That matters for more than your bill. In Effective context engineering for AI agents, Anthropic describes context rot: as the number of tokens in the window grows, the model's ability to accurately recall information from it goes down. Their framing is that a model has an "attention budget", and every token you add spends some of it. The guiding principle they give is to "find the smallest set of high-signal tokens that maximize the likelihood of your desired outcome."

I covered the money side in Where Your Coding Agent's Token Bill Goes. This one is about quality: what fills the context, and what to trim first so the agent has room to think about your actual task. The examples use Claude Code because its docs spell out exactly what loads and when, but the order works for any agent.

Step 1: Look before you cut

Don't guess. In Claude Code, run /context. The context window docs describe it as a live breakdown by category, with optimization suggestions, including which CLAUDE.md and auto memory files loaded.

According to the same page, this is what loads before you type anything:

• CLAUDE.md (or AGENTS.md in its place) and auto memory
• MCP tool names
• skill descriptions
• anything your own setup adds, like an output style or --append-system-prompt text

Write down the three biggest categories. That's your trim list, in order. If you don't use Claude Code, the question is the same: what does your agent load at startup, and which of those things did you actually need today?

Step 2: Trim the tools

Anthropic calls bloated tool sets "one of the most common failure modes": too much functionality, or tools that overlap so the model can't tell which one to use. Their test is a good one to borrow: if a human engineer can't say for sure which tool fits a situation, the agent can't be expected to do better.

Claude Code already softens the cost here. Per its MCP docs, tool search is on by default, so only tool names and server instructions enter context at session start; full definitions load when Claude actually needs a tool. That doesn't make every connected server free, though, and it doesn't fix overlapping tools. Three things still help:

1. Disable servers you aren't using. Run /mcp and switch off anything unrelated to the current project.
2. Prefer a CLI when one exists. The cost docs say tools like gh, aws, gcloud and sentry-cli are still more context-efficient than MCP servers, because they don't add any per-tool listing.
3. Check tool search is actually on. It's off in some setups, for example older models, some cloud deployments or when ENABLE_TOOL_SEARCH=false is set, and then all MCP tools load upfront. If /context shows a large tools category, this is the first thing to look at.

If you write your own MCP server, the docs suggest keeping descriptions and server instructions concise and putting the important words near the start, since that's the part tool search reads.

Step 3: Trim what loads from files

Instruction files load every session, whether the task needs them or not. Claude Code's memory docs recommend keeping each CLAUDE.md under 200 lines, and note that imports help you organise a long file but don't reduce its context cost, because imported files load with it.

The fix is to move instructions to where they're needed:

• Path-scoped rules in .claude/rules/ load only when Claude works with matching files.
• Skills load only when invoked, so a long PR-review or migration procedure costs nothing on days you don't use it.

A path-scoped rule looks like this:

---
paths:
  - "src/api/**/*.ts"
---

# API rules
- Every endpoint validates input with the shared schema.
- Errors use the standard error response format.

I went through the full cut-and-move process in Your CLAUDE.md Is Too Long, so I won't repeat it here. One addition that's easy to miss is in Step 5 below: path-scoped rules don't survive compaction the way root instructions do.

Then look at what the agent reads during work. Vague prompts trigger broad scanning; the cost docs contrast "improve this codebase" with "add input validation to the login function in auth.ts". The second one lets the agent find what it needs with far fewer file reads.

Step 4: Keep noisy output out of the main window

Test runs, log files and documentation pages are the quiet context killers. A failing test suite can print thousands of lines when you needed ten.

Two options from the docs:

• Filter before the model sees it. The cost docs show a PreToolUse hook that rewrites test commands to keep only failure lines, and give the example of a hook that greps a 10,000-line log for ERROR instead of letting Claude read all of it.
• Delegate to a subagent. A subagent does the reading in its own context window and sends back only a summary. The docs recommend this for running tests, fetching documentation and processing logs. It isn't free, since the subagent's requests still count toward your usage, but the raw output stays out of your main conversation.

Anthropic's post lists the same idea from the other direction: once a tool result is deep in history, the agent rarely needs to see the raw output again, and clearing old tool results is one of the lightest forms of compaction.

Step 5: Manage history on purpose

The longest-lived thing in your context is the conversation itself. You have two tools for it, and they do different things.

/clear when the task changes. Old conversation crowds out the files you need next and is re-sent with every message. The docs point out that /clear costs nothing, while /compact is itself a large request because it has to read the whole conversation it summarises. If you don't need continuity, clear. Use /rename first if you want to /resume that session later.

/compact with a focus when you do need continuity. Claude Code compacts automatically near the limit, but the automatic pass guesses what matters. Telling it is better:

/compact focus on the auth bug fix

You can also put standing instructions in your project's CLAUDE.md, as the docs show:

# Compact instructions

When you are using compact, please focus on test output and code changes

Before relying on compaction, know what comes back. Per the context window docs, after compaction:

• the project-root CLAUDE.md, unscoped rules and auto memory are re-injected from disk;
• path-scoped rules and nested CLAUDE.md files are summarised away and reload only when Claude touches a matching file again;
• Claude Code re-reads up to five recently modified files it had used, and a file over 5,000 tokens comes back as a path reference, not its content;
• invoked skill bodies are re-injected but capped, and truncation keeps the start of the file.

So if a rule must hold for the whole session, don't scope it to paths; put it in the root file. And put the most important instructions at the top of each skill.

If you're building your own agent rather than using Claude Code, the same three techniques from Anthropic's post apply: compaction, structured note-taking (the agent writes notes to a file outside the window and reads them back later), and subagents with clean context windows.

A 15-minute context check

1. Run /context (or your agent's equivalent) and note the three biggest categories.
2. Disable MCP servers you don't need for this project.
3. Replace an MCP server with its CLI where one exists.
4. Confirm tool search is on if your tools category looks large.
5. Get each CLAUDE.md under 200 lines; move the rest to path-scoped rules or skills.
6. Write prompts that name the file or function, not the whole codebase.
7. Filter test and log output with a hook, or send it to a subagent.
8. /clear between unrelated tasks; /compact with a focus when you need continuity.
9. Keep session-wide rules unscoped, at the top of the root instruction file.
10. Run /context again and compare.

Where to go next

These five steps are one slice of a bigger discipline. Context Engineering: The Complete Guide to the Skill That Replaced Prompt Engineering covers it in 40 pages: the anatomy of a context window, the four core strategies (Write, Select, Compress, Isolate) in depth, the four failure modes (poisoning, distraction, confusion and clash) with a diagnostic toolkit, context engineering in Claude Code and Cursor, 20 reusable patterns, 12 common pitfalls with fixes, and a 30-day plan.

This article was written with the assistance of AI and reviewed by the author.