Why Claude Code Gets Slower the Longer You Use It, and How to Fix It
Why Claude Code Gets Slower the Longer You Use It, and How to Fix It
Claude Code is slow, but not randomly. There are two distinct failure modes, and most developers are solving the wrong one.
I measured this properly rather than guessing. Claude Code writes every session to disk with timestamps on each turn, so I analysed 35 days of my own: 350 session files, 74,493 assistant turns. The headline result:
| Context size | Median turn wall time | p90 |
|---|---|---|
| Under 25K tokens | 1.1s | 3.9s |
| 75K to 100K | 2.6s | 18.4s |
| 175K to 200K | 3.6s | 20.4s |
| 275K to 300K | 4.0s | 20.1s |
| 500K to 525K | 5.0s | 25.5s |
| 700K+ | 5.2s | 22.3s |
Slowdown from context is real, but it is roughly 5x and it flattens. Going from an empty session to 300K tokens costs you about 3 seconds per turn. Going from 300K to 700K costs about one more second. It is sublinear, not exponential. If your session feels ten times slower than it did an hour ago, context size is not the whole explanation.
The p90 barely moves at all. It sits at 19 to 22 seconds across the entire range. Whatever produces your worst-case waits, it is not the size of your context window.
The first genuine cause is round trips: Claude Code works in a loop of think, call a tool, read the result, think again. In my sessions, 74.9% of tool-calling turns issued exactly one tool call, so most work is strictly sequential. The second is context accumulation, which pushes every one of those round trips further along the curve above.
Quick answer: Claude Code slowness has two root causes. Too many sequential round trips, which is an architecture problem fixed by better prompts and CLAUDE.md, and a growing context window, which is a hygiene problem fixed by/compactor/clear. The measured cost of context is about 5x from empty to full, and it plateaus. The measured cost of a round trip is one full model turn, which is 2 to 4 seconds in a typical session. Cutting ten unnecessary tool calls saves more time than emptying your context window.
Table of Contents
- The short answer: two different problems that feel like one
- Why tool call latency is the real culprit, not token processing
- Why Claude Code gets slower as a session goes on
- How to diagnose what is actually causing the slowness
- Six fixes you can apply right now
- Claude Code vs Cursor vs Codex, where slowness comes from in each
- Common mistakes that make Claude Code slower over time
- Frequently Asked Questions
- Key Takeaways
The short answer: two different problems that feel like one
Developers searching "why is Claude Code slow" usually mean one of these:
- Slow from the first message, the model takes a long time to respond even on simple tasks early in a session
- Slow after a while, responses were fast initially but are now grinding, and nothing changed about the task complexity
These have different causes and different fixes. Conflating them leads to wasted effort, switching models when the real problem is context bloat, or clearing the session when the real problem is a vague prompt triggering 25 file reads.
The table below separates them clearly.
| Symptom | Likely cause | Primary fix |
|---|---|---|
| Slow on turn 1, short session | Model response latency, network, or exploratory tool calls | Scope the task more precisely in your prompt |
| Fast at start, slow by turn 20+ | Context window accumulation | /compact or /clear |
| Slow on every multi-file task | Sequential tool call chains | CLAUDE.md + explicit file scoping |
| Consistent lag across all sessions | Model tier selected | Switch to Sonnet or Haiku for simpler tasks |
| Occasional spike in latency | Prompt cache miss after idle gap | Work in tighter bursts |
Why tool call latency is the real culprit, not token processing
Most developers assume Claude Code is slow because it is "thinking," and most guides on this topic (including the first version of this one) blame the tools themselves. The measured data says both are wrong, and the real answer is more actionable.
Tool execution is nearly free. The turn around it is not.
Here is how long tools actually took in my 74,493 turns, measured from the moment Claude requested the tool to the moment the result came back:
| Tool | Calls | Median | p90 |
|---|---|---|---|
| Read | 4,372 | 0.01s | 0.05s |
| Edit | 6,924 | 0.03s | 3.09s |
| Bash | 18,879 | 0.12s | 7.15s |
| WebFetch | 466 | 5.04s | 10.33s |
| WebSearch | 313 | 9.33s | 12.35s |
| Subagent (Agent) | 176 | 2.41s | 30.12s |
So where does the time go? Into the model turn that sits between every pair of tool calls. Claude has to receive the result, re-process the entire conversation, decide what to do next, and emit the next call. That is the 2 to 4 seconds from the table at the top of this article, and it is paid once per tool call.
How sequential round trips compound into visible lag
Here is what a typical "fix this bug" instruction actually triggers, priced correctly this time. Assume a mid-sized session at roughly 100K context, where the median turn takes 3.1 seconds:
| Step | Tool time | Model turn |
|---|---|---|
| Read the file mentioned | 0.01s | 3.1s |
| Read a related import | 0.01s | 3.1s |
| Search for usages | 0.03s | 3.1s |
| Read another file found in the search | 0.01s | 3.1s |
| Run the test suite | 4.0s | 3.1s |
| Read the error output | 0.01s | 3.1s |
| Write the fix | 0.03s | 3.1s |
| Run tests again | 4.0s | 3.1s |
This is why the fix is not "make the tools faster." It is make fewer round trips, which means telling Claude where to look so it does not have to discover it, and letting it batch calls when it can.
The parallelism gap
Claude Code can issue several tool calls in a single turn, and when it does, they run concurrently and cost one model turn instead of several. In my sessions it mostly did not:
| Tool calls in one turn | Share of turns |
|---|---|
| 1 | 74.9% |
| 2 | 18.5% |
| 3 | 4.2% |
| 4 or more | 2.3% |
A vague prompt makes this significantly worse, because Claude cannot skip the exploration phase and cannot batch what it has not discovered yet.
How vague prompts trigger unnecessary tool call chains
The instruction "fix the auth bug" tells Claude nothing about where the bug is. Claude must explore: read the auth module, check the router, search for session handling, read middleware, look for tests. That exploration is 10–15 extra tool calls before any fix is written.
The instruction "in src/auth/session.ts, the cookie expiry is hardcoded to 3600 seconds, change it to use the SESSION_TTL env variable" eliminates the exploration entirely. Claude reads one file and writes one change.
Specificity is the single highest-impact speed optimisation for early-session slowness. It costs you 30 extra seconds of thinking time and saves 30–90 seconds of agent time.
Why Claude Code gets slower as a session goes on
Tool call latency explains early-session slowness. Context accumulation explains why sessions degrade over time.
Context window processing overhead grows with every turn
Every turn in a Claude Code session appends to the transcript:
- Your message
- Claude's response
- Every tool call made
- Every tool result returned (file contents, shell output, grep results, test logs)
This entire transcript is re-sent to the model on every single turn. The model does not maintain a running state, it re-reads the full conversation each time to understand where it is.
Here is how fast that actually happens, measured as median billed context per turn across my sessions:
| Turn number | Median context |
|---|---|
| 1 to 10 | 46,758 |
| 41 to 50 | 97,320 |
| 91 to 100 | 148,909 |
| 191 to 200 | 228,424 |
| 291 to 300 | 294,314 |
The effect on speed is real but smaller than most people assume, because prompt caching absorbs most of it. The measured result, from the table at the top of this article, is about 5x from an empty session to a very full one, and it flattens out past roughly 300K tokens. Compare that to the first-five-turns figure: median 1.4 seconds on turns 1 to 5, against 3.5 seconds on everything after. That 2.5x is the "it got slower" feeling, and it arrives early rather than at the extremes.
But latency is only half the cost of a bloated window. Output quality degrades too. As the transcript fills, the model spreads its attention across more and more tokens, and instruction-following weakens, the well-documented "lost in the middle" effect, where detail buried deep in a large context gets handled less reliably than detail at the edges.
There is no published cutoff for this, and it is gradual rather than a cliff. As a working heuristic, many developers notice quality slipping once a window is roughly 60% full, on Claude Opus 4.8's 1M-token window, that is somewhere around 600K tokens. Treat that figure as a signal to compact, not a hard limit: the right threshold depends on the task, and a context packed with stale tool output degrades faster than one carrying clean, relevant state.
The difference between slow at turn 1 and slow at turn 30
This is the diagnostic that saves the most time:
Slow at turn 1: The session is fresh, context is minimal. If Claude Code is slow here, the cause is model response latency, network conditions, or a prompt that immediately triggers a long chain of exploratory tool calls. Fix: write a more specific prompt. Optionally, switch to a faster model tier.
Slow at turn 30: You have been in the session for a while. Files have been read, commands have been run, errors have been processed. Context is large. Each new turn pays the full processing overhead of the entire history. Fix: /compact to summarise and continue, or /clear and restart with fresh context.
How to diagnose what is actually causing the slowness
Before applying any fix, confirm what you are actually dealing with.
Use --verbose to see tool call chains
Running Claude Code with the --verbose flag prints each tool call as it happens, showing you what Claude is doing and how long each step takes. If you see 15 file reads before any output, you have a tool call problem. If the first tool call response takes 8 seconds, you have a model latency or context problem.
claude --verboseWatch the output. Count the tool calls. Look for unexpected file reads that suggest Claude is exploring the codebase rather than executing a scoped task.
Signs Claude is exploring instead of executing
| Signal | What it means |
|---|---|
| Claude reads files you did not mention | Prompt is under-specified |
| Claude searches for function usages across the repo | Claude does not know where the relevant code lives |
| Claude reads test files before touching source | Claude is building its own context map |
| Claude opens the same file twice | Context was not retained or the task was ambiguous |
Diagnostic table: which fix applies to your situation
| Observation | Diagnosis | Fix |
|---|---|---|
| Slow from message 1, short session | Exploratory tool calls from vague prompt | Rewrite prompt with file paths and explicit scope |
| Slow from message 1, long session | Context bloat on first turn | /compact and restart |
| Fast early, slow by turn 20+ | Context accumulation | /compact mid-session |
| Consistent slow on all multi-file tasks | No CLAUDE.md, Claude navigates blind | Write a CLAUDE.md with file structure |
| Long stalls with no visible progress | Network drops, not Anthropic capacity | Check your own connection first |
Before you blame Anthropic, check your own network
This is the single most surprising thing in the dataset, and it will save you a lot of misdirected frustration.
Across 74,493 turns over 35 days of heavy use, Claude Code logged 375 API errors. Their breakdown:
| Error type | Count |
|---|---|
| Local connection failure (ECONNRESET, ENOTFOUND) | 325 |
| 5xx server errors (500, 502, 503) | 21 |
| 429 rate limited | 12 |
| 529 overloaded | 6 |
Claude Code retries these automatically with backoff, up to 10 attempts, which is why they surface as unexplained stalls rather than visible errors. If your session freezes for 30 seconds and then continues normally, the most likely explanation is that your wifi blinked, not that the model is thinking hard. Check your connection before you check the status page.
Six fixes you can apply right now
For more context on how to structure your work across multiple sessions, see 25 battle-tested practices for teams using coding agents.
1. Scope the files explicitly in your prompt
Give Claude the file path, the function name, and the expected change. Remove the need to explore.
Before: "Fix the bug in the payment flow"
After: "In src/payments/checkout.ts, the calculateTax() function returns undefined when the country code is missing. Add a fallback to 'US' if countryCode is null or undefined."
The second prompt eliminates at minimum 5–10 tool calls. On a 400ms-per-call basis, that is 2–4 seconds of latency removed before Claude touches any code.
2. Use CLAUDE.md to prevent codebase re-exploration every session
CLAUDE.md is loaded at the start of every Claude Code session. If it contains a clear map of your repo, where the auth lives, what the main entry points are, which files Claude should never read, Claude starts every session already oriented. It does not need to explore.
A CLAUDE.md entry as simple as this eliminates a category of exploratory tool calls:
# Structure
- Auth: src/auth/, session handling in session.ts, middleware in auth.middleware.ts
- Payments: src/payments/, do not read stripe-legacy/ unless explicitly asked
- Tests: tests/, mirror structure of src/This is a speed optimisation, not just a context optimisation. Every session that does not start with exploratory file reads is a faster session. For a comprehensive guide on writing effective CLAUDE.md files, see our guide to designing AI agents.
3. Run /compact instead of continuing a bloated session
When a session is long but you need continuity, you're mid-feature, you've made architectural decisions Claude should remember, /compact is the right tool. It asks Claude to summarise the full conversation into a short working memory, replacing hundreds of thousands of tokens of transcript with a few thousand tokens of essential context.
/compactUse /compact when: the session is slow but you genuinely need the model to remember prior decisions.
Know what it costs before you reach for it. Across 97 compactions in my sessions:
| Measure | Value |
|---|---|
| Median context before compacting | 420,840 tokens |
| Median wall time to compact | 123 seconds |
| p90 wall time | 158 seconds |
| Worst case | 198 seconds |
| Context immediately after | 65,844 tokens (an 84% cut) |
| Context 10 turns later | +22% and climbing again |
/compact is a genuine 84% reduction, it costs you roughly two minutes of standing still, and it buys about ten turns before the context starts filling again. It is a useful tool and a bad habit. If you find yourself compacting repeatedly in one session, the session is the problem.Write your working state to a file before you compact. /compact is lossy by design, it replaces the transcript with a summary, and anything the summary omits is gone. Do not rely on the compacted memory alone to carry decisions forward. Have the agent maintain a plan-and-decisions file on disk (todo.md, DECISIONS.md, or a scratchpad) as it works. The durable loop is: finish a task → write current state and next steps to the file → /compact (or /clear) → tell the agent to re-read the file and continue. State lives on disk, where compaction cannot touch it, and the context window becomes disposable.
Use /clear when: the task has changed or the session context is no longer relevant. Starting fresh is faster than compacting stale information.
For a detailed breakdown of cost implications of both commands, see the guide on how to cut Claude Code cost.
4. Switch models by task type, speed is not only a cost decision
Model selection affects response latency independently of cost. Claude Haiku 4.5 responds significantly faster than Sonnet or Opus in wall clock time, not just in tokens per dollar. For tasks that do not require deep reasoning, such as renaming a variable, formatting a file, or generating a repetitive pattern, Haiku is faster and cheaper.
Switch models in Claude Code with:
/model haiku
/model sonnetA practical heuristic:
| Task | Recommended model | Reason |
|---|---|---|
| Rename, formatting, repetitive edits | Haiku 4.5 | Fast, cheap, sufficient |
| Single-file logic, debugging | Sonnet 5 | Balanced speed and quality |
| Cross-file architecture, hard bugs | Sonnet 5 or Opus 5 | Best quality per dollar on hard work |
| Long autonomous runs, novel algorithms | Opus 5 | Strongest on long-horizon work, slowest per turn |
low, medium, high, xhigh, and max, and it controls both how deeply the model reasons and how many tool calls it makes before answering. Lower effort produces fewer, more consolidated tool calls and less preamble, which compounds into real wall-clock savings because each tool call you avoid is a full model turn you avoid.In my own sessions, 78% of turns ran at high. For routine work that was the wrong default. If a session feels sluggish on simple tasks, try dropping effort before you try switching model, and note that switching model mid-session also throws away your prompt cache.
There is one more speed control worth knowing about: fast mode, available on Opus-tier models, runs the same model at up to 2.5x higher output tokens per second at premium pricing. It is a latency purchase, not a quality one.
5. Run parallel Claude Code sessions for independent workstreams
Claude Code is single-threaded within a session, each tool call waits for the previous one to complete. But you can run multiple Claude Code instances simultaneously in separate terminal windows or tmux panes.
If you have two unrelated tasks, writing tests for module A while refactoring module B, running them in parallel halves the wall clock time. Each session carries only its own context, with no cross-contamination.
# Terminal 1
claude # Working on auth tests
# Terminal 2
claude # Working on payment refactorThis is one of the most underused speed strategies available to Claude Code users. It requires no configuration and costs the same as running the tasks sequentially.
For a step-by-step guide on how to structure parallel sessions safely, including worktrees, subagents, and how to avoid merge conflicts, see Parallel Claude Code Agents: How to Speed Up Coding Without Breaking Your Repo.
6. Clear and restart when context is stale
If the session has drifted, you fixed one bug, then another, then started a new feature, the accumulated context is more noise than signal. A /clear and a precise new prompt will almost always be faster than continuing a heavy session.
/clearThe test: if you had to explain the current session context to a new colleague in two sentences, and you cannot, the session is too stale to be useful. Start fresh.
Claude Code vs Cursor vs Codex, where slowness comes from in each
The tool call architecture is common across all three tools. The differences are in packaging and where the bottlenecks appear.
| Tool | Primary speed bottleneck | What helps |
|---|---|---|
| Claude Code | Sequential tool calls + context accumulation | /compact, CLAUDE.md, explicit file scoping |
| Cursor | "Max mode" uses frontier models with long reasoning | Disable Max mode for routine tasks; use standard mode |
| Codex (OpenAI) | Reasoning tokens on o-series models are hidden but billed | Disable extended thinking for simple tasks; use GPT-4.1 for speed |
/model sonnet in Claude Code.For Codex, the equivalent is disabling reasoning mode when deep reasoning is not needed.
One correction worth making here, because it appears in a lot of older advice including an earlier version of this post: the "work in tight bursts to keep the cache warm" rule no longer applies to Claude Code. Anthropic offers both a 5-minute and a 1-hour cache TTL, and in my measured sessions 89% of cache writes used the 1-hour option. Idle gaps are no longer the thing to manage. What still costs you is invalidating the cache prefix by switching models, editing CLAUDE.md, or changing your MCP servers mid-session.
Common mistakes that make Claude Code slower over time
Keeping one session alive all day. Context accumulates, gaps cause cache misses, and the session becomes progressively more expensive and slower to respond. A clean session each morning, or each major task switch, is almost always faster.
Using the agent as a file browser. Asking "what does this function do?" inside a long session makes Claude read and process files it may have already read, re-billing that context into an already heavy transcript. For exploratory questions, open a fresh short session.
Letting tool calls run unbounded. Instructions like "look through the codebase and find everywhere this pattern is used" can trigger 30+ file reads. If you need that analysis, scope it: "search only in src/components/ for uses of the useAuth hook."
Ignoring the --verbose output. Most developers never look at what Claude is actually doing between their prompt and the response. Running --verbose once per session type teaches you where the tool calls are going and where the time is being spent.
Switching models for speed without fixing the underlying prompt. A faster model running 20 unnecessary tool calls is still slower than the right model running 3 targeted tool calls.
Frequently Asked Questions About Why Claude Code Is Slow
Why does Claude Code get slower during a long session?
Every tool result and conversation turn is appended to the context window, which is re-processed on every subsequent call. Measured across 74,493 of my own turns: median turn time is 1.1 seconds under 25K tokens of context and 4.0 seconds at 300K, so the practical penalty is roughly 4x. Within a single session, the first five turns ran at a median of 1.4 seconds against 3.5 seconds for everything after.
The important nuance is that the curve flattens. Going from 300K to 700K tokens only adds about another second per turn. If a session feels dramatically slower than that, look at how many tool calls each turn is making rather than at the size of your context.
What is a tool call and why does it cause latency?
A tool call is a discrete action Claude takes, such as reading a file, running a shell command, or searching a directory. It is not the tool that is slow. In my measurements, a file read completed in a median of 10 milliseconds and a shell command in 120 milliseconds.
The latency comes from the model turn wrapped around each call: Claude must receive the result, re-process the conversation, and decide the next step, which takes 2 to 4 seconds in a typical session. A task requiring 20 sequential tool calls therefore costs roughly a minute of model turns, almost none of which is spent executing tools.
Is Claude Code slow because Anthropic is overloaded?
Almost never, in my data. Across 35 days and 74,493 turns I logged 375 API errors, of which 325 were local network failures on my side. Only 12 were rate limits and 6 were overload errors. Claude Code retries these silently with backoff, so they present as unexplained pauses. Check your own connection before checking the status page.
Does switching to a smaller model fix Claude Code slowness?
Partially. Smaller models like Haiku respond faster in wall clock time, so model switching helps. But if the root cause is tool call chains or context accumulation, a faster model running the same number of tool calls on the same bloated context will still be slow. Fix the tool call problem with better prompts and CLAUDE.md first, then consider model selection.
What does --verbose do in Claude Code?
The --verbose flag prints each tool call as it executes, showing what Claude is reading, running, or searching, and when. It is the primary diagnostic tool for understanding whether slowness is coming from exploratory file reads, long-running shell commands, or model inference time. Run it once on a typical session to understand your personal bottleneck.
How is Claude Code slowness different from Cursor slowness?
The underlying cause is the same, sequential tool calls and context accumulation, but the controls differ. In Cursor, disabling Max mode switches from frontier models to faster mid-tier models. In Claude Code, /model sonnet or /model haiku achieves the same effect. Context management in both tools benefits from starting fresh sessions for unrelated tasks.
When should I use /compact versus /clear?
Use /compact when you need the model to remember prior decisions in the session, architectural choices, debugging context, in-progress feature logic, but the session has grown slow. /compact summarises the transcript into a short working memory. Use /clear when the task has changed completely and prior context is irrelevant. Starting fresh is faster than carrying stale context.
Does CLAUDE.md actually improve speed?
Yes, directly. CLAUDE.md is loaded at session start and tells Claude where things live in your codebase. Without it, Claude often reads multiple files to orient itself before doing any work. A well-structured CLAUDE.md eliminates that exploration phase, reducing tool calls on the first turn of every session. It is both a speed and a quality improvement.
Key Takeaways
- Tools are not the bottleneck. Round trips are. A file read takes 10 milliseconds; the model turn wrapped around it takes 2 to 4 seconds. Cutting a tool call saves 300 times more time than speeding one up.
- Context costs about 5x, and it plateaus. Median turn time went from 1.1s under 25K tokens to 4.0s at 300K, then only 5.2s past 700K. If your session feels ten times slower, context is not the whole story.
- The p90 sits at 19 to 22 seconds regardless of context size. Worst-case waits are a different problem from average slowness. Do not try to fix them with
/compact. - 74.9% of tool-calling turns made exactly one call. Naming several files up front lets Claude batch them into a single turn, which is the cheapest speed win available.
/compactcosts about two minutes and buys about ten turns. It cut context 84% in my sessions, then context regrew 22% within 10 turns.- 87% of my API errors were my own network, not Anthropic. Claude Code retries silently, so they look like stalls. Check your connection first.
- Effort is a bigger latency lever than model choice. Lower effort means fewer tool calls, and every tool call avoided is a model turn avoided.
- A vague prompt can trigger 15 or more unnecessary tool calls, which at typical context size is close to a minute of pure waiting. Specific prompts with file paths eliminate the exploration phase entirely.
- CLAUDE.md is a speed tool. A repo map at session start prevents Claude from navigating your codebase blind on every session.
CTA
If Claude Code degraded after an Anthropic product update rather than a long session, see Why Is Claude Code Slow? Official Causes and Developer Fixes, a runbook based on Anthropic's April 23 postmortem covering effort settings, the caching bug, and the system prompt change.
If you have not read the companion post on how to cut Claude Code cost, speed and cost are the same root problem viewed from different angles. The session hygiene and model selection guidance there applies directly to the fixes in this post.
Coming next: a full CLAUDE.md optimisation guide and a practical breakdown of running parallel Claude Code sessions.
References
- Anthropic - Claude Code documentation
- Anthropic - Prompt caching documentation
- Anthropic - Model overview and pricing
- Anthropic - Claude models overview
- Primary data: 350 Claude Code session transcripts from
~/.claude/projects/, covering 74,493 assistant turns across 35 days on client versions 2.1.187 to 2.1.222. Turn latency measured as wall time between the previous event and the assistant response; tool latency measured between the tool request and its result.
Aakash Ahuja
Enterprise AI, Cybersecurity & Platform Engineering
Aakash writes about secure AI agents, microservices architecture, enterprise platforms, and production engineering. He has 20+ years of experience building and operating software systems across banking, cloud, cybersecurity, AI, and enterprise workflow automation. He is Director of Technology at itmtb Technologies and teaches AI, Big Data, and Reinforcement Learning at top institutes in India.