What loads into the Claude Code context window before you type?
Four things load before you type: 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, and the whole 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 |
Memory files in the directory hierarchy above your working directory load in full at launch, while files in subdirectories below it load on demand, when Claude reads something in that subdirectory. So the directory you launch from decides how much of that loads up front.
How much startup overhead is normal?
On a 200,000 token window, under 15,000 tokens at startup is lean, 15,000 to 30,000 is normal, and past 50,000 something is loading that you do not use. As a share of the window, keep the startup block under about 15 percent so that most of the window is left for the task itself.
| 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. |
We built those bands from three sources. The first is our own 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.
Both 29,000 and 65,538 are real measurements of a default install plus whatever the owner added. The gap between them is large enough that you cannot know where your own setup falls until you measure it.
Do MCP servers really eat your context window?
They use 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 and only tool names and server instructions load at startup. Adding another server now has minimal effect.
Of the usual advice about startup overhead, the MCP numbers are the most out of date. 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, and on current models that no longer happens. 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 the reported number can be double counting. The cuts are still worth making, but most of the alarm about MCP overhead describes 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?
You can measure it three ways, in ascending order of trust. The context command gives a category breakdown in one second but over-reports tools, a logging proxy shows the request exactly as the model receives it, and 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. It is fast and accurate on memory files but inflates the tool count. 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, which logs exactly which instruction files loaded, when and why. This is the one people tend to skip, 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?
Switch off whole features before individual tools, because each feature brings a cluster of tools and instructions with it. Then trim the memory files, which are the largest thing you wrote yourself. Leave MCP servers for last, after you have confirmed at the wire that they actually cost what the report says.
- Record the baseline before you change anything, or you will have no way to tell whether a change helped.
- Switch off features you do not use, since one flag removes a whole cluster. disableBundledSkills drops Anthropic's bundled skill catalog while leaving the slash commands typable, and 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, such as the plan mode tools, notebook editing, remote control or scheduling. Keep anything your background jobs depend on.
- Trim CLAUDE.md. If a competent engineer could work something out in twenty minutes of reading the repo, cut it. Keep things like a non-obvious build command, a decision that goes against the framework default, or a 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.
- Only then 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"]
}
}Pick from that config rather than copying it whole. The reason to look at your own payload first is so that you cut what you personally do not use, and if you work in plan mode, keep plan mode.
What are the less obvious ways to lower the baseline?
The less obvious ways are structural: replacing servers with command line tools, launching sessions in the right directory, auditing the context you inject into yourself, and turning standing prose rules into gates that cost nothing until they fire. These save more than the standard advice of trimming files and disconnecting servers.
- Replace MCP servers with CLIs. A GitHub MCP server ships tool schemas, while 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, and 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 for in every message of every session 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.
- 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, and very few servers justify their cost once you do that arithmetic.
- 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. To shrink an instruction file, delete a rule, run the same task, and see whether behavior changes. Rewording a rule only tests the prose, while deleting it tells you whether the rule was doing anything.
When is a lean baseline not worth chasing?
It is not worth chasing when you are optimizing for 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 less accurate. What it costs is money, prompt cache stability and the room you have left for the real work.
Taken too far, this exercise makes your setup worse. If you strip tools you actually use, you spend the first ten minutes of every session working around their absence. What degrades in long sessions is composition rather than recall, and having fewer tools does not help composition.
If you are billed through the API, note that connecting or disconnecting an MCP server mid-session invalidates the prompt cache for the whole session, so make those changes when the session starts.
