Why Is Cursor Slow? Fixing Slow Requests

Slowness comes from what each request carries, not from a hidden penalty tier. The heavier the model and the more tokens it has to read, the longer every turn takes. Four causes cover almost every case:

• You use a large thinking modelA reasoning model (shown with a brain icon in Cursor's picker) that spends extra compute before answering; reach for it on complex, nuanced work and a standard model for fast, simple tasks. Press Enter for the full definition. for everything. Bigger models that reason more deeply are slower per turn.
• The context is bloated, with many open tabs or whole-repo prompts, so each request is heavier.
• A long thread is near its context window. Past about 70% usage, responses get slower and weaker, because every turn carries more history. Near the limit, Cursor also compresses older parts of the conversation.
• The model provider is under heavy load for a while, for example at peak demand.

Three of the four are yours to change. Model choice and context scope are settings, and a long thread is a habit you can break. Provider load is not, so work out which cause you have before you spend an afternoon tuning. If a colleague on the same repo and the same model sees the same lag right now, stop tuning and try again later.

People report both as slow requests, but they have different fixes. Typing lag, or a window that stalls while nothing is generating, points at the editor. A response that takes a long time to arrive points at what the request carries.

For a slow editor, Cursor's performance help points at extensions and settings, not at models or context. Launch with cursor --disable-extensions to see whether the slowdown survives. If Cursor is using too many resources, the same page says to add large generated folders like dist/, build/ and .next/ to .cursorignore. Cursor already respects .gitignore, which is where node_modules should be. The troubleshooting guide has the rest of that sequence.

If the editor responds but the first token is slow, run one network check. Open Cursor Settings > Network and choose Run Diagnostics. When a proxy blocks HTTP/2, the documented fix is to set HTTP Compatibility Mode to HTTP/1.1 and restart. This is not the first thing to check, but it fits the case where every model feels equally slow.

Lighten each request, starting with the two changes that cost nothing: model choice and context scope.

1. 1Use a faster model for routine edits, such as Auto or Composer 2.5The current Composer release, better at long-running tasks and at judging when a job needs a light touch versus deep work. Press Enter for the full definition., instead of a large thinking modelA reasoning model (shown with a brain icon in Cursor's picker) that spends extra compute before answering; reach for it on complex, nuanced work and a standard model for fast, simple tasks. Press Enter for the full definition.. Save the heaviest models for hard problems.
2. 2Scope the context: close tabs you don't need and @-mention only the files in play.
3. 3Start a fresh chat when a long thread turns sluggish. A long history costs time and quality on every turn.
4. 4Check your remaining usage in Cursor's settings, or on the usage dashboard at cursor.com/dashboard if you are on a legacy plan. If you've hit the limit, Cursor shows a notification instead of slowing down, and you choose how to continue.

The order follows what each step costs you. Switching the model is a dropdown: it applies to the next turn, and switching back undoes it. Scoping the context costs a minute of closing tabs. A fresh chat costs you the thread you were working in, which is why it comes third. The usage check comes last because it answers a different question: whether anything you do in the editor was ever going to help.

A fresh chat is the most reliable of the four steps, so it is tempting to lead with it. It also throws away the thread you were trying to rescue. If the real cause was a large thinking modelA reasoning model (shown with a brain icon in Cursor's picker) that spends extra compute before answering; reach for it on complex, nuanced work and a standard model for fast, simple tasks. Press Enter for the full definition. doing a two-line edit, you lose the thread and learn nothing.

So change the model first, send one more turn, and reset only if that turn is still slow.

The advice to attach fewer files needs a qualifier. Fewer files do make each request lighter, but Cursor's guidance on @-mentions is to skip them when you are unsure which files matter, because the agent searches for relevant files itself. If you are guessing, the tokens go on files the agent was going to look for anyway.

Yes, but you pay for the speed. Cursor lists the Fast variants as separate line items: Composer 2.5The current Composer release, better at long-running tasks and at judging when a job needs a light touch versus deep work. Press Enter for the full definition. costs $0.5 per million input tokens and $2.5 for output, and Composer 2.5 (Fast) costs $3 and $15. Grok 4.5 goes from $2 and $6 to $4 and $18.

The sixfold jump on ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. Press Enter for the full definition. buys the same model on faster hardware. The Cursor engineer quoted on our Max Mode page is blunt about it: speed costs more and does not make the model any smarter. For a routine edit that is a poor trade. For the one turn that is blocking you, it can be worth the premium.

Hopping between models has a cost of its own. Switching models mid-thread breaks the cache, so a session that hops between a thinking modelA reasoning model (shown with a brain icon in Cursor's picker) that spends extra compute before answering; reach for it on complex, nuanced work and a standard model for fast, simple tasks. Press Enter for the full definition. and a fast one drops the cached context at every switch and pays full input rates to rebuild it. Where you can, choose the model at the start of a task and keep it.