Memory usage and performance from 3.16.x

Support Bug Reports
1

Starting on version 3.16, working in multiple projects at once on a i9 with 64GB of RAM, the system memory keeps going up until the system becomes unusable and i need to restart. Cursor memory itself is not so big (3-4Gb) but it’s the only things that has changed lately. Also, everything inside cursor is easily an order of magnitude slower

Where does the bug appear (feature/product)?

  • Editor, Tab & Chat (autocomplete, Composer, in-editor agent)
  • Terminal & commands
  • Models, pricing & API keys (availability, Auto/Max, BYOK/Bedrock)
  • MCP & tools
  • Cloud Agents & Automations (cursor.com/agents, scheduled/event)
  • BugBot & Code Review
  • Cursor CLI
  • Cursor Mobile
  • Remote (SSH / Dev Containers / WSL)
  • Account, billing & login
  • Something else…

Describe the Bug
System becomes unusable, high memory pressure and slow implementation times.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. Regular use, goes down in less than 1 hour

Expected Behavior
The computer not becoming a brick

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

Version: 3.17.8 (user setup)
VS Code Extension API: 1.128.0
Commit: 2fdd31c9f33f7fbe501f2d57772dc5bf64b63620
Date: 2026-08-20T02:18:12.724Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.26200

Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue
2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Editor, Tab & Chat (autocomplete, Composer, in-editor agent)
  • Terminal & commands
  • Models, pricing & API keys (availability, Auto/Max, BYOK/Bedrock)
  • MCP & tools
  • Cloud Agents & Automations (cursor.com/agents, scheduled/event)
  • BugBot & Code Review
  • Cursor CLI
  • Cursor Mobile
  • Remote (SSH / Dev Containers / WSL)
  • Account, billing & login
  • Something else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

8

Hey @Angel_Andres,

This isn’t something in your setup - when several projects run agents at once, memory piles up across Cursor’s helper and agent subprocesses (plus each window’s extension hosts), which is why system memory climbs even though the main Cursor process stays at 3-4 GB. There’s no cross-window throttling for that yet. It’s an issue we’re tracking.

To keep it usable:

  1. Run fewer projects/agent windows at once.
  2. Offload heavy parallel work to Cloud Agents — they run off your machine.
  3. Fully quit and reopen between long sessions; reload heavy windows (Ctrl+Shift+P → Developer: Reload Window).

Next time it’s slow, could you grab a screenshot of Windows Task Manager sorted by memory (or Ctrl+Shift+P → Developer: Open Process Explorer)? That shows us exactly which processes are holding the memory.