Buildverse
← All videos

01Watch & read

Why Claude Code Is Already Full When You Type Hi

29 Oct 2026 · 8:53

Watch on YouTube ↗

A fresh Claude Code session spends about 40,000 tokens before your first message. Half of it is the system prompt and built-in tools, and the rest is skills, plugins, agents and MCP names you installed. This is the measured breakdown from a real cleanup, the five fixes, and the 10,000 tokens I got back without breaking anything.

Chapters

  1. 0:00A fresh session that is already five percent full
  2. 0:31The fixed floor: system prompt and built-in tools
  3. 1:09Skills: only names and descriptions load, until you use one
  4. 2:13Plugins: one line in settings, dozens of components
  5. 3:12MCP: tool search helps, but the names still load
  6. 4:09Agents and memory, plus one silently broken agent
  7. 4:54Measure it: slash context, then archive skills
  8. 6:06Plugins and MCP: global off, project and local scope on
  9. 7:26Trim descriptions, and the before/after numbers
  10. 8:03Make it stick: one line in CLAUDE.md

Commands & links

Article

A fresh session that is already five percent full

Fresh session. Nothing open. I type two letters: hi. And the context meter is already at five percent.

About forty thousand tokens, on a million token window. I have not asked a question. Nothing has been read. No file has been opened.

So what is in there? This is the story of that number. What fills a Claude Code session before your first message, which parts you can cut, and which parts are the price of admission. I did this on my own setup, measured it, and got about ten thousand tokens back.

Nothing broke.

The fixed floor: system prompt and built-in tools

Start with the half you cannot touch. Every session carries Claude Code's own system prompt and the definitions of its built-in tools. Read a file. Write a file.

Edit a file. Run a command. Search the codebase. Fetch a web page.

Each tool is a name, a description, and a schema for its arguments. In my session that fixed floor was about twenty thousand tokens. Half of the forty. It is not waste.

It is the agent's body. A model with no tools can only talk. But it means a fresh session is never empty. The only question is what you stack on top.

Skills: only names and descriptions load, until you use one

On top of that sat my skills. About a hundred and fifty of them, counted together: ones I wrote, ones that came with plugins, ones synced from my account, and the built-in ones. Nine thousand tokens. Here is the part people get wrong.

Only the name and the description load at startup. The body, the actual instructions, loads when the skill is used. That is the whole design, and it is a good one. But the descriptions are not free.

One video-editing skill pack had eleven skills with very long descriptions. About three thousand tokens. And my own video pipelines never called those skills. They called the command line tool the pack wrapped.

So I paid three thousand tokens, in every session, for eleven descriptions I never used. The docs even point this out. The skill listing has a character budget, about one percent of the model's context window, and when you go over it, Claude Code drops descriptions starting with the skills you use least. Which is a polite way of saying: the list has a ceiling, and you are paying for the climb.

Plugins: one line in settings, dozens of components

Then plugins. Plugins are worse, because one install is a whole box. The deploy platform plugin, Vercel, brought thirty-seven skills, four commands, three subagents, an MCP server, and three hooks that fire at the start of every session. That is one line in a settings file.

It also had a stale second copy of itself installed, so part of that was counted twice. The API plugin, Postman, brought seventeen skills, plus a startup hook that injects a block of instructions into every session before I type anything. And a plugin I wrote myself pointed at a folder that no longer existed. Its source was gone, so it could never update, and nothing told me.

None of these are bad tools. That is the point. Nothing here is broken. It is just all switched on, everywhere, by default.

MCP servers are the next layer, and they are the one that surprises people.

MCP: tool search helps, but the names still load

Tool search is on by default now. So the full schema of every MCP tool stays out of context until Claude actually needs it. Only the tool names and each server's instructions load at startup. That is official, and it is a real improvement.

The names are still a list. My database server, Neon, exposed about a hundred and fifteen tools. A hundred and fifteen names, every session, roughly two thousand tokens. Plus that server's instructions.

Then the failures. One server failed to connect at every single startup, and I never noticed, because a failed server does not stop anything. It just costs you a second and a log line you scroll past. And one service was connected three times: a local server, and two account level connectors.

None of them signed in. Three dead entries, carried on every launch.

Agents and memory, plus one silently broken agent

Two smaller lines on the bill. Subagent descriptions load the same way skill descriptions do. Mine were small, about a hundred and fifty tokens after I trimmed them. The built-in agents, the explorer, the planner, the general purpose one, are about eight hundred tokens, and they are fixed.

The CLAUDE dot md file and the memory index came to about thirteen hundred tokens. That one is worth it. That is where I keep the rules that should apply everywhere. But there was a bug hiding in that stack.

One agent preloaded a skill I had archived. The skill was gone, so the agent started without it, silently. Nothing failed. It just quietly did less than I thought it did.

Measure it: slash context, then archive skills

Now the fix. Step one is always the same. Open a fresh session, type slash context, and look. It shows a colored grid of where the window went, by category: system prompt, tools, skills, agents, memory, MCP.

Not estimates from a blog post. Your own session. That is the only number that matters. Step two, skills.

I moved the ones I rarely use out of the skills folder and into a backup folder, skill bak. Then I wrote a tiny skill called skill loader. It does one thing: when I ask for an archived skill by name, it moves that folder back. Nothing is deleted.

Everything is one request away. Two rules before you move anything. First, search the other skills for real dependencies. A skill that calls another skill needs it.

A skill that calls a command line tool with the same name does not. That distinction is the whole ballgame, and it saved my video pipeline. Second, move bundles together. Skills that call each other move together.

And the skills I only use in another coding agent went too. That agent has its own copies. Step three, plugins.

Plugins and MCP: global off, project and local scope on

My mistake was enabling them globally. Global means every project pays. So in my global settings dot json, the deploy plugin went to false. If a project needs it, I turn it back on in that project's own settings file.

Project settings override global. Same plugin. Only where it is used, instead of every session. The stale duplicate is off too, and the plugin pointing at a deleted folder is uninstalled.

The API plugin stayed on. I chose to keep it, so now it is a decision instead of an accident. Step four, MCP. The database server moved from user scope, which means every project, to local scope, which means one project.

I ran the add command in each project that needed it, with local scope, then removed the server from user scope. Local scope matters for a second reason. The connection details live in your own config, not in a file you commit. Never put a key in a project level MCP file that goes into git.

Then I removed the server that failed every time, and the entries pointing at folders I deleted. And the account connectors I am not using get disconnected on the website, because those live in your account, not on your machine. Step five, the cheap one.

Trim descriptions, and the before/after numbers

Shorten descriptions. My agent descriptions went from about four hundred and thirty characters to about two hundred and ten. Same behaviour, half the rent. The same trick works on skills: put the words you would actually search for first, because the listing reads from the top.

The outcome. My own skills went from thirty-nine to sixteen. Their startup descriptions went from twenty-one kilobytes to eight. Across the whole setup, about ten thousand tokens saved, in every new session.

And nothing broke. That is the part I checked hardest.

Make it stick: one line in CLAUDE.md

Two things keep it from creeping back. One line in the global CLAUDE dot md file: before adding a skill, an MCP server, a plugin or a hook, check what it costs at startup, and prefer project scope. And one skill, kept archived, called context audit. It measures the startup budget, walks the same five steps, and asks before it changes anything that depends on how I work.

Archived means it costs nothing until I call it. The takeaway is not that Claude Code is bloated. It is that context is a budget, and global is the expensive default. Every tool you install everywhere is a subscription you pay on every message.

Scope things to where you use them. If this helped, subscribe. Build with AI. For real.