Since the last couple of updates, Cursor has been Hypermaxxing CPU resource utilization on my machine. I have a max-specced M3 Pro Macbook, and Cursor has brought the computer to it’s knees with cpu hogging. Activity monitor shows the Cursor Renderer spiking over 100-200% of CPU utilization. It’s obvious too, because the IDE will freeze and lag, and stall when this occurs.
Steps to Reproduce
I’m running Cursor in Linux Devcontainers via Orbstack, using a Mac host machine. Simply launch a container, run an agent query, and watch the CPU usage spike over 100% and the IDE crawls to a stop / freezes for a while… then maybe recovers for a bit, then stalls / freezes again. Resource usage can be viewed in the Mac Activity monitor application. Makes it pretty difficult to use Cursor currently.
Expected Behavior
Cursor should not be freezing or stalling, especially on a powerful host machine. The renderer should not be consuming more than 100% of the CPU resources of the machine
[Extension Host] [otel.error] {"stack":"OTLPExporterError: Bad Request\n\tat IncomingMessage.<anonymous> (/root/.cursor-server/bin/3578107fdf149b00059ddad37048220e41681000/node_modules/@opentelemetry/otlp-exporter-base/build/src/transport/http-transport-utils.js:52:31)\n\tat IncomingMessage.emit (node:events:530:35)\n\tat endReadableNT (node:internal/streams/readable:1698:12)\n\tat process.processTicksAndRejections (node:internal/process/task_queues:82:21)","message":"Bad Request","code":"400","name":"OTLPExporterError","data":"{\"error\":\"Trace spans collection is not enabled for this user\"}"}
ERR [Extension Host] [otel.error] {"stack":"OTLPExporterError: Bad Request\n\tat IncomingMessage.<anonymous> (/root/.cursor-server/bin/3578107fdf149b00059ddad37048220e41681000/node_modules/@opentelemetry/otlp-exporter-base/build/src/transport/http-transport-utils.js:52:31)\n\tat IncomingMessage.emit (node:events:530:35)\n\tat endReadableNT (node:internal/streams/readable:1698:12)\n\tat process.processTicksAndRejections (node:internal/process/task_queues:82:21)","message":"Bad Request","code":"400","name":"OTLPExporterError","data":"{\"error\":\"Trace spans collection is not enabled for this user\"}"}
Extension Monitor check: CPU spikes from Cursor Helper (Renderer) can sometimes be caused by extensions. Turn on Extension Monitor (Settings > Application > Experimental > Extension Monitor Enabled), restart Cursor, reproduce the issue, then open it (CMD + Shift + P > “Developer: Open Extension Monitor”) and share a screenshot.
Process Explorer: Similarly, run CMD + Shift + P > “Developer: Open Process Explorer” during the CPU spike to see what exactly is using resources inside Cursor.
Does it happen outside devcontainers? I noticed OrbStack Helper is also using a lot of CPU (65 to 95%). It’s worth testing on a local project (not a devcontainer) to rule out the remote connection layer as the cause.
I don’t think it’s Orbstack, since the window renderer is what seems to be causing the utilization spike (and the Orbstack utilization on those spikes sometimes spikes up with it as a consequence – but not always). This issue also seems to be happening locally when not running in devcontainers as well.
The process explorer suggest it is an issue with the window renderer as well:
Thanks for the screenshots. Key observation: the extension host is basically not under load (0–4% CPU). The issue is in the window/renderer process (310% CPU, 1.5 GB RAM). That means extensions are probably not the cause, but let’s confirm to be sure:
Try launching Cursor from the terminal with cursor --disable-extensions and run an agent request. If the CPU still spikes, that confirms it’s not extensions.
What extensions do you have installed? Can you paste the output of cursor --list-extensions.
You mentioned the issue started “since the last couple of updates”. Do you remember roughly which version was fine?
One more question: how big is the project (file count)?
I’ll pass this to the team. The renderer shouldn’t behave like this when starting an agent. Let me know the result with --disable-extensions.
I think I figured it out the root cause – Since adjusting, I’ve been able to mostly avoid this issue over the last few days.
I believe the root cause has to do with using ultra-long conversations in the chat / AI Pane. I have a tendency to keep and revisit / re-use very long-running chats for context-related tasks. In some cases, these conversations can be extremely long, and have gone through many many chat summarizations and compactions over their lifetime.
What I believe is that the UI / rederer is trying to pull in as much of that chat history as possible when an ultra-long chat window is open – this is very evident if you keep scrolling up and up and up through the chat history. I believe that the renderer is struggling to load and keep so much data, that it starts consuming the full resources available on the machine in an attempt to keep up with that task.
To get around this issue, I’ve closed those ultra-long conversations, started a fresh empty context chat, closed cursor and killed the application completely – then reopen cursor and the project such that it does not automatically open any of the previous ultra-long chats, but only opens the fresh empty chat (i.e. the UI has a pretty clean slate conversationally in terms of what’s in view and loaded)
By doing this, the UI then has minimal data / context / conversational history loaded into it, keeping the renderer mostly free and lightweight to perform its task. And this prevents sluggishness and crashing of Cursor, and normal operation and usage can be resumed.
I’m quite confident this is the root cause of the issue, after much local testing.
To fix this issue, Cursor needs to do a better job of caching conversations and lazy-loading chat / previous chat history and context where possible, placing special emphasis on ultra-long conversation windows. To put less strain on the UI resources attempting to load it all. Trying not to load so much data initially in cases where there is a firehose, and just generally doing a better job of data management in the UI, will help alleviate this issue.
Great debugging, this is really helpful. You identified the root cause: very long chats overload the renderer, and that matches similar reports we’ve seen before.
To summarize the workaround for anyone hitting this issue:
Close overly long chats
Start a new empty chat
Fully quit and relaunch Cursor so it doesn’t auto-restore the old chats
Your suggestion about lazy loading and more efficient chat history caching is great feedback. I passed it to the team.
One extra note: the OTLPExporterError in your logs (“Trace spans collection is not enabled for this user”) is a separate known issue and is probably not related to the CPU spikes, but it’s still worth mentioning.
Let me know if the workaround keeps working for you going forward.
I have the same issue: since the last few updates, cursor has been taking 20+ GB of RAM and is extremely laggy. very frustrating…
Also, when opening a past chat, instead of going to the bottom of the conversation, it jumps to the very top, and I have to scroll to the bottom manually every time I switch tabs.
Also, in addition to chats making cursor super laggy, I feel like the inline diffs showing what the agent changed in the code panel also make the editor really laggy.
this really needs to be fixed, i posted some about this as well. Cursor boasts long running agent chats and so I set an agent to test a whole bunch of variables in my program and it runs for 30 minutes or longer testing all kinds of things, and i do that and it crashes the whole program. due to 4gb limit.. it’s running non stop blasting tests sometimes even for an hour and boom crash with 4gb garbage collection stall
Some of us can’t just make a new chat every time we want to do something, it takes forever to get the agent back on track even with handoffs and mcp servers and such it’s frustrating
Hey f00z, the team actually just pushed some fixes for those memory leaks in the Agent and Composer. Updating to the latest version and using a .cursorignore file to trim down your codebase should help a ton with the RAM usage during long sessions. For the UI lag and the chat jumping around, try clearing out your workspaceStorage folder in the Cursor settings directory. That usually wipes out the corrupted session state causing those glitches.
