Extreme Cursor Helper usage on MacOS in even moderately long composer agents

[isarmstrong]

Hi, thanks for reporting an issue with Cursor.

Before you report this, we’d appreciate if you can search this forum to see if this issue has already been reported.

If you have done so, please check this box.
on

Describe the Bug

When running long composer chats (kind of what it is best for by default), Cursor Helper’s idle CPU management gets extremely inefficient even on my M2 with 48gb/RAM.

Steps to Reproduce

Run a composer for 2-3 hours. Every time.

Expected Behavior

I would expect Cursor to limit high CPU usage to active tasks vs idling so hard that it causes in-app keyboard lag.

Screenshots / Screen Recordings

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 0.44.8
VSCode Version: 1.93.1
Commit: f3b5a63019e4e2283033b4db987a35f8413c7570
Date: 2024-12-22T05:48:08.427Z
Electron: 30.5.1
Chromium: 124.0.6367.243
Node.js: 20.16.0
V8: 12.4.254.20-electron.0
OS: Darwin arm64 24.2.0

Additional Information

Once cursor backgrounds the system is okay but the moment I start typing in the composer it spikes.

Does this stop you from using Cursor

No - Cursor works, but with this issue

[SoMaCoSF]

Even though not on Mac, I’d love to know root cause.

Specifically; what is the agent doing with that long lived thread/process exactly?

Complete naive take: is there some sort of garbage collection that could be applied to context windows, whereby older, understood/frozen concepts/files/code/checkpoints can by “hashed” “holographically vectorized, in a temp ‘llm’ like scratchpad of sorts…

Basically where can I find latest on what pushing context/attention current state?

[accessor]

I don’t think this is a big.

You should create new composers when you pivot from a specific tasks or topics. That helps tremendously. Always index your code base when it prompts/requests you to.