If Cursor's memory footprint keeps climbing the longer you work, and quitting and reopening it only provides temporary relief, you're seeing a pattern other users have reported directly to Cursor's own team.
Why Cursor uses more memory than a plain code editor
Cursor is built on the same open-source foundation as VS Code, which already has its own multi-process memory profile (the main editor process plus a separate process per extension). Cursor adds AI-specific functionality on top: indexing your codebase for context-aware suggestions, maintaining conversation history with the AI assistant, and running background analysis to power its autocomplete and chat features. Each of these adds its own memory overhead beyond what a standard editor needs, and on a large codebase, the indexing step in particular can be memory-intensive.
How bad do the reports get?
Threads on Cursor's own community forum describe memory climbing to 40GB and beyond during extended sessions, with one report specifically citing the "your system has run out of application memory" macOS alert, and a separate thread describing a 7GB+ leak that made the app unusable with constant crashes. These aren't isolated one-off complaints; they're the kind of repeated, specific pattern that indicates a real underlying issue with how the app manages memory over long sessions rather than normal, expected usage.
What genuinely helps
Restart Cursor periodically during long sessions. Rather than leaving one Cursor window open for an entire working day, closing and reopening it every few hours resets whatever has accumulated. This is a workaround, not a fix, but it's the most reliable one reported by users dealing with this.
Use "Reload Window" instead of a full quit when possible. Cursor, like VS Code, has a command palette action to reload the window without fully quitting the app. This clears a meaningful amount of accumulated state faster than switching between files repeatedly, though a full quit-and-reopen clears more.
Limit the number of open windows and large files. Each Cursor window maintains its own indexing and context state. If you regularly work across several large projects simultaneously, closing windows for projects you're not actively using reduces the total memory Cursor is responsible for at any one time.
Check your extensions. As with VS Code, third-party extensions run in their own processes and can be a significant, easily overlooked contributor to overall memory use. Disabling extensions you rarely use is a quick way to reduce Cursor's baseline footprint.
Keep Cursor updated. Memory-management issues like this are exactly the kind of thing an actively developed app iterates on across releases. If you're several versions behind, updating is worth trying before more involved workarounds.
How this compares to plain VS Code
If you've used VS Code before switching to Cursor and noticed memory use is meaningfully higher, that tracks: you're running everything VS Code does, plus Cursor's AI indexing and assistant features on top. For a comparison point, see the VS Code memory guide, which covers the baseline editor's own memory profile before any AI-specific overhead is added.
Where a memory-relief tool fits in
Restarting Cursor clears what Cursor itself has accumulated, but it doesn't address memory that other apps, or Cursor's own now-orphaned helper processes from a previous session, are still holding onto in the background. Shiny frees exactly that kind of leftover memory in one click from the menu bar, which is a useful complement between Cursor restarts rather than a replacement for them: it won't stop Cursor's own memory from climbing during a session, but it clears the wider clutter around it, giving you more headroom before you need to restart Cursor again.
For developers running multiple tools alongside Cursor, the Xcode memory guide and the Docker Desktop memory guide cover similar ground for other parts of a typical development setup.
Large codebases make it worse
The size of the project you have open matters more with Cursor than with a plain text editor, because the AI indexing feature scans your codebase to build the context it uses for suggestions and chat responses. On a small project this is barely noticeable. On a large monorepo with hundreds of thousands of lines across many files, the initial indexing pass and the ongoing incremental updates as you edit both carry a real memory cost that scales with project size. If you've noticed memory climbs faster on one project than another, checking whether the heavier project is simply larger is a reasonable first diagnostic step, and it explains why two developers on the same Cursor version can report very different experiences.
What to report if you're hitting this regularly
Because Cursor is an actively developed product with its own support channels, if you're seeing this consistently enough to affect your daily work, reporting it with specifics (approximate memory figures from Activity Monitor, how long into a session it appears, and your project size) through Cursor's own community forum or support channel gives the team something concrete to investigate, and adds to the existing body of reports that make a fix more likely to be prioritised.