Claude Code Speed Guide | Why It's Slow and How I Made It 3x Faster

“Is Claude Code getting slower lately?”

I automate article generation for this site with Claude Code every day, and I had the same frustration in the first week. What used to take 15 minutes per article dropped to an average of 4–5 minutes after tuning the setup — roughly 3x faster.

In this article, I’ll cover the root causes of why Claude Code slows down and the speed optimization techniques I actually tested and found effective. Rather than just “how to make it faster,” I want you to understand why each technique works.

Why Does Claude Code Get Slow?

Before optimizing, you need to understand the causes. There are three main reasons Claude Code feels sluggish.

Cause 1: Context Is Bloating

Claude Code calls the API with the full conversation history as context. The longer the session, the more data it sends each time, and the slower responses get.

Right after session start: context ~2,000 tokens  → fast
After 1 hour:              context ~30,000 tokens → slow
After half a day:          context ~80,000 tokens → very slow (or errors)

In my experience, once context exceeds 50,000 tokens, the perceived speed drops to less than half.

Cause 2: Reading Too Many Files

Giving instructions like "Read the entire repo and understand it before implementing" causes Claude Code to attempt to read a huge number of files. The waiting time when it runs dozens of Glob and Grep commands is almost entirely “time spent reading files.”

Cause 3: Model Processing Load

Opus is powerful, but it takes longer to generate responses. Many tasks use Opus when they don’t need to — that’s overkill for the task at hand.

---

Fix 1: Make /compact a Habit

The most immediately effective fix. Claude Code has a /compact command that compresses and summarizes conversation history, dramatically reducing context size.

# Run inside the Claude Code REPL
/compact

I made it a habit to run /compact once an hour or at each natural break in work. This alone improves perceived speed by 1.5–2x.

Start New Tasks in a New Session

For new tasks that don’t need the context of previous work, restarting Claude Code and beginning a fresh session is faster. Restarting takes less than 5 seconds.

# Exit and restart
exit
claude

When you do want to reference earlier work, pasting only the relevant information after /init is faster and more accurate in the end than carrying over a long conversation history.

---

Fix 2: Explicitly Narrow the Scope of Instructions

Reducing unnecessary file reads leads to significant speed gains.

Before / After Comparison

# ❌ Slow: scope too broad
claude -p "Fix the bug in this project"
# → Glob → Read × dozens of times → takes forever

# ✅ Fast: scope limited
claude -p "Fix the null check missing at line 108 in src/api/auth.ts"
# → Read 1 time → fix done

A pattern I use often:

# Tell it to read only specific files
claude -p "Read only the files below and fix the issue. You don't need to read anything else:
- src/components/Button.tsx
- src/styles/button.css
Problem: hover styles are not applying"

Adding “you don’t need to read anything else” stops unnecessary exploration behavior.

---

Fix 3: Use the Right Model for the Job

Using Opus for every task is wasteful in terms of speed.

Opus:   Complex design · difficult debugging · code review
Sonnet: General implementation · refactoring · documentation
Haiku:  Translation · formatting · simple transformations

Switching Models in Claude Code

# Switch model during a session
/model claude-sonnet-4-6

# Speed note: Sonnet is roughly 2–3x faster than Opus in practice

For my site operations:

• Japanese article body → Sonnet (structure quality is sufficient, faster than Opus)
• Multi-language translation → Haiku (translation quality is perfectly usable, dramatically faster)
• Design discussions · complex implementation → Opus (quality-first here only)

This split brought per-article generation time from 15 minutes → 4 minutes.

---

Fix 4: Parallel Execution with Sub-Agents

Parallelizing heavy processing can dramatically cut total time.

Parallel Translation (the method I actually use)

// ❌ Sequential translation: 9 languages × 30 seconds = 270 seconds (4.5 min)
for (const lang of languages) {
  await translate(article, lang);
}

// ✅ Parallel delegation with Agent tool: time = slowest language ≈ 30 seconds
// (This site went from 8 min → 1.5 min by delegating to sub-agents in bulk)
Agent({
  prompt: `Translate ${article} into 9 languages and save each file: EN/DE/ES/FR/HI/ID/KO/PT/ZH`
})

Sub-agents run in their own independent context, so they don’t pollute the main context. This also contributes to speed improvement.

---

Fix 5: Speed Up Input with Prompt Caching

When you reuse the same system prompt repeatedly, prompt caching makes input processing roughly 10x faster. This has a noticeable effect on perceived speed.

// Just add cache_control
system: [
  {
    type: "text",
    text: longSystemPrompt,
    cache_control: { type: "ephemeral" },
  },
],

When you reuse the same system prompt within 5 minutes, the second call onwards is noticeably faster than the first.

---

Fix 6: Reduce Unnecessary Exploration with CLAUDE.md

Writing “commands to use,” “directory structure,” and “do-not-read” rules in CLAUDE.md lets Claude Code act directly without wandering.

# Project Rules

## Frequently Used Commands (no need to look these up each time)
- Build: npm run build
- Test: npm run test
- Deploy: bash scripts/deploy.sh

## Directory Structure
- src/components/: UI components
- src/pages/: routing
- src/content/blog/: blog articles (MDX)

## Important: Do NOT read these
- node_modules/
- .wrangler/
- site/dist/

This reduces the number of turns Claude Code spends figuring out “where should I look,” which speeds things up overall.

---

Real Speed Improvement Numbers (This Site)

For reference, here are actual results from this site (claudecode-lab.com).

Task	Before Optimization	After Optimization	Reduction
Article generation (Japanese)	8 min	2.5 min	69% faster
9-language translation	7 min	1.5 min	79% faster
Build + deploy	13 min	11 min	15% faster
Total (per article)	28 min	15 min	46% faster

By also rigorously applying /compact and session management, the site now runs stably at 10–12 minutes per article.

---

Speed Optimization Checklist

Listed in order of what to check first.

Do right now (under 1 minute):
□ Run /compact to compress context
□ Restart a session that's been running for a long time
□ Switch translation/formatting tasks to Haiku

Do today (30 minutes):
□ Add "directories not to read" to CLAUDE.md
□ Add frequently used commands to CLAUDE.md
□ Build a habit of breaking large tasks into "scope-limited small tasks"

Do this week:
□ Add cache_control to repeated batch processes
□ Create patterns for delegating parallelizable tasks to Agent tool
□ Define model-usage rules and add them to CLAUDE.md

---

Summary

The root causes of Claude Code slowness are “context bloat” and “inefficient file exploration.” Being aware of just these two will make a big difference in perceived speed.

My prioritized list of the most impactful improvements:

1. Making /compact a habit (immediate effect, zero cost)
2. Using the right model for each task (switching translation to Haiku alone is dramatic)
3. Explicitly scoping instructions (just adding “you don’t need to read anything else”)
4. Parallel delegation to sub-agents

You don’t need to do all of this at once. Just incorporating /compact into today’s work should already feel noticeably faster.

Related Articles

• Complete Guide to Cutting Claude Code API Costs by 90%
• Complete Guide to Harness Engineering
• 10 Dangerous Prompt Patterns in Claude Code