Performance Optimization

You are working on a monorepo with 400,000 lines across 12 packages. Cursor takes 30 seconds to start suggesting completions. Agent mode pauses for 10 seconds before it starts exploring files. The indexing indicator has been spinning for the past hour. You start to wonder if Cursor just does not work for large projects.

It does. But large projects require tuning. Out of the box, Cursor indexes everything, loads every extension, and uses default memory limits designed for small projects. A few targeted changes make the difference between a sluggish experience and instant responses.

What You’ll Walk Away With

• A .cursorignore configuration that eliminates indexing noise
• Memory and performance settings tuned for large codebases
• Extension audit techniques to identify and disable resource-heavy extensions
• Strategies for reducing context overhead without losing AI quality

Fix Indexing First

Indexing is usually the primary performance bottleneck. Cursor’s semantic search indexes every file it can see. In a project with 50,000 files (including node_modules, build outputs, and generated code), most of the index is noise.

The .cursorignore File

Create a .cursorignore file at the root of your project. This works like .gitignore but specifically controls what Cursor indexes and searches:

Tip

Copy-paste .cursorignore for JavaScript/TypeScript projects:

# Build artifacts
dist/
build/
.next/
out/
.nuxt/
.output/

# Dependencies (indexed separately by Cursor)
node_modules/

# Generated code
__generated__/
*.generated.ts
*.d.ts.map
*.js.map
coverage/

# Large assets
*.min.js
*.min.css
*.bundle.js
public/assets/
static/media/

# Package manager
.pnpm-store/
.yarn/

# IDE and OS
.git/
.DS_Store
*.log

For Python projects, also exclude:

.venv/
venv/
__pycache__/
*.pyc
.mypy_cache/
.pytest_cache/
htmlcov/
*.egg-info/

Verify Indexing Status

Check the indexing indicator in Cursor’s bottom status bar. If it shows a large number of files being indexed, your .cursorignore is not aggressive enough. After updating the ignore file, reindex by opening the command palette (Cmd/Ctrl+Shift+P) and running “Reindex Codebase.”

Optimize Extension Load

Extensions are the second-largest performance drain. Every VS Code extension you have installed runs inside Cursor and competes for memory and CPU.

Audit Your Extensions

1. Open the Extensions panel (Cmd/Ctrl+Shift+X)
2. Sort by “Installed”
3. For each extension, ask: “Do I use this weekly?”
4. Disable extensions you do not actively use
5. Pay special attention to extensions that run language servers (Python, Java, C++)

High-Impact Extensions to Review

These categories of extensions commonly consume significant resources:

• Language servers for languages you are not using — If you are in a TypeScript project, disable Java, Python, and C++ extensions
• Linting extensions that duplicate Cursor’s built-in capabilities
• Git visualization extensions with real-time file watching
• Code formatting extensions that run on every save

Caution

Do not disable the TypeScript language server or ESLint if your project uses them. These provide critical information that Cursor uses for Tab completion and error detection. Only disable language servers for languages not present in your current project.

Workspace-Specific Extension Profiles

Use Cursor’s workspace settings to enable extensions only where needed:

{
  "extensions.autoUpdate": false,
  "extensions.ignoreRecommendations": true
}

You can also disable specific extensions per workspace using the Extensions panel’s workspace toggle.

Memory and Editor Settings

Increase Memory Allocation

For large projects, Cursor may need more memory than the default allocation. Add these to your settings.json:

{
  "files.maxMemoryForLargeFilesMB": 4096,
  "search.maxResults": 20000,
  "editor.maxTokenizationLineLength": 20000
}

Reduce File Watcher Load

In large projects, file system watchers consume significant resources:

{
  "files.watcherExclude": {
    "**/node_modules/**": true,
    "**/dist/**": true,
    "**/build/**": true,
    "**/.git/objects/**": true,
    "**/.git/subtree-cache/**": true,
    "**/coverage/**": true
  }
}

Search Optimization

Exclude the same directories from VS Code’s built-in search:

{
  "search.exclude": {
    "**/node_modules": true,
    "**/dist": true,
    "**/build": true,
    "**/coverage": true,
    "**/*.min.js": true,
    "**/*.map": true
  }
}

Tab Completion Performance

If Tab completion feels slow, these settings help:

{
  "editor.quickSuggestions": {
    "other": true,
    "comments": false,
    "strings": true
  },
  "editor.suggestOnTriggerCharacters": true,
  "editor.acceptSuggestionOnCommitCharacter": false
}

Worktree Performance

If you use parallel agents with worktrees, optimize the initialization:

{
  "setup-worktree": [
    "pnpm install --frozen-lockfile",
    "cp $ROOT_WORKTREE_PATH/.env .env"
  ]
}

Use pnpm or bun instead of npm install — they are significantly faster for worktree initialization because they can reuse the global package cache.

Configure cleanup to prevent disk bloat:

{
  "cursor.worktreeCleanupIntervalHours": 6,
  "cursor.worktreeMaxCount": 10
}

Tip

Copy-paste prompt for identifying performance bottlenecks:

Use Ask mode:

Analyze this project's structure and tell me:
1. How many files are in each top-level directory (approximate count)
2. Which directories contain generated or build output that should be in .cursorignore
3. Which directories have the most files that are unlikely to need AI indexing
4. Are there any unusually large files (over 5000 lines) that might slow down context loading

I want to optimize Cursor's performance for this project.

When This Breaks

Indexing still slow after .cursorignore changes. Reindex explicitly via the command palette. The ignore file changes may not take effect until the next full reindex.

Tab completion disappears entirely. Check that you have not disabled the TypeScript language server. Also verify that your project has a valid tsconfig.json — Tab completion relies on the TypeScript language service.

Agent responses are slow but indexing is fine. The bottleneck may be network latency to the AI model, not local performance. Try a different model (Claude Sonnet 4.5 is faster than Claude Opus 4.6) or check your internet connection.

Worktrees eat disk space. Reduce cursor.worktreeMaxCount and cursor.worktreeCleanupIntervalHours in settings. Run git worktree list to see all active worktrees and git worktree prune to clean up stale ones.

What’s Next

• Large Codebase Strategies — Performance is foundational for large project workflows
• Token Management — Reducing context overhead also improves response speed
• Custom Rules and Templates — Well-scoped rules reduce the agent’s search space