If Claude Code is slow today, frozen mid-tool-call, or taking ninety seconds to answer "hi", the cause is almost always one thing: your context window is full. The session you have been pasting into for two hours holds 180,000 tokens of stale tool output, and every new turn re-reads all of it.
The fix is /clear. Second fix, /compact. Third, audit what loads at session start. If none of that helps, check status.claude.com (status.anthropic.com redirects there now) for an active incident.
That is the whole article. The rest is detail.
Triage in 30 seconds
Open status.claude.com. If Claude Code shows anything other than green, stop reading and wait. The page tracks claude.ai, the API, Claude Code, Console, Cowork, and Claude for Government separately, so confirm Claude Code itself is the degraded service.
If status is green, run /clear and ask your question again. If it is fast, you had context bloat. Done.
If a fresh session is still slow, run /doctor (Claude Code's built-in diagnostic, which also covers skill listing overflow) and check /model. If you are on Opus, switch to Sonnet and see if speed returns.
A fresh session that is still sluggish is usually a network problem. VPN off, try again.
Cause 1: context bloat
This is 95% of "Claude Code slow today" reports. A session that has read fifteen files, run twenty bash commands, and held a conversation about three unrelated tasks carries every byte of that history into every new turn. The model is reading a small novel before each response, which takes the time it takes.
Two commands fix it.
/clear wipes the session and starts fresh. Use this between unrelated tasks. Finished debugging the auth bug, want to refactor billing next? /clear. The cost of reloading what you actually need is lower than dragging the auth context along.
/compact summarizes the current session and continues from the summary. Claude Code auto-compacts around 95% capacity, but waiting that long is a mistake. By 95% the model has been slow for a while. Run /compact manually at 60%, often with a focus hint: /compact focus on the database schema changes we just made. The hint tells the summarizer what to keep verbatim. (code.claude.com/docs/en/how-claude-code-works)
For expensive sub-tasks that would otherwise eat your main context, push the work into a forked subagent via /agents or the bundled Task tool. The subagent burns its own window and hands back a summary. Right pattern for "read these forty files and tell me which import from legacy/". (code.claude.com/docs/en/sub-agents)
Cause 2: too many skills
Every installed skill contributes its name and description to a metadata listing that loads at session start. Default budget is 1% of the model's context window, around 2,000 tokens on a 200K window. Past that, descriptions get truncated and skills drop from the listing. (code.claude.com/docs/en/skills)
The startup penalty is real. Twenty-five installed skills with 900-character descriptions is roughly 22,500 characters Claude Code processes before doing anything else. That is the slow claude startup people complain about.
Run /skills, count, and uninstall what you do not use. Tighten descriptions on what remains. Full diagnostic and the math on skillListingBudgetFraction is in the sibling piece, Why your Claude Code skill is not loading. Short version: a 130-character description does the same job as a 900-character one at one-seventh the budget. Knack's authoring flow constrains description length during the interview, so skills produced by it stay under the budget by construction.
Cause 3: large reads, parallel tool calls
A 30,000-line file read sits in your context for the rest of the session. So does a git log with no limit. So does a directory listing of node_modules. If you remember pulling something enormous in an hour ago, it is still there.
Use offset and limit on Read. Use Glob and Grep instead of find and cat. The dedicated search tools return only what matched. Parallel tool calls amplify the problem: six file reads in one batch is six payloads added at once. If you suspect this is the cause, /compact and move on.
Cause 4: Opus is slower than Sonnet
Opus trades speed for reasoning. For most of what Claude Code does (reading code, running tests, editing files), Sonnet is faster and the quality delta is small. Switch with /model sonnet mid-session; the change applies on the next turn.
Reserve Opus for parts that need the reasoning: long architectural plans, gnarly debugging, anything that needs many constraints held at once. Day-to-day tool use is Sonnet's job.
Cause 5: the network
If /clear does not help, Opus-to-Sonnet does not help, and status is green, you are looking at network. VPN routing through a distant region is a common culprit. Corporate firewalls that MITM TLS add hundreds of milliseconds per request. If first-token latency feels like fifteen seconds (an actual reported issue) and only on your machine, it is your machine's path to the API. Try a phone hotspot for one prompt as a diff test.
What is not a fix
Rebooting your laptop will not fix context bloat. Reinstalling Claude Code will not fix it either (unless it happens to clear the session, in which case /clear would have saved the time). Updating sometimes helps if you were on a regressed release, but the GitHub issue tracker is the place to confirm. Switching to a different AI tool because today felt slow is not a fix. Codex has the same context-budget mechanics with different defaults; every coding agent that loads tools at startup pays this tax.
The daily habit
Run /clear between unrelated tasks. Not at end of day, not when things feel slow. Every time you finish one thing and start another. The five seconds it costs to reload the file you were just looking at is a rounding error against a 150K-token session holding four conversations. That habit alone will eliminate most "claude code freezing" complaints you would otherwise have this month.