If startup overhead is fixed and nearly impossible to cut, what real benefit does Prompt Caching actually provide?
The benefit is concentrated in billing, not context space. Prompt caching targets the content that gets resent unchanged on every turn (System Prompt, CLAUDE.md, tool definitions), marking it as cacheable so subsequent requests hitting the cache get roughly a 90% billing discount on that portion. For a long conversation with many turns, each resending the same fixed content, that discount compounds to something substantial.
But the distinction here matters: caching lowers how much these tokens cost you, not how much context-window space they occupy. The 200K window ceiling is measured by actual Token count occupied, not the discounted billing price — so even with a cache hit and a smaller bill, the space these tokens take up in the window stays exactly the same, and a long conversation still moves toward Compaction or summarization regardless.
Does an MCP Server that's connected but never actually used in this conversation still drag down startup overhead?
Yes. Both official documentation and community breakdowns point out that every connected MCP server has its tool schema loaded into the System Prompt regardless of whether you actually call it in a given session — this lets Claude know "this tool exists, and can be used when needed," so Claude can correctly judge when to reach for it, but the cost is that every connected server contributes a small but genuinely real fixed overhead to every single message.
The practical recommendation is periodically reviewing your mounted MCP list: if a server hasn't actually been called in over a week, disconnect it and reconnect when you actually need it — a ten-second action that keeps compounding savings over time. There's no need to let it permanently carry overhead just because "you might need it eventually."
Beyond /context, /memory, and /usage, is there any way to catch unusual usage earlier, instead of only finding out once the bill arrives?
Yes, and you don't need to wait until the session ends. Beyond these three built-in commands for live inspection, the community has also built standalone measurement tools — a CLI tool like context-budget, for instance, can scan your workspace before you actually load a file into the conversation and list each file's individual Token cost, letting you see the price tag before you actually execute the "load this document" action, rather than discovering afterward that it ate a large chunk of the window.
Another practical habit is checking in stages: run /context right at the start of a session to note the startup baseline, then run it again after a step that clearly pulls in a lot of files or runs a lot of commands, and compare the difference — this shows you concretely how much that specific step actually cost, rather than only noticing the total is high at the end of the session, by which point it's genuinely hard to trace back which step caused it.
I'm not a heavy user, just occasionally using Claude Code for small tasks — is this content still relevant to me?
It's relevant, but the relevance shifts. If your usage pattern is "occasionally open a session, ask a few questions, done," the fixed startup overhead makes up a proportionally larger share of your total usage — because you don't have enough subsequent turns to dilute that upfront cost. In this case, what's actually worth paying attention to is whether you need to open this many separate short sessions in the first place — combining a few small tasks into a single session lets that fixed cost get amortized more favorably.
If your tasks themselves are simple and don't involve reading a lot of files or running commands repeatedly, the compounding portion (unfiltered output, accumulated file reads) has naturally limited impact on you. The most relevant part of this piece for you is actually just the awareness of what the startup overhead itself is — knowing what that 20,000-to-30,000 tokens represents means that when you see a usage number, you don't mistake it for something being wrong with the system, and instead first confirm whether it's just the normal fixed cost.
A specific bug report on GitHub (issue #52979) documents this: opening a fresh session in a completely empty folder — no files, no tools, no CLAUDE.md — and typing just "hi" produced a reported Token usage of roughly 30,000. This isn't an isolated fluke either; a token-optimization guide from firecrawl.dev directly labels the "20,000 to 30,000 tokens gone before you type a single character" pattern as "not a bug, it's the fixed overhead of how Claude Code initializes." This piece breaks down exactly where that money goes, and which parts you can actually trim versus which parts you're stuck with.
Before you type your first word, Claude Code has already loaded several things into context: the system prompt itself, built-in tool definitions (official documentation notes these get folded into the system prompt for accounting purposes rather than counted separately), project- and global-level CLAUDE.md, memory files, connected MCP servers' tool schemas, and the names and descriptions of installed Skills. All of this gets re-sent with every single message — because the API is fundamentally stateless, with no such thing as "remembering," every turn re-lays out the entire stack from scratch.
This is also why an intuitive optimization like "delete a paragraph from CLAUDE.md and assume it saved something" often produces a murky result: what you can actually see is only the part you added yourself. Fixed costs like the system prompt and tool schemas don't disappear just because you trimmed content you wrote.
Both the official documentation and several technical breakdowns point to the same key distinction: prompt caching lets these fixed, repeatedly-sent contents get cached, with an actual billing discount of roughly 90%, but caching saves money, not context space. These tokens still fully occupy the 200K Context Window and still count against rate limits — and once content piles up, output quality still starts degrading once the window fills to 50-70%, which is exactly what context rot addresses. Cheap isn't free, and it definitely isn't weightless.
Treating the 20,000-to-30,000-token startup floor as a fixed cost to accept is generally the pragmatic move — nearly everyone pays it. What's actually worth spending time diagnosing is what keeps stacking up and compounding as a session runs longer. A concrete case from community-collected measurements: a test command with no output filtering produced roughly 2,131 tokens per run, and running it three or four times an hour compounds to far more than the CLAUDE.md you spent an evening carefully trimming; the same command changed to output only failures dropped cost per run to roughly 363 tokens — marked in that write-up as "the highest-Leverage single change on the list, and almost nobody makes it."
Another commonly underestimated source of compounding is files already read: every file Claude Code reads stays permanently in the conversation history, reprocessed on every subsequent message. A PR review that pulls 20 files into context means those 20 files' contents get resent for the rest of that session's turns — not a one-time cost, but one that accumulates with session length.
Rather than guessing intuitively at "this change should have saved something," Claude Code itself offers a few tools that show you actual numbers: /context gives a live breakdown of exactly how many tokens each element in the current context window occupies, with total usage laid out clearly; /memory shows exactly which CLAUDE.md and memory files loaded at this session's startup; /usage (available from Opus 4.8 onward) points specifically to which component your current usage is concentrated in. Rather than deleting something first and going by a vague sense that "it feels faster," running /context first shows you clearly where the money is actually going before you decide whether to act.
Next time a session's usage climbs faster than expected, first sort out which category the problem falls into: is it the fixed startup overhead every session pays once (system prompt, CLAUDE.md, connected MCP servers and Skills), or the variable cost that compounds with turn count (unfiltered command output, files accumulated from repeated reads)? Accept the former as an inherent cost worth only minor trimming; the latter is where diagnosis is genuinely worth your time — and where a single fix keeps paying off for the rest of the session.