Cursor Slow on Big Repos? Scope, Index and Hardware Fixes

Cursor on a big repository can feel like wading through mud: ghost text lags keystrokes, agent runs stall waiting on context, and the index spinner becomes permanent furniture. Almost always the cause is scope, not hardware — thousands of generated files, dependencies and build artifacts being lovingly indexed for no benefit. This guide shows how to scope indexing to the code that matters, nurse the initial pass to completion, and keep large repos fast permanently.

Scope is the bottleneck

Big repositories are mostly not code: node_modules, dist output, vendored libraries, generated clients, binaries and caches routinely outnumber real sources ten to one. Indexing all of it burns disk, CPU and time while actively degrading result quality — the AI searches more hay for the same needles. Scoping the index to human-written sources is the single highest-leverage fix available.

Audit first: check indexed file counts and spot-check for generated paths that slipped through. Then write aggressive ignore rules covering dependencies, build output, generated code and media. The prize is routinely an order of magnitude fewer files, which translates directly into faster indexing, snappier ghosts and better agent context. No hardware upgrade competes with deleting 90 percent of pointless work.

• Generated files indexed for no benefit
• Dependencies and build output as ballast
• How to audit what gets indexed
• The order-of-magnitude prize

Nurse the initial pass

The first full index is the expensive one; everything after is incremental. Give it an uninterrupted runway: pause the heaviest AI features, avoid switching branches mid-pass, keep the machine awake, plugged in and cool. Interruptions do not merely pause indexing — they often restart chunks of it, turning a two-hour job into a two-day background ache.

For giant monorepos, schedule the initial pass overnight and verify completion in the morning rather than watching progress bars. Resist the urge to tweak scope mid-pass; each change can invalidate completed work. One clean uninterrupted run beats a week of fiddled partial passes. Patience here is not passivity — it is the fastest strategy available.

• Uninterrupted initial pass matters most
• Pause heavy features during indexing
• Branch switches restart work — avoid them
• Overnight runs for giant repos

Hardware reality checks

After scoping correctly, hardware matters at the margins: fast SSDs beat spinning disks enormously for index workloads, RAM headroom prevents swap death during big passes, and thermal throttling silently halves laptop performance during long runs. Close disk-hungry background processes during indexing days and keep the machine ventilated — boring advice that measurably shortens passes.

Recognize genuine ceilings honestly: decade-old laptops on spinning disks with giant repos will struggle regardless of settings. For those cases, cloud dev boxes with fast disks solve the problem structurally for a few dollars a month. Price that against hours of staring at spinners; the arithmetic almost always favors the cloud box. Hardware excuses expire once measured against scoped baselines.

• SSD, RAM and thermal headroom
• Background processes competing for disk
• When hardware is genuinely the ceiling
• Cloud dev boxes as an escape hatch

Rebuilds and maintenance

When behavior degrades gradually — slower ghosts, dumber suggestions, hung index jobs — the standard fix is a scoped rebuild: verify ignore rules are current, clear the index, and run one clean pass. This resolves corruption and scope rot alike, the two recurring causes of slow decay. Keep the known-good scope in version control so rebuilds are routine, not archaeology.

Audit scope quarterly as projects grow new generated directories; today's perfect ignore file rots within months. Fresh clones fix the truly mysterious cases where local state defies diagnosis — cheap to try, surprisingly effective. Document the rebuild routine where the team finds it; indexing health should not depend on one person's memory of incantations.

• Scoped rebuild as the standard fix
• Version-controlled ignore rules
• Periodic scope audits
• Fresh clone as last resort

Keep big repos fast forever

Scope first with aggressive ignore rules, nurse initial passes without interruption, rebuild routinely at the first sign of decay, and measure with stopwatches instead of feelings. Four habits that keep even monorepos snappy indefinitely. Each is simple alone; together they eliminate the entire category of indexing complaints.

Track indexed file counts and pass durations as team metrics — rising counts signal scope rot before users feel it. Review ignore rules alongside dependency updates, since new tooling constantly adds new generated paths. Teams that treat index health as maintenance never experience indexing emergencies. Teams that treat it as magic experience them quarterly.

• Scope first, hardware second
• Uninterrupted passes, always
• Rebuilds as routine maintenance
• Measure, don't feel

Frequently asked questions

How do I speed up Cursor indexing?

Indexing speed scales with files scanned, so scoping is the main lever: exclude build output, dependencies and generated code, then let the initial pass complete uninterrupted. Interruptions restart work; patience plus scope finishes fastest.

Does .cursorignore really matter?

Yes, dramatically. Excluding node_modules, dist folders, vendored code and binaries can cut indexed files by an order of magnitude. Review ignore rules quarterly — they rot as projects grow new generated directories.

What slows indexing besides project size?

Pause the heaviest AI features during the initial pass, avoid branch switches mid-index, and keep the machine awake and cool. Indexing fights for disk and CPU; giving it a clear runway beats any setting.

How do I prove scope is the problem?

Compare a scoped fresh index against the current state with a stopwatch, not feelings. If scoped indexing finishes fast, the old scope was the problem. If it still crawls, suspect hardware or a corrupted index needing a rebuild.

What if indexing degrades again later?

Keep a known-good scope configuration in version control and rebuild the index from it when behavior degrades. Index corruption and scope rot are the two recurring causes; both yield to the same rebuild routine.

Related guides

• Cursor Alternative: What It Really Costs and What Replaces It
• Cursor Free Tier Limits: What Stops and How to Keep Shipping

Last updated: 2026-09-28