Claude Code Slow? Context Bloat Is the Usual Culprit

Claude Code slow usually comes down to context bloat, not a bad connection. Every turn re-sends the whole conversation, so a session stuffed with file reads gets slower and pricier with each message. Run /context, /clear between unrelated tasks, and cut unused MCP servers before you blame anything else.

Effort levels and model defaults verified 31 July 2026 against Anthropic's effort documentation.

That's the short version. The long version matters, because "Claude Code slow" describes at least three different problems with three different fixes, and people usually chase the wrong one. This guide walks the causes in the order they actually pay off — biggest lever first. We have walked this exact path in our own terminal, so the guidance here is grounded in doing rather than describing.

First, decide what "slow" actually means

Three different problems hide under one word: a long pause before any text appears, text that crawls once it starts, and a task that takes twenty minutes because it did twenty minutes of real work. Watch one message to tell them apart.

Before you change a setting, separate these three things. A ten-minute agentic run is not slowness; that's work.

• Time to first token — you hit enter and stare at a blinking cursor for ages before any text appears. This is usually reasoning effort, a bloated prompt, or network latency.
• Tokens per second — text appears but crawls out. This is model choice or genuine upstream load. Almost nothing local fixes it.
• Total task time — the first token arrives fast and streaming is fine, but the task takes twenty minutes because Claude read 40 files and ran the test suite three times. That's throughput, not latency, and the fix is scoping your prompt better.

If you can't tell which one you have, watch one message closely. Does the pause happen before text starts, or during? That single observation cuts the search space in half. People who report sluggishness usually mean the first or third — rarely the second.

Why context bloat makes Claude Code slow

Every turn re-sends the whole conversation. Message forty carries every file read, diff, and test output since message one, so the processing cost — and your bill — grows on exactly the same curve as the session.

This is the big one, and it's worth understanding properly. Claude Code is stateless underneath: every single turn re-sends the entire conversation to the model. Your first message might be a 45-token question against a small system prompt. Message forty is that question plus every file read, every tool result, every diff, every test output since.

So the cost of each turn grows as the session grows. More input tokens means more to process before the first output token appears, which is exactly the "why is it taking so long to start" feeling. It also means your bill grows on the same curve — context bloat makes Claude Code slow and expensive at the same time, which is why this is the first thing to fix.

The startup content alone isn't trivial: the system prompt runs to a few thousand tokens, plus your CLAUDE.md, auto memory, skill descriptions, and MCP tool names — all before you type a word. Then a single meaty source file can add 2,400 tokens, and a test run adds another 1,200. It compounds fast, even against the million-token windows the current models carry.

Here's what to do about it, in order:

1. Run /context. It visualizes current usage as a colored grid and shows optimization suggestions for context-heavy tools, memory bloat, and capacity warnings. Pass all to expand the per-item breakdown. This tells you what's actually eating your window instead of making you guess. If you want the money angle too, see how to check token usage in Claude Code.
2. /clear between unrelated tasks. Finished the auth bug and moving to CSS? Clear. Old conversation crowds out the files you need next and costs tokens on every message. The docs are blunt about this. /clear starts a fresh conversation with empty context, and you can still /resume the old one.
3. /compact with focus instructions. Staying on the same task but running long? /compact focus on the auth bug fix summarizes the conversation and keeps what you chose, rather than what the automatic pass guesses matters. Claude Code compacts automatically as you approach the limit anyway, but a focused manual compact is better than a guessed one.
4. Keep sessions task-scoped. One session, one job. This is the habit that makes the other three unnecessary most of the time.
5. Delegate big reads to subagents. A subagent researches in its own context window and returns only a summary — for example, 6,100 tokens of file reads can come back as a 420-token answer. Your window stays clean.

The Claude context window explainer covers the mechanics in more depth, and if the same sluggishness follows you into the web app, Claude getting slower is the companion piece. Anthropic's own context window walkthrough is an interactive simulation worth ten minutes of your time.

MCP servers and skills add a standing tax

Tool schemas stay deferred by default and load on demand, so the resting cost is only tool names. Override that and a dozen servers become a permanent per-turn tax. /doctor names unused servers against their context cost.

Every connected MCP server contributes tool schemas and startup cost. By default Claude Code is smart about this — full MCP schemas stay deferred, and Claude loads specific ones on demand via tool search when a task needs them, so only the tool names sit in context. But that default can be overridden: setting ENABLE_TOOL_SEARCH=false loads every schema upfront, and auto loads them when they fit within 10% of the context window. If someone turned that off in your config, a dozen servers become a permanent tax on every turn — and that alone can make Claude Code slow from the very first message of a brand-new session.

