When Claude Code starts dragging, there are really only two suspects, and they have nothing to do with each other. One is the session you're in: the more context the model is carrying, the longer each reply takes, because it has to reason over everything you've loaded. The other is the wire. Claude Code is chatty by design, firing off one round trip after another to read a file, run a command, read the result, edit, and so on. If each of those trips pays an extra hundred-plus milliseconds, a task that should take seconds turns into a long wait.
The catch is that the advice you'll find first, compact your context, drop to a lighter model, only touches the session side. If your actual problem is the route to the API, you can compact until you're blue in the face and the agent will still feel sluggish, because the network tax gets charged on every single tool call.
The two people who complain about this
One is the developer who's been in the same session for hours. At 9am everything is snappy. By mid-afternoon the same prompts take noticeably longer. That's context piling up. A chat that opened at fifteen thousand tokens behaves like a different tool at sixty thousand, and nothing about the network has changed.
The other one sits far from the API, geographically. For them Claude Code is slow on the very first command, every command, regardless of how fresh the session is. Every request has to travel a long, often congested path and come back, and when the agent chains a dozen reads and edits, those delays stack up into something you can feel. Figuring out which person you are is most of the battle.
Working out which one you've got
Start with the cheapest test there is. Open a brand-new session and send the exact prompt that felt slow earlier. If the fresh session is quick and the old one wasn't, you have context bloat, not a network problem. The fix is housekeeping. Compact early, somewhere past roughly a hundred thousand tokens of input. Spin up clean sessions for unrelated work instead of letting one balloon. And stop dragging large bundles or generated assets into context, because the model reads every byte of what you load before it does anything useful with it.
If the fresh session is also slow, the problem is on the wire, and now you want numbers.
Time the round trip
Ping the API host and note your baseline. If it sits consistently above 200 ms, every sequential tool call inherits that delay. And Claude Code is sequential by nature: read, run, read, edit. A single task can rack up twenty or more round trips, so a 250 ms route quietly turns into several seconds of pure waiting before the model has reasoned about anything. This is the most common reason slowness sticks around after you've already trimmed your context, and it's the one people miss.
Don't trust the average
A route can post an acceptable average latency and still feel awful, because jitter swings it around and the occasional dropped packet has to be resent. A casual ping won't show you any of that. Run a short mtr session instead and read the loss column per hop. Retransmissions are invisible until they freeze your cursor mid-edit, and interactive coding is unusually sensitive to them. A route that holds a steady, unspectacular latency will beat a route with a great average and ugly spikes every time.
A quick word on model choice
Not every step deserves your heaviest model. Quick syntax questions and short explanations come back far faster from a lighter one, while genuine reasoning work earns the slower, stronger model. Matching the model to the task removes latency you're inflicting on yourself. It won't rescue a bad route, though, so think of it as cleanup, not a cure.
What's actually eating your response time
| Factor | What it looks like | Where it lives | What helps |
|---|---|---|---|
| Context accumulation | Gets slower the longer one session runs | Your session | Compact early, start fresh sessions for new work |
| Per-call latency | Slow from the first command, and every command after | The network route | A shorter, faster path to the API |
| Jitter and packet loss | Random freezes and stalls in the middle of a task | The network route | A stable, low-loss route |
| Model choice | A heavy model doing trivial work | Your config | Match the model to the size of the task |
Two of those four rows are session and config problems you fix yourself. The other two are about the path your requests take, and that's the half a tuned route actually moves the needle on.
Questions people actually ask
Why is Claude Code slow even on a fast laptop?
Because most of the wait is network and reasoning time, not local compute. Your CPU runs the tools quickly, sure. It can't shorten the round trip to the API, and it can't speed up the model's thinking on a large context.
Does compacting context really help?
For the session-length kind of slowness, yes. Less context means less to chew on per reply. It does nothing for a slow route, which is exactly why some people compact, see no change, and assume the tool is just like that.
Wired or Wi-Fi?
Wired, usually. It tends to have lower jitter and fewer dropped packets than congested Wi-Fi, and as covered above, interactive coding lives and dies on those spikes.
What does a better route actually change?
It trims the per-call latency and smooths the jitter, so each of the many round trips in an agent run comes back faster and more predictably. On a multi-step task, that adds up to a lot.
So the way out isn't to guess. Split the problem first. Confirm whether the lag scales with your session or shows up from the first keystroke, then handle the session half with basic hygiene and the network half with a route built for sustained, low-latency traffic. The second half is where NasaCode fits, with developer-tuned nodes that keep each round trip short and steady, so the per-call tax that compacting can never touch finally stops adding up.
