I blamed the wrong thing for my slow laptop
My laptop felt slow and I was sure I knew why. I was wrong three times over: the listener I blamed used 7 MB, the MCP servers I trimmed were the small half of the bill, and the real cost, the Claude runtime itself, was hiding behind a number that lies about idle processes. The whole investigation, with the measurements.
My laptop felt slow, and I was pretty sure I knew why.
I run a lot of Claude Code. Multiple terminals, a phone in the loop, a fleet of Linux nodes, and a background listener that watches my messages. That listener runs all day. It was the obvious suspect. So I opened a process monitor to confirm it, and start killing things.
The listener was using 7 MB. Seven, not seven hundred. The thing I had been quietly blaming for months was a rounding error. That is the first lesson of this whole exercise, and I relearn it every time: the thing you assume is slow is almost never the thing that is slow. So I stopped guessing and started counting.
The crowd I found, and trimmed
What I found instead was a crowd. Forty-five separate tool-server processes, together holding well over a gigabyte. These are MCP servers, the little background programs that let the agent touch my calendar, my ad account, my design tools, my database. Each integration I had ever connected was running.
And they were running more than once. MCP servers are not shared between windows. Every Claude Code terminal I open launches its own complete copy of the fleet. Five terminals meant five copies of everything: ten facebook-ads servers, ten brokers, ten pitches, ten pinterest, five ghidra bridges. A reverse-engineering bridge for a tool I did not even have open. An ad-account controller I touch once a month. All of it warm, all of it multiplied by five.
So I did the obvious thing. I split the servers into a lean default, the two or three I actually use every session, and an opt-in list for the rest, using the allowlist and denylist in Claude Code's per-machine settings file. Nothing lost: the disabled ones still work from the command line, and turning one back on is a one-line edit. I estimated it would save around 175 MB per window. I was pleased with myself. I was also not done, because I had made a rookie mistake: I had measured the wrong number.
The number I was measuring was lying to me
I had been reading working set, the physical RAM a process is using at the instant you look. It is the number your task monitor shows you. It seems like the honest one. It is not, for idle processes. Windows reclaims physical pages from programs that sit still, so an idle MCP server reads close to zero one minute and 58 MB the next. I watched a freshly-spawned server show 58 MB and the same server, minutes later, show 3 MB. Same process, same real cost, different reading.
The number that does not lie is commit charge: the private memory a process has claimed and will not give back, whether or not it is touching it right now. It is what actually counts against your machine. So I remeasured everything in commit. That is when the real answer showed up, and it was not the MCP servers.
The thing I had ignored cost four times more
The Claude Code runtime itself, the process holding the conversation, the tools, and the V8 heap, was costing about 1,116 MB per open terminal. Roughly four times its entire fleet of tools. Five terminals is around 5.6 GB of committed runtime before a single MCP server is counted. The lever I had been pulling, trimming tools, was real. It was just the second-biggest lever in the room. The biggest one was sitting behind me the whole time: the number of terminals I leave open.
That reframes the fix completely. Closing one idle Claude Code window frees more than trimming every tool in it. My lean MCP profile still earns its place, it cuts the fleet from ~293 MB to ~117 MB per window and it speeds up startup, but it is the cleanup, not the cure.
Two bills, not one
The deeper reason I got this wrong is that I was thinking about one cost when there were two. There is the cost on your machine, the commit and the physical RAM. And there is the cost in the model's attention, the finite window it reasons inside, which a large menu of tools quietly eats before you type a word. Claude Code now defers tool definitions, loading a tool's full schema only when the agent reaches for it, which keeps that menu short. Leave that on.
But here is the trap, and it is my MCP mistake seen from the other side: deferring a tool's definition does nothing for the process behind it. A short menu and a heavy kitchen are not the same thing. I had assumed that because the agent was not carrying all those tools in its head, they were not costing me anything. They were costing me a gigabyte of commit. Context and compute are two different bills. Fix both, on purpose.
Three things, in order of what they gave back
Close idle terminals. This is the whole ballgame. Every open Claude Code window is about 1.1 GB of committed runtime and 150 to 370 MB of real, resident RAM, before tools. If it is not doing something, close it.
Run a lean MCP default. Keep the two or three servers you touch every session; make the rest opt-in. It cuts the per-window fleet by more than half and boots faster, because a server that resolves its own dependencies on every launch is slow to start even when it is cheap to keep.
Move the always-on daemons off the laptop. My message listener, the 7 MB innocent from the top of this story, runs on a Linux node now and syncs every few minutes. The laptop stays light and I can close it without killing anything.
Measure before you blame, and measure the right number
I spent an afternoon confidently trimming the second-largest cost because I never checked the largest, and because the metric I trusted was quietly lying about idle processes. None of this is really about going faster. It is about knowing, at any moment, exactly what is open, what it costs, and why. A Claude Code terminal is a powerful thing to have running. It is also about a gigabyte. Both are true, and now I can see both.