The tool that settles this argument is /doctor. It runs a setup checkup and explicitly finds unused skills, MCP servers, and plugins versus their context cost, flags slow hooks, checks installation health, and can fix what it finds. If you've collected servers over months and never audited them, this is a five-minute win. Our guide to Claude Code MCP covers how to disconnect the ones you don't use.

Skills behave similarly: one-line descriptions load at startup, full bodies only when invoked. That's cheap. The expensive pattern is a huge always-loaded CLAUDE.md — which /doctor also trims by cutting content Claude could derive from the codebase.

Model and effort level: the real dial

Effort decides how much the model reasons before its first visible word, which reads as latency. low suits scoped mechanical work, high is the sensible middle, and max invites overthinking for diminishing returns.

Effort level controls adaptive reasoning — how much the model thinks before answering. Higher effort means more reasoning tokens generated before your first visible word, which reads as latency even though the model is working. That's the trade, made on purpose.

/effort accepts low, medium, high, xhigh, and max (availability depends on the model; max is session-only). /effort auto resets to the model default. Claude Opus 5 is currently the default model on Max and API accounts, and it ships at high effort — a sensible middle. Drop to low for short, scoped, latency-sensitive work that isn't intelligence-sensitive. Avoid max as a habit: the docs warn it shows diminishing returns and is prone to overthinking.

Model choice matters too. Aliases opus, sonnet, and haiku resolve to the newest version in each family. A smaller, faster model is genuinely the right call for mechanical tasks — see best Claude model for coding for the trade-offs. Note that ultrathink in your prompt requests deeper reasoning for that turn without changing your session effort, which is a good way to pay the latency only when you need it.

The version of this that used to bite us most was total task time rather than latency — a session that felt Claude Code slow but was really just doing an enormous amount of real work because we had let it read half the repo. Two habits fixed it better than any setting: scoping each session to a single job, and matching the model to the task instead of leaving Opus on for everything. Bulk edits across dozens of draft files go to Haiku and fly through; we only reach for Opus 5 when a problem genuinely earns the extra thinking time.

Hooks run on every matching tool call

A hook is code rather than context, so /context cannot see it. A PostToolUse lint or type-check fires on every file write and quietly adds seconds to each one — the classic uniformly draggy session with no visible cause.

This one is sneaky, and it's the most common cause of Claude Code slow behaviour that /context can't explain. A hook is code, not context — but a slow hook fires on every matching tool call and silently taxes the whole session. A PostToolUse hook that runs a full lint or type-check after each edit can add seconds to every single file write, and Claude Code makes a lot of file writes.

If your session feels uniformly draggy with no obvious cause, this is a prime suspect. /doctor flags slow hooks specifically. Then go read your config with Claude Code hooks in hand and ask whether that check really needs to run 30 times an hour instead of once at commit time.

Environment: network, machine, and repo

A VPN adding 200ms per round trip adds it to every single message. So does an already-loaded machine, a monorepo that makes every glob expensive, and an IDE terminal that throttles output rendering.

Local reality bites more often than people expect, and it makes Claude Code slow in ways no slash command can fix:

• Network, VPN, or corporate proxy. Every turn is an API round trip. A VPN that adds 200ms per request adds it to every message. Try a direct connection for one session and compare.
• An overloaded machine. If your builds are already crawling, Claude Code inherits that. Its tool calls are your CPU's problem.
• A huge repo. Globs and greps across a monorepo with hundreds of thousands of files take real time. Scope your prompt to a directory.
• IDE-embedded terminals. Some integrated terminals throttle output rendering, which looks like slow streaming but is your editor, not the model. Test the same prompt in a standalone terminal.

Is the slowness actually upstream?

Platform overload shows up as slow streaming, 529 responses, and long queues, and no amount of /clear touches any of it. Check the status page before spending an hour tuning your own config.

Sometimes nothing you do locally helps, because the problem isn't local. API overload or degraded performance shows up as slow streaming, 529 errors, or long queues — and no amount of /clear fixes it. Check status.anthropic.com before you spend an hour tuning your config, and see is Claude down for how to read the signals. If the status page is green and everyone else is fine, it's you; if it's yellow, go get coffee.

Symptom to cause to fix

Match the shape of the delay to its cause: a pause before text points at context or effort, worsening-over-time at a growing conversation, slow-from-message-one at schemas or network, and laggy edits at a hook.

Use this as a lookup table the next time Claude Code slow performance shows up mid-task.