Why Claude Code Is Slow - The Short Answer
Claude Code is slow because of what you are asking it to carry, not because the product is broken. Every turn, it re-sends the conversation plus whatever files, memory, and tool definitions are loaded, and the model has to read all of that before it writes a single character. On top of that, some of the wait you feel is not the model at all - it is your test suite, your build, or a slow search running inside the loop while the agent waits like you do.
So there are exactly three meters to read. The context meter: how many tokens go up on every turn. The tool meter: how long the commands it runs actually take. The model meter: whether the model you selected is heavier than this task needs. Almost every slowness complaint resolves to one of those three, and you can find out which in about five minutes.
The Slow Loop Audit - Three Checks in Order
The Slow Loop Audit is our name for the fixed order you check these in. Order matters because context is free to fix and it compounds across every future turn, while changing model is a one-time trade you can make any time. Do them in this order and you never pay twice.
- Read the context bill. Look at what is auto-loaded before you type anything: your CLAUDE.md, any memory or rules files, connected MCP servers and their tool definitions, and any files already read into the conversation. This is the fixed tax on every single turn.
- Time one tool call. Ask Claude Code to run the thing it runs most often - your test command, your build, a search across the repo - and watch the clock yourself. If that command takes ninety seconds by hand, the agent is not slow, your command is.
- Check the model. Only after the first two are clean should you ask whether the task actually needs the heaviest model available. Routine edits, renames, and file plumbing do not.
Cause One - Your Context Is Too Big
Context is the number one cause and the easiest to fix. Everything the model has to read before responding is paid for in latency on every turn, not once. A CLAUDE.md that grew to a few thousand words, a rules directory nobody has pruned, and three files that were read in full an hour ago are all still riding along on the request you just sent.
- Trim CLAUDE.md to instructions that change behavior. If a line is describing something the agent can discover by reading the code, delete it. Project structure, file paths, and conventions belong in the code, not in a file that is re-sent every turn.
- Prefer search over reading. Grep and Glob return the matching lines, a full Read returns the whole file. On a large file that difference is the whole slowdown.
- Disconnect MCP servers you are not using today. Each connected server injects its tool definitions into the context whether you call it or not, so six idle servers are six standing taxes.
- Start a fresh session when you change task. A long conversation carries everything that came before it. If you finished the bug and are now on a feature, the bug's context is pure overhead.
- Watch for large generated files. A lockfile, a build artifact, or a giant JSON fixture read into context once will slow every turn after it.
The tell for a context problem is that the first turn of a session feels fine and the twentieth feels sluggish, on the same kind of task. Latency that grows as the conversation grows is context, every time.
Cause Two - The Tools Are the Bottleneck, Not the Model
A large share of perceived slowness is the agent sitting there waiting for your machine. When Claude Code runs your test suite, it waits for the exact same amount of time you would. If your suite takes four minutes, an agent loop that runs it three times spends twelve minutes doing nothing but waiting, and it will look for all the world like the model is thinking.
- Give it a narrow test command. Point it at the one test file relevant to the change rather than the whole suite, and only run the full suite at the end.
- Keep searches out of dependency folders. A repo-wide search that walks node_modules or a build output directory is slow for the agent for the same reason it is slow for you.
- Run long builds outside the loop. If a production build takes minutes, do not make it a step the agent waits on mid-task.
- Check hooks. A hook that fires on every tool call adds its own runtime to every tool call. A formatter that takes two seconds is fine; a full type check is not.
Cause Three - You Are Using a Heavier Model Than the Task Needs
Model choice is a real lever, but it is the third one, not the first. Heavier models reason more and therefore take longer to produce the first token and the last one. That is a fair trade on architecture decisions, tricky debugging, and anything where being wrong is expensive. It is a bad trade on renaming a variable across twelve files.
Extended thinking is the same trade in a smaller package. When you ask for more deliberation, you are explicitly buying latency with the expectation of a better answer. Turn it on for the hard step and off for the plumbing, rather than leaving it on all session and wondering where the time went.
When It Is Not You - Limits, Retries, and Network
Some slowness is genuinely outside your project. If you are near a usage limit, requests can be throttled or retried, and a retry looks exactly like a long think from where you are sitting. Heavy demand periods can add latency the same way. Neither of those is fixed by trimming CLAUDE.md, so it is worth ruling them in or out before you go rearranging your setup.
The way to tell the difference is consistency. A context or tool problem is reproducible - the same task is slow every time you run it. A limits or network problem is erratic, and the same prompt that crawled at four in the afternoon returns quickly an hour later. If your slowness moves around on its own, stop optimizing and go do something else for twenty minutes.
If you are running into usage limits regularly, that is a separate problem with its own fixes, and we walked through those in [what to do about Claude Code usage limits](/blog/claude-code-usage-limits-what-to-do).
The Setup That Stays Fast
Speed is not a one-time cleanup, it is a habit of not accumulating weight. The projects that stay fast are the ones where somebody prunes on a schedule instead of only when it gets painful.
- Cap your CLAUDE.md. Pick a length you are willing to re-read on every turn and hold it there. When you add a line, ask what comes out.
- Keep MCP servers to the ones this project actually uses, and disconnect the rest.
- Have a fast test command and a slow one, and tell the agent which is which in your project instructions.
- Start fresh sessions at task boundaries rather than running one enormous conversation all day.
- Re-run the Slow Loop Audit when a project starts to feel heavy, rather than guessing at it.
If you want the wider version of this, keeping a session lean is the same discipline as [Claude Code context management](/blog/claude-code-context-management), and the file itself is covered in [the CLAUDE.md file guide](/blog/claude-code-claude-md-file).
Short, practical drops on skills, MCP, agents, prompts, and more. No spam, unsubscribe anytime.
Frequently asked questions
Why is Claude Code slow all of a sudden?
Sudden slowness on a project that used to be quick is almost always something that got added recently: a new MCP server, a much longer CLAUDE.md, a hook that now runs on every tool call, or a test command that grew. Check what changed in your setup in the last week before you assume it is the model. If nothing in your project changed and the slowness comes and goes on its own, it is more likely limits or network conditions than anything you can fix locally.
Does a bigger CLAUDE.md really make Claude Code slower?
Yes, because it is re-sent on every turn rather than read once. A long instructions file is a fixed cost added to every request for the life of the project, so the cost is the length multiplied by the number of turns you will ever take. That is why trimming it is the highest-leverage speed fix available and why it is the first step of the Slow Loop Audit.
Will switching to a lighter model fix slowness?
It will help if the model was genuinely the bottleneck, and it will do nothing at all if your context is bloated or your test suite is the thing eating the clock. That is why model is the third check, not the first. Time one tool call by hand and look at what is auto-loaded before you type; if both are clean, then a lighter model for mechanical work is a good trade.
Do MCP servers slow Claude Code down?
Connected servers add their tool definitions to the context whether or not you call them, so a stack of servers you are not using today is a standing cost on every turn. It is not that any one server is heavy, it is that they accumulate. Keep the ones this project uses connected and disconnect the rest, and reconnect them when you actually need them.
Is extended thinking worth the extra wait?
On genuinely hard problems, yes, because the cost of a wrong answer you then have to unpick is much higher than the extra seconds. On routine edits it is pure overhead. Treat it as something you switch on for a specific step rather than a setting you leave on all session, and the wait stops feeling like a tax.
Last reviewed by David Iya on August 18, 2026
