Fix
Why Is Cursor Slow? Fixing Slow Requests
Cursor slows down when a request carries a large thinking model plus too much context, or when a long thread nears its context window. Running out of included usage is not a slowdown on current token-metered plans: Cursor notifies you and you enable on-demand usage or upgrade. Requests are never downgraded in speed. Fix slowness by scoping context and picking a faster model for routine work.
On this page
Why is Cursor so slow?
Slowness traces to what each request carries, not to 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're using 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, deeper-reasoning models are slower per turn.
- Bloated context (many open tabs / whole-repo prompts) makes each request heavier.
- A long thread near its context window: past ~70% usage, responses get slower and weaker as history is compressed each turn.
- Transient provider/peak-demand load.
Three of those four are yours to change and the fourth is not. Sort out which one you have before you spend an afternoon tuning. Model choice and context scope are settings, and a long thread is a habit you can break. Transient load at the provider is none of those, so if a colleague on the same repo and the same model is watching the same lag right now, stop tuning and come back to it later.
Earlier Cursor plans dropped you into a slower request pool once the monthly allowance ran out, which is where most 'slow requests' advice comes from. Current plans are token-metered and work differently: Cursor's pricing docs state that requests are "never downgraded in quality or speed". When included usage runs out, you get a notification in the editor and choose between on-demand usage (pay-as-you-go at API rates, cappable with a spend limit) and a plan upgrade.
This is covered hands-on in Troubleshooting and Operating Cursor Reliably — 7 short modules, free to read.
Is it Cursor that's slow, or the model?
Those are two different problems with two different fixes. Typing lag and a window that stalls while nothing is generating point at the editor, while a response that takes a long time to arrive points at what the request is carrying.
Everything above is about the turn. When the editor itself feels heavy, Cursor's own troubleshooting points at extensions and at indexing rather than at models or context. Launch with cursor --disable-extensions to see whether the slowdown survives, then add generated folders like dist/, build/ and .next/ to .cursorignore so the indexer skips them. Cursor respects .gitignore when it indexes, which is where node_modules should already be. The troubleshooting guide has the rest of that sequence.
A slow first token with an otherwise responsive editor is worth one network check. Cursor Settings has a Network section with Run Diagnostics, and the documented fix when a proxy blocks HTTP/2 is to switch HTTP Compatibility Mode to HTTP/1.1 and restart. It is not where I would start, though it does explain the case where every model feels equally slow.
Both of those get reported as slow requests.
How do I fix Cursor slow requests?
You can speed Cursor back up by lightening each request. Start with the changes that cost nothing (model choice and context scope), then check the dashboard to rule out a usage limit masquerading as slowness.
- 1Use a faster model for routine edits (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. rather than 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.
- 2Scope context by closing irrelevant tabs and @-mentioning only the files in play.
- 3Start a fresh chat when a long thread turns sluggish; compressing stale history costs time and quality on every turn.
- 4Check Dashboard → Usage at cursor.com/dashboard. If you've hit the included-usage limit, Cursor stops with a notification rather than slowing down. Enable on-demand usage or upgrade to continue.
The order is the order because of what each step costs you. Switching model is a dropdown, it applies to the next turn, and switching back undoes it. Scoping context costs a minute of closing tabs. Starting a fresh chat costs you the thread you were working in, which is why it sits third rather than first. The dashboard check is last because it answers a different question: whether anything you do in the editor was ever going to help.
I had the fresh-chat step higher up for a while. It is the most reliable of the four, and leading with it is tempting.
What moved it down is that it throws away the thread you were trying to rescue, and 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 spent the thread to learn nothing. Change the model, send one more turn, and reset only if that turn is still slow.
The advice to attach fewer files does not fully carry over here. It does make each request lighter, and yet Cursor's guidance on @-mentions is to skip them when you are unsure which files matter, because the agent searches for relevant files itself. When you are guessing, the tokens go on files the agent was going to look for anyway.
Does paying for a Fast model make Cursor faster?
It buys throughput, and it is priced like it.
Cursor lists the Fast tiers 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. is $0.5 per million input tokens and $2.5 output; Composer 2.5 (Fast) is $3 and $15. Grok 4.5 goes from $2 and $6 to $4 and $18.
What 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 is the same model on faster hardware, which the Cursor engineer quoted on our Max Mode page is blunt about: speed costs more and does not make the model any smarter. For a routine edit that is a poor trade. For the one turn you are genuinely blocked on, it can be worth the premium.
There is a cheaper lever next to that one. Switching models mid-thread breaks the cache, so a session spent hopping 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 hop and pays full input rates to rebuild it. Decide on the model at the start of a task where you can.
Frequently asked questions
Why did Cursor get slow after a while?
Almost always a long thread: as the context window fills, every turn carries more history, so responses slow down and degrade. Start a fresh chat. Hitting your included-usage limit does not throttle current token-metered plans. It surfaces a notification, and you choose between on-demand usage and an upgrade.
Does a faster model fix slow Cursor requests?
Often, yes. Auto and Composer 2.5 respond quicker for routine edits; save the largest thinking models for genuinely hard tasks.
Sources & last verified
Cursor ships frequently. Last updated July 28, 2026.