Claude Code Speed Optimization: Diagnose Slow Sessions and Work Faster

When Claude Code feels slow, the first suspect is usually not the model. In practice, slow sessions usually come from bloated conversation history, broad file exploration, noisy test output, or instructions that make Claude inspect half the repository before making one change. On this site, the slowest sessions happened when article writing, translation, build logs, deployment, and debugging were all kept in one conversation. The fix was not a single magic setting; it was a workflow that checks /usage and /context, compacts intentionally, and narrows what Claude is allowed to read. This guide is written for beginners who want a practical operating system for speed: how to diagnose the slowdown, how to structure prompts, what to put in CLAUDE.md, where subagents help, and what mistakes make things worse.

Diagnose before tuning

Start with diagnosis. The /usage command is now the main entry point for understanding current usage. API users see session token usage and a locally estimated dollar amount; subscribers see plan usage bars and usage attribution. Treat it as an operating meter, not as the final billing source. Then run /context. It shows which parts of the environment are taking context: conversation history, memory, MCP, tools, and other loaded instructions. If MCP or memory dominates, switching models will not solve the real problem. Use /compact before the session becomes hard to steer. The important detail is to say what should survive compaction: changed files, failing tests, decisions, and unresolved questions. That keeps the session lighter without erasing the working state.

# Run these inside Claude Code before changing the workflow
/usage
/context
/compact Preserve changed files, test failures, decisions, and open questions

Build a fast default workflow

My default loop is simple: check /usage and /context at the start of a heavy task, use /compact with instructions at natural breaks, and use /clear when switching to an unrelated task. Clearing context is not a failure; it is often the cheapest way to stop yesterday’s assumptions from leaking into today’s work. The second habit is scoping. Do not ask Claude to understand the whole project when the bug is in one file. Tell it which files to read first, which test to run, which directories to avoid, and what evidence should be returned at the end. The third habit is keeping CLAUDE.md small. Official memory guidance treats CLAUDE.md as the place for facts that must be known every session. Long procedures, rare playbooks, and domain-specific workflows belong in rules or skills so they do not tax every request.

claude -p "Fix only the null-check bug in src/api/auth.ts.
Read src/api/auth.ts and tests/auth.test.ts first.
Do not scan node_modules, dist, coverage, or unrelated feature folders.
Return the changed files, commands run, and remaining risks."

Put only always-needed facts in CLAUDE.md

The following example is intentionally short. It gives Claude the stable map of the repository without turning memory into a permanent documentation dump.

# CLAUDE.md

## Project commands
- Build: npm run build
- Test: npm run test
- Type check: npm run typecheck

## Fast navigation
- API code: src/api/
- UI components: src/components/
- Tests: tests/

## Do not read unless explicitly requested
- node_modules/
- dist/
- coverage/
- .wrangler/

## Compact instructions
When compacting, preserve changed files, failing tests, decisions, credentials policy, and next actions.

Measure with a small benchmark

Do not optimize only by feeling. Run the same type of task once with a wide prompt and once with a scoped prompt, then compare elapsed time, number of files read, and quality of the final evidence.

$runs = @(
  @{ Name = "wide"; Prompt = "Find and fix the auth bug in this project" },
  @{ Name = "scoped"; Prompt = "Fix the null-check bug in src/api/auth.ts only" }
)

foreach ($run in $runs) {
  $elapsed = Measure-Command { claude -p $run.Prompt }
  [pscustomobject]@{
    Name = $run.Name
    Seconds = [math]::Round($elapsed.TotalSeconds, 1)
  }
}

Three practical use cases

Small bug fix

Give Claude the file, the failing test, and the exact acceptance condition. Exploration drops from dozens of reads to a few targeted reads, and the final review becomes shorter.

Large refactor

Split the work into investigation, patch, test, and review. Compact after each phase while preserving decisions. This avoids carrying raw exploration logs into the implementation phase.

Publishing or translation pipeline

Delegate translation, page checks, or list generation to a subagent. Keep the main session responsible for decisions, final verification, and deployment notes only.

Failure cases to avoid

• The first mistake is using /compact as a blind speed button. If you do not tell Claude what to preserve, the summary may lose the exact failing command or the reason a design choice was made.
• The second mistake is turning CLAUDE.md into a warehouse. A file that contains every old incident, every personal preference, and every rare procedure becomes a permanent tax on every session.
• The third mistake is removing verification to save time. Do not feed Claude every log line, but do preserve the failing lines, expected behavior, and the command that reproduced the issue.

Official docs checked

• Claude Code costs and /usage: https://code.claude.com/docs/en/costs
• Claude Code monitoring and telemetry: https://code.claude.com/docs/en/monitoring-usage
• Claude Code memory and CLAUDE.md: https://code.claude.com/docs/en/memory

What I verified for this rewrite

For this rewrite I checked the current Claude Code docs for Costs, Monitoring, and Memory. The article now centers on /usage, /context, /compact, CLAUDE.md, and scoped prompts instead of old /cost-only habits.

Next step

If your team is trying to make Claude Code faster, do not start by buying a bigger model or adding more automation. First standardize the prompt shape, the memory file, and the verification receipt. The internal links below continue the same operating model.

• Token optimization
• Claude Code permissions guide
• Harness engineering guide
• Consultation and training