How to Make Claude Code Faster
Claude Code slows down for three different reasons: model latency, tool execution time, and an overloaded context. Each has a different fix. Here is how to tell them apart and what to do about each one.
Updated 5 min read
Claude Code is slow for three different reasons, and each one has a different fix. Confusing them leads to changes that feel productive but do not actually help. Tools like fenbs keep concise plans and confirmed findings outside the session, so Claude Code starts each task with the essential context rather than re-reading everything to work out where to begin.
The three causes are model latency (the time to generate a response), tool delays (how long file reads, shell commands and searches take), and an overloaded context (the model spending tokens on material that is not relevant to the current task). Diagnose before you change anything.
Diagnosing model latency
Model latency is the delay between sending a message and seeing the first token of the response. It includes network round-trip time and the time the model takes to process the prompt. If Claude Code starts typing quickly but takes a long time to finish a long response, that is generation time, not latency.
High latency on a short prompt usually points to API load or network conditions rather than anything in your configuration. Check the Anthropic status page (opens in a new tab) to rule out an incident. If latency is consistently high on short prompts across sessions, try a different network or a different time of day.
Choosing a faster model reduces generation time. Claude Haiku is significantly quicker than Claude Sonnet or Opus and suits tasks that do not need deep reasoning. You can switch models with the --model flag. For tasks where speed matters more than depth, start with Haiku and escalate only when the result is not good enough.
Reducing tool execution time
Claude Code uses tools to read files, run shell commands and search your codebase. Each tool call takes real time. A task that involves reading fifty files to find one relevant function is much slower than a task where Claude Code knows which file to look at.
You can speed up tool-heavy tasks by being specific. Instead of "find the function that handles authentication," say "look at src/auth/session.ts, specifically the validateToken function." Claude Code reads one file instead of searching many.
Shell commands that take a long time (test suites, builds) are not Claude Code slowness — they are the actual work taking its natural time. Avoid asking Claude Code to wait for a long-running command when you can run it separately and share the result.
Managing context size
A large context window means the model processes more tokens per response. This increases generation time and cost. More importantly, a context full of irrelevant material makes it harder for the model to focus on the current task.
Start a new session for a new task rather than continuing in an old one with a long history. The transcript from debugging a CSS bug is not useful context for refactoring a database query. Starting fresh is faster and usually produces better results.
Keep your AGENTS.md and CLAUDE.md files concise. Every token in those files is read at the start of every session. Long, detailed context files that cover every historical decision slow every session. Move infrequently needed detail to a linked document and keep the main file focused on what is relevant today.
Give Claude Code the right context, not all the context
fenbs keeps concise, current plans, decisions and progress for each task. When a session starts, a connected Claude Code reads only what is relevant: the current task, the rules that apply, and Where we left off. It does not re-read a long chat history to find where things stand. Smaller context, faster start.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
Other factors that affect speed
The amount of work per turn matters. Asking Claude Code to refactor an entire large module in one turn is slow because it reads many files, writes many changes and generates a long response. Breaking the work into focused turns is often faster than one large request, because each turn is shorter and easier to verify.
Auto-accept mode (where Claude Code runs tools and makes edits without pausing to ask permission) removes confirmation delays. Use it for tasks where you have reviewed the plan and trust the approach. For exploratory or risky changes, the confirmation pauses are useful.
For making Claude's general responses faster — not specific to Claude Code — a separate page covers that topic in detail.
How to do this with fenbs
- Create a free account and add the project.
- Write each task with a clear, specific goal and the exact files or functions involved. A specific plan means fewer exploratory tool calls.
- Record confirmed findings as context notes. "The authentication bottleneck is in
validateTokeninsrc/auth/session.ts" saves Claude Code from rediscovering it each session. - Connect Claude Code from Integrations and ask it to read the project context at the start of each session.
- After the session, save Where we left off with the next specific step. Starting from a precise checkpoint is faster than starting from a general goal.
For more on what Claude Code is and how to install it, see what is Claude Code and how to install Claude Code.
A practical checklist
- Short prompt, slow to start: check API status and network first.
- Long response taking time: expected — try a smaller model or a more focused request.
- Many tool calls to find basic facts: be more specific in your instructions.
- Good results but slow session: check context file length and start fresh sessions for new tasks.
- Commands taking long: that is the work itself; separate them from Claude Code's response time.