Severe System-Wide Performance Degradation When 5+ Cursor Projects Run AI Models Concurrently

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When running approximately five or more Cursor projects/windows simultaneously, with each project actively using Cursor’s AI functionality—particularly Grok and Composer—Cursor can cause severe system-wide performance degradation.

Steps to Reproduce

  1. Launch Cursor on Windows.
  2. Open at least five separate projects/workspaces, preferably in separate Cursor windows.
  3. Configure/use Cursor’s AI functionality in each project.
  4. Use a mixture of Grok and Composer workloads.
  5. Start AI/agent operations across several or all projects within roughly the same period.
  6. Allow the agents to continue working concurrently.
  7. Attempt to use Cursor or other Windows applications while these operations are running.
  8. Observe significant system-wide responsiveness degradation.

Expected Behavior

Cursor should implement sufficient resource management, workload scheduling, concurrency limits, or backpressure so that multiple active AI projects cannot consume enough local resources to severely degrade the entire operating system.

For example, Cursor could dynamically throttle background agents or other expensive operations when CPU, RAM, disk I/O, or other system resources approach critical utilization.

Background projects should ideally receive lower priority than the Cursor window with which the user is actively interacting.

Operating System

Windows 10/11

Version Information

Latest version (3.16)

For AI issues: which model did you use?

Cursor Grok 4.5/4.6

For AI issues: add Request ID with privacy disabled

N/A

Additional Information

This does not permanently crash the computer, and the system generally recovers. However, during periods of high concurrent Cursor activity, system responsiveness can deteriorate enough that normal computer usage becomes temporarily impractical.

Additional Technical Information:

The problem seems related specifically to concurrent workloads rather than one individual project.

It may be worth investigating:

  • CPU utilization across Cursor processes
  • RAM consumption per project/window
  • Disk I/O generated by simultaneous agents
  • Number of spawned Cursor/extension-host processes
  • Indexing occurring simultaneously across workspaces
  • Concurrent filesystem scanning
  • Language-server activity
  • Agent subprocess creation
  • Terminal/command execution from multiple agents
  • Context construction and repository searching
  • Resource prioritization between foreground and background Cursor windows
  • Whether concurrency/backpressure limits exist across independent Cursor windows

One potential issue is that separate Cursor windows may be independently scheduling expensive operations without sufficient global resource coordination. Five individually reasonable workloads could therefore collectively overwhelm a machine.

Does this stop you from using Cursor

Yes - Cursor is unusable
Sometimes - I can sometimes use Cursor

Hey @theworker02,

This isn’t anything wrong with your setup. Each Cursor window runs its own agents, indexing, and terminals independently, with no global coordinator across windows, so 5+ windows all driving agents at once can add up to the system-wide slowdown you’re hitting. It’s something we’ve seen before and an issue we’re tracking (including the specific ask for cross-window limits and prioritizing the window you’re actively in). No ETA to share yet.

What helps most in the meantime:

  1. Keep it to 2-3 concurrent agent sessions rather than 5+.
  2. Offload heavy parallel work to Cloud Agents; they run off your machine, so they don’t compete for CPU, RAM, or disk.
  3. Close or archive finished agent conversations instead of leaving them open across windows.
  4. Reload heavy windows during long sessions: Ctrl+Shift+P, then “Developer: Reload Window”.

If you can share a Process Explorer capture during the slowdown (Ctrl+Shift+P, then “Developer: Open Process Explorer”) showing which process type dominates, that would help us pin it down on Windows.