Your context is not mostly full before you type

Idle MCP servers and an inherited CLAUDE.md do not fill your context before you type: the docs' startup itemization totals about 7,850 tokens, MCP tool names just 120, because tool definitions are deferred by default. Keep running /context; the 33k figure is not yours.

You ran out of window sooner than you expected, went looking for why, and found a thread saying the real culprit is startup: idle MCP servers plus an inherited CLAUDE.md eat a large slice before you type a word, with a measured 33k of pre-prompt overhead quoted as proof. It is a satisfying explanation because it blames configuration rather than your own file reads.

On a current default setup it is mostly wrong, and the docs contain the arithmetic that says so.

What startup actually costs

The official context-window walkthrough itemizes what loads before your first message. Its illustrative numbers:

Startup item	Tokens (docs illustration)
System prompt	4,200
Auto memory (`MEMORY.md`)	680
Environment info	280
MCP tools, deferred	120
Skill descriptions	450
`~/.claude/CLAUDE.md`	320
Project `CLAUDE.md`	1,800
Total	~7,850

That is under 4% of a 200k window, and the MCP row is 120 tokens — not a large fraction, a rounding error. Note the coincidence: the "lean harness sends 7k" half of the comparison is roughly what Claude Code's own documented startup adds up to.

Why the 33k number does not describe your session

MCP tool definitions are deferred by default. Only tool names and server instructions enter context at startup; full schemas load on demand when Claude searches for a tool. That is why adding servers has, in the docs' words, minimal impact on the window.

Deferral is not universal. Tools load upfront — and the old cost returns — when:

ANTHROPIC_BASE_URL points at a non-first-party host, since most proxies do not forward tool_reference blocks
you are on a Microsoft Foundry deployment hosted on Azure, which rejects tool search server-side
you are on an older Google Cloud Agent Platform model, pre-4.5 generation
CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS is set, or ENABLE_TOOL_SEARCH=false
a server or tool is marked alwaysLoad, exempting it from deferral

If you are behind a corporate gateway, you may genuinely be paying the old price. Check which case you are in before you accept or dismiss the number.

The cache claim is half true

The companion claim — that every registered server adds a cache-invalidation surface, because a stdio process exiting or an HTTP session expiring reshapes the tool set on its own — is stated too broadly. The prompt-caching page splits it:

Deferred tools, the default: a server connecting, disconnecting, or changing its tool list only appends content and leaves the cached prefix intact.
Tools loaded into the prefix: any change invalidates the cache, and a server dropping mid-session is the most common cause.

So the risk is real precisely in the gateway and older-model cases above, and absent in the default one. Same fork in the road as the token cost.

What is actually filling your window

The docs attribute unexpectedly high spend to long sessions that were never cleared and to Opus left as the default model — not to startup. The walkthrough backs that up: a single source file read costs more than your entire MCP row, and a test run costs more than your global CLAUDE.md.

The part worth keeping

The habit survives even though the diagnosis does not, and the docs say it plainly:

/context shows what is consuming the window, broken out by system prompt, tools, memory files, and messages. /context all expands the per-item breakdown, including per-tool MCP usage.
Check the Memory files row to confirm the CLAUDE.md you think is loaded actually is — and to see what an inherited one costs you.
/mcp lists configured servers and lets you disable ones you are not using.
/doctor flags oversized memory files and unused extensions.

Run these early because they are cheap and they replace a guess with a number, not because you expect the number to be alarming.

What is unverified here

Nobody has run a measurement for this entry. The 7,850 figure is copied from a docs illustration; the 33k figure is one person's claim in a forum thread, disputed in its own replies on caching grounds, and its own submitter concedes deferral makes it overstate a current setup. Neither is your machine.

What would settle it, on your machine, in one command — compare a bare directory against your project:

bash

cd "$(mktemp -d)" && claude -p "hi" --output-format json | jq '.usage'

Then run the same line from your project root and diff the input-token counts. The gap is what your project CLAUDE.md, rules, and skills cost; the baseline is your harness plus global config plus whatever your servers contribute. If the baseline lands near 8k, the thread does not describe you. If it lands near 33k, check the deferral list above — you are probably behind a gateway.

Checkpoint

Is your setup one where MCP tool definitions are deferred, or one of the exceptions?

Show answerAnswer
On a current default setup, deferred: only tool names and server instructions enter context at startup, which is why the docs' itemization prices the MCP row at 120 tokens instead of a large slice. You are an exception if ANTHROPIC_BASE_URL points at a non-first-party host, you are on a Microsoft Foundry deployment hosted on Azure, you are on a Google Cloud Agent Platform model earlier than the 4.5 generation, CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS is set or ENABLE_TOOL_SEARCH=false, or a server or tool is marked alwaysLoad.
Which case is yours is yours to measure, not to assume. Run claude -p "hi" --output-format json | jq '.usage' from a scratch directory and read the input tokens: a baseline near 8k says the 33k thread does not describe you, one near 33k sends you down that exception list — you are probably behind a gateway.
Which single line in your last /context output was the largest, and was it startup or conversation?

Show answerAnswer
No one can answer that for your machine, so run /context — it breaks the window out by system prompt, tools, memory files and messages, and /context all expands the per-item breakdown including per-tool MCP usage. Expect a conversation line on top: the docs' startup illustration totals about 7,850 tokens, under 4% of a 200k window, and a single source file read costs more than the entire MCP row. That matches the docs attributing unexpectedly high spend to long uncleared sessions and to Opus left as the default, not to startup.
If a startup row does win, the likely culprit is Memory files — confirm the CLAUDE.md you think is loaded is the one that is, and let /doctor flag oversized memory files.
Before removing an MCP server, what is your reason — token cost, or something else?

Show answerAnswer
Token cost is not a good enough reason on a default setup. You reclaim a few hundred tokens, lose tools you may want mid-task, have to re-add and in some cases re-authorize the server later, and hit the same limit thirty file reads on anyway. Remove a server because it adds noise and failure modes you do not need.
The exception is the same fork as the first question. Where tools load into the prefix rather than deferring, the old cost is real — and so is the cache risk, since a server dropping mid-session invalidates the cached prefix, where under deferral a connect, disconnect or tool-list change only appends and leaves the prefix intact.