"Slow" usually means one of three specific things, not a vague general complaint — and each has a real, different explanation worth knowing before assuming something is broken.
A long session accumulates everything discussed — dead ends, resolved tangents, prior file reads — and processing more context per turn takes more time, on top of crowding out what's actually relevant.
/compact to summarize and free space without losing the thread, or /clear to start fresh when old context no longer matters. See common errors, explained for the fuller version of this.A multi-file, open-ended task takes proportionally longer than a small, well-scoped one — the same way a big task takes a person longer regardless of tool. This isn't a malfunction, it's the actual size of the work.
A slow or unstable connection adds real, separate latency on top of normal processing time — easy to mistake for the tool itself being slow.
The free guide covers the permission model and a first real workflow — good habits from the start help avoid context bloat later.
Get the Free Guide →Yes, often noticeably — less context to process per turn means less latency per response, on top of the accuracy benefit of not competing with irrelevant history.
Generally yes, proportionally — more files and more back-and-forth naturally take longer, the same way a bigger task takes a person longer regardless of tool.
Yes — a slow or unstable connection adds real latency on top of processing time, and is worth ruling out before assuming the slowness is task-related.