Audit your startup context before you blame the model
One reported `/context` audit found 51,400 tokens loaded before the first prompt; disabling four third-party plugins and turning off auto memory recovered roughly 10,000 of them, while deleting an individual skill saved about 100.
The official documentation describes the mechanism this relies on. The technique itself is community practice.
What this costs you if it is wrong
The figures are one person's setup and depend entirely on which four plugins were installed — treat the shape of the result, not the numbers, as transferable. Auto memory is a real feature you are trading away: if you rely on Claude carrying your corrections across sessions, those tokens are buying something. Disabling a plugin can also remove skills, agents, or hooks that other work in your repo depends on, so disable rather than uninstall while you are measuring.
You open a fresh session, type nothing, and run /context. The window is already a third full. Nothing you did caused that — it is your configuration loading before the first token of your prompt, and most people never look at it because it arrives silently and feels like a fixed cost of using the tool.
It is not fixed. Some of it is yours to spend elsewhere.
What one audit found
A writer at XDA published a /context breakdown from a fresh session with 51,400 tokens already loaded, then took two actions and re-measured:
| Category | Before | After disabling 4 plugins | After also disabling auto memory |
|---|---|---|---|
| System tools | 28,500 | not reported | not reported |
| System prompt | 10,700 | 10,700 | 6,700 |
| Skills | ~6,300 | 3,200 | 3,200 |
| Messages | ~5,000 | ~5,000 | ~5,000 |
| Custom agents | 943 | 74 | 74 |
Net claim: about 5,800 tokens back from the plugins, about 4,100 from auto memory, roughly 10k total.
The single most useful line in that audit is the one that saved nothing. Deleting an unused personal skill recovered about 100 tokens. That is the negative result worth keeping: individual skills are noise, plugin bundles are the weight. A plugin is not one skill — it ships skills, subagents, commands, and often MCP servers together, so one install lands as a dozen skill descriptions and several agent definitions at once. That is why the Custom Agents row collapsed from 943 to 74 when four plugins went away.
What the docs do and do not back
The mechanism is documented; the numbers are not.
- context-window states what loads before you type — CLAUDE.md, auto memory, MCP tool names, skill descriptions — and tells you to run
/contextfor a live breakdown by category with optimization suggestions. - discover-plugins shows a Context cost estimate on each marketplace plugin's detail view, and flags installed plugins you have not used recently so you can find ones that "still add startup and context cost."
- memory documents turning auto memory off, via the
/memorytoggle, theautoMemoryEnabledsetting, orCLAUDE_CODE_DISABLE_AUTO_MEMORY=1. - features-overview rates skill descriptions as a low per-request cost and MCP tools as minimal until used, because tool schemas are deferred.
No page attaches a token figure to a plugin or to auto memory. So the practice is corroborated and the specific savings are one anecdote.
The tool the source missed
If you are auditing skills and plugins, /context is the wrong instrument on its own — it gives you a category total, not a culprit. Claude Code ships a purpose-built report:
/skill-doctorIt lists what each of your skills costs in context and how often it has been used, flags skills in the listing that have never been invoked, says where to turn each one off, and also lists plugins you have not used recently. In an interactive session it opens in the /plugin manager's Stats tab; with -p it prints as text. It arrived in v2.1.252, and it has two blind spots worth knowing before you lean on it: it is unavailable "in sessions that skip feature-flag fetching," and it will not run over Remote Control — run it in the terminal on the machine hosting the session.
Start with the highest-cost entries it tells you where to disable. That ordering matters more than the raw total.
What to actually cut
| Target | Typical payoff | What you give up |
|---|---|---|
| Unused third-party plugins | Largest | Every skill, agent, command and MCP server the plugin bundled |
| Auto memory | Large | Claude accumulating your corrections across sessions |
| MCP servers you never call | Modest | Nothing, if you genuinely never call them |
| An individual unused skill | Negligible | Nothing — but do not expect a win either |
| System tools | Zero | Not yours to cut; it was the biggest line in the audit |
That last row is the honest framing. The 28,500-token system tools block was more than half the startup cost and no user action in the audit touched it. You are optimizing the minority of the number.
What is unverified here
Nobody on this project has reproduced the audit. Specifically unverified: the 51,400 starting figure, the ~5,800 plugin recovery, the ~4,100 auto memory recovery, and whether the plugin savings really came partly from the unreported System tools row. Also unverified in the general case: whether auto memory always costs about 4k, which cannot be true — it is a pile of markdown notes that grows with how much Claude has learned about your projects, so a new install pays close to nothing and a heavily-used one pays more than 4k.
What would settle it for your machine, which is the only answer that matters: run /context in a fresh session, write down the numbers, change one thing, start another fresh session, and run it again. One variable at a time — the audit above changed plugins and auto memory in sequence, which is why its rows are readable at all.
Do this periodically
The habit worth stealing is not the specific cut. It is treating the startup number as a budget you own and re-checking it after you install anything. A plugin you installed for one afternoon in March is still on the bill in September, and nothing surfaces that except looking.
Checkpoint
- Which row of your own
/contextoutput is largest, and is it one you can act on?Show answerAnswer
The figure is yours to measure: open a fresh session, type nothing, run
/context, and write the rows down. Expect the largest one to be a row you cannot touch — in the published audit, System tools was 28,500 of 51,400 tokens, more than half the total, and nothing the writer did moved it. The rows that answer to you are the ones your configuration owns: Skills and Custom agents, which plugin bundles inflate, the auto-memory share of the system prompt, and MCP servers you never call. - What does
/skill-doctorsay is your most expensive never-invoked skill, and which plugin brought it in?Show answerAnswer
Only your own run knows.
/skill-doctor(v2.1.252) lists what each skill costs in context and how often it has been used, flags the ones never invoked, says where to switch each off, and names plugins you have not used recently; interactively it opens in the/pluginmanager's Stats tab, and-pprints it as text. Expect the culprit to be a bundle rather than a skill you installed by hand — in the audit, deleting an unused personal skill recovered about 100 tokens while four plugins recovered around 5,800, because one plugin arrives as skills, agents, commands and often MCP servers at once. Two blind spots before you lean on it: it is unavailable in sessions that skip feature-flag fetching, and it will not run over Remote Control. - If you turn auto memory off, what were you relying on it to remember?
Show answerAnswer
Claude accumulating your corrections across sessions — that is what those tokens buy, and only you know how much of your workflow leans on it. Turn it off with the
/memorytoggle, theautoMemoryEnabledsetting, orCLAUDE_CODE_DISABLE_AUTO_MEMORY=1. Do not plan on the audit's ~4,100-token refund: auto memory is a growing pile of markdown notes, so a fresh install pays close to nothing and a long-used one pays more than that.