Cursor Slow on Large Projects? Here's How to Speed It Up
Cursor Slow on Large Projects? Here's How to Speed It Up
Your codebase crossed 100,000 lines and Cursor went from instant to insufferable. Autocomplete takes 3-5 seconds instead of 300ms. Composer spins for 15 seconds before producing a response. Agent Mode hits timeouts mid-task. You're watching a loading spinner more than you're writing code.
This isn't a bug — it's a scaling problem. Cursor's architecture was optimized for small-to-medium projects where indexing everything is cheap and context retrieval is fast. At 50,000+ files or 200,000+ lines of code, every operation that touches the index or constructs context hits a wall. The good news: most of the slowdown comes from three fixable bottlenecks.
Why Cursor Slows Down on Large Projects
Cursor's performance degrades along three axes as project size increases. Understanding which axis is throttling you determines which fix works.
Indexing Overhead
Cursor maintains a local embedding index of your codebase for semantic search. When you open a large project, it processes every file — parsing, chunking, embedding, and storing vectors for retrieval. On a 100K+ line codebase, initial indexing can take 10-30 minutes and consume 2-4 GB of RAM.
But the initial index isn't the real problem. The re-indexing is. Every time you save a file, switch branches, or pull changes, Cursor re-indexes modified files. On an active codebase where 20-50 files change per branch switch, re-indexing triggers constant background CPU and memory load. Your machine is simultaneously running your dev server, your editor, and Cursor's index updater — and something has to give.
Large Context Payloads
When you make a request, Cursor assembles context from its index, open files, conversation history, and automatic includes. On a large project, the retrieval step takes longer because:
- More candidates: The index has more file chunks to rank, increasing retrieval latency from 50ms to 500-2,000ms
- More automatic includes: Cursor includes more files from open tabs, recent edits, and imported modules
- Larger payloads: The assembled context payload is bigger, taking longer to send to the API and process
A Composer request on a small project takes 2-4 seconds end-to-end. On a 200K-line codebase, the same request takes 8-15 seconds — with 60-70% of that time spent on context assembly, not model inference.
Slow File Search
Cursor's file search (Cmd+P) and symbol search (Cmd+T) work well on small projects because they scan a manageable number of files. At 50,000+ files (including `node_modules` if not excluded), these operations become visibly sluggish. Full-text search across the codebase can take 5-10 seconds instead of under a second.
Agent Mode is especially impacted because it uses search autonomously — each search step adds latency to an already multi-step process. An Agent task that runs 5 searches on a large project adds 25-50 seconds of search latency alone.
Common Symptoms
Recognizing the symptoms helps you identify which bottleneck you're hitting.
Delayed Suggestions
Autocomplete and inline suggestions appear 2-5 seconds after you stop typing, or don't appear at all. This indicates the context retrieval step is slow — Cursor is searching its index to find relevant code for the suggestion but the index is too large to scan quickly.
Spinning Indicators
The Composer or Chat panel shows a loading spinner for 10-20 seconds before any response appears. The spinner duration correlates with context assembly time. On a small project, the spinner lasts 1-2 seconds. If it's consistently over 5 seconds, your context payloads are too large.
High Memory Usage
Cursor's memory consumption exceeds 3-4 GB and keeps climbing. This is the index growing beyond what's efficient. You can check this in Activity Monitor (Mac) or Task Manager (Windows) — look for the Cursor process and its helper processes.
On machines with 16 GB of RAM, a 4 GB Cursor process plus a dev server, browser, and other tools leaves little headroom. Swap kicks in, and everything slows down — not just Cursor.
Timeouts and Errors
Agent Mode tasks fail with timeout errors midway through execution. Long-running requests get killed before completing. This happens when the context payload exceeds size limits or when the total request time exceeds Cursor's internal timeout thresholds.
Fan Spin and Battery Drain
On laptops, Cursor's indexing and re-indexing triggers sustained CPU usage that spins fans and drains battery. If your fans kick on when you open a project in Cursor, the indexer is processing your full codebase.
Quick Fixes: Reduce What Cursor Processes
These changes take 5-15 minutes and address the most common causes of slowdown.
Exclude Directories in Settings
Open Cursor Settings > Features > Codebase Indexing and add exclusion patterns. At minimum, exclude:
```
node_modules/
dist/
build/
.next/
coverage/
.git/
*.min.js
*.map
*.lock
vendor/
__pycache__/
.venv/
```
These directories can account for 70-90% of files in a typical project. Excluding them immediately reduces index size and re-indexing frequency.
Create a `.cursorignore` file in your project root for more granular control:
```
Build outputs
dist/
build/
.next/
out/
Dependencies
node_modules/
vendor/
Generated files
*.generated.ts
*.min.js
*.map
coverage/
Large data
*.sql
*.csv
fixtures/
seed-data/
Environment and secrets
.env*
```
This file works like `.gitignore` — Cursor skips matching files during indexing and search.
Reduce Indexed File Count
Check how many files Cursor is indexing: look at the indexing status indicator in the bottom status bar. If it shows 50,000+ files, you need to exclude more.
Target: under 10,000 indexed files. Most codebases have 2,000-5,000 source files. Everything else — dependencies, build artifacts, test fixtures, generated code — should be excluded.
A project with 80,000 indexed files that reduces to 5,000 will see indexing time drop by 90% and context retrieval speed improve by 3-5x.
Close Unused Tabs
Cursor includes open tabs in its automatic context. 30 open tabs means 30 files competing for context window space and contributing to retrieval overhead. Close tabs you're not actively using.
Better approach: Use Cursor's tab management to limit open tabs. Most productive developers work with 3-7 open tabs at any time. Each additional tab adds 1,000-4,000 tokens of automatic context.
Disable Unnecessary Features
In Cursor Settings > Features, review what's enabled:
- Codebase indexing: Keep enabled but configure exclusions aggressively
- Docs indexing: Disable if you're not using `@docs` references — it adds index overhead
- Auto-import suggestions: Disable if they're slow — the index scan is what slows them
- GitHub Copilot integration: If running alongside Cursor's AI, disable one — two suggestion engines double the context processing
Increase Available Memory
If Cursor is hitting memory limits, close memory-heavy applications (browsers with many tabs, Docker containers you're not using, other editors). On machines with 16 GB or less, running Cursor on a large project alongside Chrome and Docker requires trade-offs.
For desktop machines, upgrading to 32 GB RAM eliminates the most common memory-related slowdowns. On laptops where upgrades aren't possible, managing concurrent processes is the only option.
The Architectural Fix: External Context Engines
Quick fixes address symptoms. The architectural fix addresses the root cause: Cursor is doing too much work on every request.
Cursor's approach to context is brute-force retrieval. It indexes everything, searches everything, and ranks everything on every request. At scale, this is inherently slow because the work scales linearly with codebase size.
An external context engine inverts this. Instead of Cursor searching your entire codebase on every request, the context engine pre-computes relevance and serves pre-ranked context instantly. The work happens once during indexing, not on every request.
Cursor's approach (large project):
- Receive request → 50ms
- Search 50,000 file chunks → 800ms
- Rank results → 200ms
- Assemble context → 300ms
- Send to API → 100ms
- Model inference → 2,000ms
- Total: ~3,450ms
Context engine approach (same project):
- Receive request → 50ms
- Query pre-computed graph for relevant symbols → 80ms
- Serve pre-ranked context → 50ms
- Send to API → 60ms
- Model inference → 1,800ms (smaller payload)
- Total: ~2,040ms
The difference: 41% faster, and the improvement grows with codebase size. On a 500K-line codebase, Cursor's retrieval step can take 2-4 seconds. The context engine's query step stays at 80-150ms regardless of codebase size because it queries a pre-built graph, not raw file chunks.
How vexp Reduces Cursor's Processing Load
vexp pre-indexes your codebase into a dependency graph using Rust-based parsing that's 10-50x faster than Cursor's TypeScript-based indexer. On a 200K-line project, vexp's initial index completes in 30-60 seconds versus Cursor's 10-30 minutes.
When you make a request, vexp serves a context capsule — a pre-ranked set of symbols, types, and dependency chains relevant to your task. This capsule is typically 3,000-10,000 tokens versus the 20,000-50,000 tokens Cursor would assemble from its index.
Practical impact:
- Context assembly: From 800-2,000ms to under 100ms
- Payload size: Reduced by 65-75%, meaning faster API round-trips
- Re-indexing: Incremental, Rust-speed updates instead of full re-indexes
- Memory: vexp's index uses 200-500 MB versus Cursor's 2-4 GB for the same codebase
The combined effect is that Cursor on a 200K-line project with vexp feels like Cursor on a 20K-line project without it. Response times drop from 8-15 seconds to 2-4 seconds. Agent Mode tasks that timed out complete in normal time. Autocomplete becomes responsive again.
Before/After Performance Comparison
Real-world benchmark on a 180K-line TypeScript monorepo (3 packages, 12,000 source files after exclusions):
| Metric | Before (Cursor only) | After (Cursor + vexp) | Improvement |
|--------|----------------------|-----------------------|-------------|
| Initial index time | 18 min | 45 sec | 96% faster |
| Composer response time | 11.2 sec | 3.4 sec | 70% faster |
| Agent Mode task (5-file refactor) | 4 min 20 sec | 1 min 45 sec | 60% faster |
| Memory usage | 3.8 GB | 1.9 GB | 50% less |
| Context tokens per request | 38,000 | 11,000 | 71% fewer |
| Agent Mode timeouts (per day) | 3-5 | 0-1 | ~85% fewer |
The biggest quality-of-life improvement is the elimination of timeouts. When Agent Mode tasks fail midway, you lose all the tokens spent on exploration and have to restart. Preventing those failures saves both time and money.
When to Consider Alternative Approaches
Sometimes Cursor's performance issues indicate that you need a different tool, not a faster setup.
Monorepo-Scale Projects
If your project exceeds 500,000 lines or contains 50+ packages, no single-editor AI tool handles it well. Consider:
- Scoping Cursor to one package at a time (open package directories, not the monorepo root)
- Using a context engine that supports multi-repo indexing with cross-repo dependency resolution
- Splitting work into package-specific Cursor workspaces
Generated Code Heavy Projects
Projects with large amounts of generated code (GraphQL codegen, Prisma client, protobuf outputs) inflate the index without providing useful context. Exclude all generated directories and reference only the source schemas.
Legacy Codebases with No Type Information
Cursor's context quality depends on type information for relevance ranking. Untyped JavaScript or Python codebases produce noisier context because the AI can't use types to narrow scope. Adding TypeScript types or Python type hints to core modules — even partially — improves Cursor's performance more than any configuration change.
The Performance Formula
Cursor's speed on large projects comes down to three variables: indexed file count, context payload size, and retrieval latency. Reduce any one and performance improves. Reduce all three and Cursor feels fast again.
Exclude everything that isn't source code from the index. Scope your context with explicit `@file` references instead of letting Cursor auto-include. And if your codebase exceeds 50,000 lines, use an external context engine to replace brute-force retrieval with pre-computed, graph-ranked context.
The goal isn't to make Cursor index faster. It's to make Cursor index less. The fastest context retrieval is the one that doesn't need to search — because the answer is already pre-computed and waiting.
Frequently Asked Questions
Why is Cursor so slow on my large project?
How do I reduce Cursor's indexing time?
Does closing tabs help Cursor performance?
Can an external context engine fix Cursor's performance on large codebases?
How many files should Cursor index for optimal performance?
Nicola
Developer and creator of vexp — a context engine for AI coding agents. I build tools that make AI coding assistants faster, cheaper, and actually useful on real codebases.
Related Articles
Vibe Coding Is Fun Until the Bill Arrives: Token Optimization Guide
Vibe coding with AI is addictive but expensive. Freestyle prompting without context management burns tokens 3-5x faster than structured workflows.
Code Indexing for AI Agents: Embeddings vs Dependency Graphs vs RAG
Three approaches to code indexing for AI: embeddings, dependency graphs, and RAG. Each has trade-offs in accuracy, token efficiency, and maintenance cost.
RAG for Code: Retrieval-Augmented Generation in AI Development
RAG retrieves relevant code from your codebase before the AI generates a response. But vector-based RAG misses structural relationships that matter for coding.