Why is Cursor so slow?
Cursor slows down mainly from large context (big files or whole-codebase requests), heavy frontier models, high server demand, background indexing, network latency, or too many extensions. Fixes: use a lighter model or Auto, trim the context you attach, close unused tabs, and check status.cursor.com for outages.
Why — the first-principles explanation
Cursor feels slow when the AI round-trip takes too long, and that round-trip has many steps that can each add delay. Your request leaves your machine, travels to Cursor's servers, gets routed to a model provider, the model "thinks," and the answer travels back. The more work at each step, the longer you wait.
The biggest factor is usually how much context you send. Asking a frontier model to reason over a huge file or your entire codebase means it has to process far more tokens, and processing time grows with input size. A small, focused request comes back fast; a "read everything and refactor" request is slow by nature.
Model choice matters too. The most capable frontier models are slower than lighter ones or Cursor's own Composer. During peak demand, shared model capacity gets congested, adding queue time nobody can control from their laptop.
Finally, local factors pile on: background codebase indexing right after opening a project, a slow or high-latency internet connection, a VPN, or dozens of heavy extensions inherited from VS Code. Because these causes are independent, the fix is to reduce load at whichever step is the bottleneck, smaller context, lighter model, cleaner setup, or simply waiting out an outage.
An example that makes it click
Imagine ordering at a restaurant. If you order one simple dish (a focused prompt), it comes out fast. If you ask the chef to prepare a 12-course tasting menu from scratch (refactor my whole codebase), it takes forever, that's a lot of cooking. Pick a Michelin chef who perfects every plate (a heavy frontier model) and it's slower than the quick line cook (a lighter model). And on a packed Friday night (peak demand), every order waits in a longer queue. Speed up by ordering less, choosing a faster cook, or coming back when it's quiet.
How to do it
- Switch to a lighter model or Auto/Composer instead of the heaviest frontier model.
- Attach less context: point at specific files with @ rather than the whole codebase.
- Wait for background indexing to finish after opening a large project.
- Check status.cursor.com to rule out a service outage or degraded performance.
- Test your internet, and disable a VPN or throttling firewall if present.
- Disable heavy or unused VS Code extensions and close excess editor tabs.
- Restart Cursor to clear a stuck session if slowness persists.
Key facts
- Large context (big files or whole-codebase prompts) is the most common cause of slowness.
- Heavier frontier models respond slower than lighter models or Cursor's Composer.
- Peak server demand can add queue time outside the user's control.
- Background codebase indexing temporarily slows a freshly opened project.
- Network latency, VPNs, and heavy extensions add local delay.
- status.cursor.com reports outages or degraded performance in real time.
An AI-first code editor built on VS Code.
Affiliate link — we may earn a commission at no cost to you.▶ The 60-second explainer (script)
Why is Cursor so slow sometimes? It comes down to the AI round-trip, and there are several steps where delay creeps in. The biggest one is how much context you send. Ask a top model to read a huge file or your entire codebase, and it has way more to process, so it's slow by nature. A small, focused prompt comes back fast. Model choice matters too, the most powerful frontier models are slower than lighter ones or Cursor's own Composer. Then there's peak demand: when everyone's online, shared model capacity gets congested. And local stuff piles on, background indexing right after you open a project, a slow connection or VPN, and dozens of heavy extensions. So to speed things up: pick a lighter model or Auto, attach only the files you need with the at symbol, let indexing finish, and check status dot cursor dot com to rule out an outage. Reduce the load at the bottleneck, and Cursor gets snappy again.
What authoritative sources say
People also ask
Does a bigger codebase make Cursor slower?
It can, especially during initial indexing and when you ask the AI to reason over many files at once.
Which model is fastest in Cursor?
Lighter first-party models like Composer and the autocomplete model are faster than heavy frontier models.
Is the slowness on my end or Cursor's?
Check status.cursor.com. If it's green, look at your network, VPN, extensions, and the context size you're sending.
Will more RAM fix Cursor being slow?
It helps the editor, but AI slowness is usually about model choice, context size, and network, not local memory.