What loads into the Claude Code context window before you type?
Four things. The system prompt Anthropic ships with the CLI, the full schema of every built-in tool, your memory files, and a name plus one line description for each installed skill. Memory files arrive as a user message after the system prompt. Every part of that block is resent with each message in the session.
Only some of it is under your control, and the parts you control are not the parts people usually attack first.
| Component | What it is | What controls its size |
|---|---|---|
| System prompt | The instructions the CLI ships to the model on every request | Feature flags such as disableWorkflows and disableBundledSkills |
| Built-in tools | Read, Edit, Bash, Task, Workflow and the rest, as full JSON schemas | permissions.deny rules and the disable flags |
| Memory files | CLAUDE.md at or above your working directory, loaded in full at launch | What you write, and which directory you launch from |
| Skills | Name and description only, roughly 30 to 100 tokens each | How many are installed and in scope for that directory |
| MCP tools | Deferred by default on 4.5 generation models and later | The ENABLE_TOOL_SEARCH variable, and permissions.deny |
The load order matters for one reason. Files in the directory hierarchy above your working directory load in full at launch. Files in subdirectories below it load on demand, when Claude reads something in that subdirectory. Where you start the session sets the bill.
How much startup overhead is normal?
On a 200,000 token window, under 15,000 at startup is lean, 15,000 to 30,000 is normal, and past 50,000 something is loading that you do not use. Expressed as a share of the window rather than an absolute, keep the block under about 15 percent. That leaves the rest for the actual job.
| Baseline at startup | Share of a 200k window | Reading |
|---|---|---|
| Under 15,000 | Under 8 percent | Lean. Instruction files trimmed, unused features switched off, nothing loaded upfront. |
| 15,000 to 30,000 | 8 to 15 percent | Normal, and fine. Our own eval harness sat at about 29,000. |
| 30,000 to 50,000 | 15 to 25 percent | Worth an audit. Something loads every session that you use once a month. |
| Over 50,000 | Over 25 percent | Check the measurement before you cut. Then cut. |
Those bands are assembled from three sources rather than invented. Ours is the 29,000 token floor measured across 128 CLI runs in the context rot study, on a fairly standard setup. Firecrawl's survey of token consumption puts the hidden baseline at 20,000 to 30,000 tokens before you type. Matt Pocock, measuring his own machine at the wire before trimming, logged 69 tools, 154,946 bytes of tool schema, and 65,538 real input tokens on a single request.
The spread between 29,000 and 65,538 is the whole point. Both are real measurements of a default install plus whatever the owner added. Nobody tells you which one you are running until you look.
Do MCP servers really eat your context window?
Less than they used to, and less than the built-in report claims. Tool search is on by default for Opus, Sonnet and Haiku 4.5 and later, so MCP tool definitions are deferred until Claude actually needs one. Only tool names and server instructions load at startup. Adding another server now has minimal effect.
This is the advice most in need of updating. The widely quoted figures of 10,000 to 20,000 tokens per server, or 50,000 to 70,000 for a full setup, describe a version of the product where every schema loaded upfront. On current models it does not. The docs are explicit that tool search defers definitions and that the practical limit is your context budget rather than a per server cap.
The second correction is a measurement artifact. When you run the built-in context report, the CLI prices each tool with its own call to the token counting endpoint. Each of those calls wraps a single schema in a dummy conversation and pays Anthropic's tool use preamble again, roughly 460 tokens of wrapper on a tool whose real schema might be 130 tokens. Iterate that over 60 tools and you pay the preamble 60 times. Async Let measured the difference: about 45,000 tokens summed one at a time, against about 15,000 for the same 60 tools in one real request.
So roughly 30,000 tokens of that scary number can be double counting. The cuts are still worth making. The panic is mostly measuring a problem that has already been fixed.
If you do want them gone, there are two levers. ENABLE_TOOL_SEARCH takes true to always defer, false to always load upfront, and auto:N to load upfront only when the tools fit inside N percent of the window. A deny rule of mcp__* removes every MCP tool without unconfiguring the servers themselves.
How do you measure your own baseline?
Three ways, in ascending order of trust. The context command gives you a category breakdown in one second and over-reports tools. A logging proxy shows the request exactly as the model receives it. An instructions hook tells you which memory files loaded and why. Use the first to triage and the second to decide.
- Run /context. It breaks the window into system prompt, tools, memory files and messages, with a token count for each. Fast, honest about memory files, inflated on tools. Write the numbers down before you change anything.
- Run a logging proxy. Claude Code talks to the API over HTTP, so a proxy between the two can record every request untouched. Pocock's proxy.mjs is one file with no dependencies, and it prints a ranked per-tool table so you cut the specific things you do not use instead of guessing.
- Add the InstructionsLoaded hook. It logs exactly which instruction files loaded, when, and why. This is the one nobody uses, and it is the only way to catch a CLAUDE.md three directories up that you forgot you wrote.
# point the CLI at a local proxy for one session
node proxy.mjs
ANTHROPIC_BASE_URL=http://localhost:8787 claude
# the proxy prints the real payload, tool by tool
[agent-proxy] 69 tools · 154,946 tool bytes · 65,538 real input tokens
Workflow 21229 B ~5307 tok
DesignSync 8978 B ~2245 tok
Monitor 7767 B ~1942 tokWhat should you cut first?
Kill whole features before you kill individual tools, because a feature drags a cluster of tools and instructions with it. Then trim the memory files, which are the largest thing you personally wrote. Touch MCP servers last, after you have confirmed at the wire that they are actually costing what the report says.
- Measure. Record the baseline before any change, or you will have no idea whether the change helped.
- Switch off features you do not use. One flag removes a whole cluster. disableBundledSkills drops Anthropic's bundled skill catalogue while leaving the slash commands typable. disableWorkflows drops the multi-agent tool, which is usually the single largest schema in the payload.
- Deny the individual tools your ranked table says are large and unused. Plan mode tools, notebook editing, remote control, scheduling. Keep anything your background jobs depend on.
- Trim CLAUDE.md. If a competent engineer could work it out in twenty minutes of reading the repo, cut it. What stays is the non-obvious build command, the decision that goes against the framework default, the constraint nobody would guess.
- Move what is left out of the always-loaded path. Path-scoped rules under .claude/rules/ and skills both load on demand. A skill costs 30 to 100 tokens at startup and its body loads only when it is relevant.
- Now look at MCP. Confirm the real cost at the wire, then disconnect the servers you are not using this session.
{
"disableBundledSkills": true,
"disableWorkflows": true,
"disableRemoteControl": true,
"permissions": {
"deny": ["NotebookEdit", "CronCreate", "CronList", "CronDelete"]
}
}Treat that as a menu and not a prescription. The reason to look at your own payload first is so you cut what you personally do not use. If you live in plan mode, keep plan mode.
What are the less obvious ways to lower the baseline?
The standard advice stops at trimming files and disconnecting servers. Bigger wins come from structural moves: replacing servers with command line tools, launching sessions in the right directory, auditing the context you inject into yourself, and converting standing prose rules into gates that cost nothing until they fire.
- Replace MCP servers with CLIs. A GitHub MCP server ships tool schemas. The gh command ships none, because the model already knows it and reads its help text only when it needs to. Any service with a good CLI is a server you can delete outright rather than defer.
- Launch the session in the right directory. Every CLAUDE.md at or above your working directory loads in full at launch. Start in the package you are working on rather than the monorepo root, and the parent instructions you do not need never arrive.
- Audit the context you inject into yourself. Session start hooks and plugins can push their own text into every session. It is easy to install a helper that spends a thousand tokens telling you how to save tokens. Read your own hook output as if a stranger wrote it.
- Turn standing rules into gates. A line in CLAUDE.md that says always run the tests is paid in every message forever and is still only advisory. The same rule as a pre-commit hook or a CI check costs zero tokens until it fires, and it is deterministic. Prose persuades, gates enforce.
- Price each tool per month rather than per session. A server that costs 5,000 tokens at startup, across 40 sessions a month, for 3 actual uses, is 200,000 tokens for 3 calls. Almost nothing survives that arithmetic honestly applied.
- Send exploration to a subagent. A subagent gets its own window, and only its conclusion comes back. Reading nine files to answer one question should not happen in the context you need for the next hour of work.
- Ablate rather than rewrite. The way to shrink an instruction file is not to reword it. Delete a rule, run the same task, and see whether behaviour changes. Rewriting measures your prose. Deleting measures the rule.
When is a lean baseline not worth chasing?
When you are optimising accuracy rather than cost. Our own recall testing found retention holding out to 730,000 tokens, so a large startup block does not by itself make the model dumber. What it costs is money, prompt cache stability, and the room you have left for the real work.
There is a version of this exercise that makes your setup worse. You strip the tools you actually use, spend the first ten minutes of every session working around their absence, and call it efficiency. The thing degrading in long sessions is composition rather than recall, and composition is not helped by owning fewer tools.
One practical warning for anyone billing through the API. Connecting or disconnecting an MCP server mid-session invalidates the prompt cache for the whole session. Make those changes at the start, not in the middle.
