Cursor has been noticeably slower for about one week.
Composer and Agent responses take longer than before. File changes also feel slower, and the overall workflow is less smooth compared to previous weeks.
I use Cursor daily for serious development work, so this slowdown has a real impact on productivity.
Steps to Reproduce
Open Cursor.
Open an existing project.
Start Composer or Agent.
Ask it to analyze files, make changes, or run a normal development task.
The response and file operation speed is noticeably slower than before.
This has been happening consistently for about one week.
Expected Behavior
Composer and Agent should respond and apply file changes with the same speed and smoothness as before.
The development workflow should not become noticeably slower without a clear reason or status update.
Operating System
Windows 10/11
Version Information
Cursor IDE version: I will add the exact version if needed.
Operating system: Windows 11
For AI issues: which model did you use?
Composer / Agent with Claude Sonnet 4 and Auto mode
For AI issues: add Request ID with privacy disabled
I do not have a request ID right now. I can provide one from a slow request if needed.
Additional Information
This does not feel like a single prompt issue. It feels like a general slowdown in Cursor IDE, especially Composer and Agent. The same type of work was faster before.
It happens across normal development tasks such as analyzing project files, editing files, and applying changes.
Hey, thanks for the report. On the backend side everything looks clean. Your requests are being handled normally, with no errors or timeouts. It looks like the slowdown is on the client side.
To narrow it down, I’ll need a bit of diagnostics:
Exact Cursor version: Help > About or Cursor > About Cursor.
Request ID from a slow request: menu in the top-right of the chat > Copy Request ID. If Privacy Mode is on, please turn it off temporarily for one or two requests.
Check Process Explorer: Cmd+Shift+P > Developer: Open Process Explorer. I’m mainly looking for whether extensionHost or ptyHost is using a lot of CPU or RAM.
Quick sanity check: run Cursor without extensions using cursor --disable-extensions in your terminal. If it’s noticeably faster, it’s likely an extension. You can narrow it down via Extension Monitor: Settings > Application > Experimental > Extension Monitor Enabled.
Also, after long sessions it can help to fully quit and reopen Cursor. Not Reload Window, an actual quit. Agent history and state can build up over time.
Send over the version, the Request ID, and what you see in Process Explorer, and we’ll dig deeper.
This request felt slow on my side during normal Composer/Agent usage. I will also check Process Explorer and try running Cursor with extensions disabled as suggested.
CPU usage was not high during the check. Most processes showed 0% CPU.
Memory usage:
Shared total: about 3870 MB
window [1] (Cursor Agents): about 1032 MB
extensionHost: about 319 MB
Cursor.exe: about 223 MB
fileWatcher: about 127 MB
ptyHost: about 148 MB
PowerShell: about 86 MB
The biggest visible memory consumer is window [1] (Cursor Agents), around 1 GB. This slowdown happens mainly in Composer/Agent during normal daily development work, especially after longer sessions.
extensionHost instances use around 319 MB and 351 MB.
gpu-process uses around 339 MB.
fileWatcher uses around 127 MB / 115 MB.
Several PowerShell / ptyHost processes are open, each around 86 MB, plus conpty-agent processes around 11 MB.
So I do not see high CPU usage, but Cursor Agents is the biggest visible memory consumer, around 1 GB. There are also multiple terminal/ptyHost processes open.
The slowdown is mainly visible in Composer/Agent responses and file operation smoothness during normal development work.
Cursor shows: “All installed extensions are temporarily disabled.”
With extensions disabled, Composer feels noticeably faster. So the slowdown may be related to an extension or extensionHost on the client side.
My current Cursor version:
Version: 3.2.11 (user setup)
VSCode Version: 1.105.1
OS: Windows 11, Windows_NT x64 10.0.26200
Request ID from a slow Composer request:
78b805c2-818a-4ac5-a111-a6c5392637ce
Process Explorer observations:
Shared memory was around 3.8 GB.
Cursor Agents window used around 1 GB memory.
CPU was mostly 0% when checked.
Several ptyHost / PowerShell / conpty-agent processes were visible.
I updated Cursor and the Update button is gone now.
Current / previous version I checked:
Version: 3.2.11 (user setup)
VSCode Version: 1.105.1
Commit: e9ee1339915a927dfb2df4a836dd9c8337e17cc0
Date: 2026-04-24T14:36:47.933Z
Build Type: Stable
Electron: 39.8.1
OS: Windows_NT x64 10.0.26200
Request ID from a slow Composer request:
78b805c2-818a-4ac5-a111-a6c5392637ce
I also opened the Workspace Process Explorer. CPU usage was mostly 0%, but memory usage was around 3.8 GB shared. The Cursor Agents window used around 1 GB memory. I also saw several ptyHost / PowerShell / conpty-agent processes.
Then I started Cursor with extensions disabled using:
& “C:\Users\mc_fl\AppData\Local\Programs\cursor\Cursor.exe” --disable-extensions
After that, Cursor felt noticeably faster. So it looks like the slowdown may be related to extensions, long sessions, or accumulated agent/terminal state.
Great job reproducing it with --disable-extensions, that narrowed it down a lot. The backend side looks clean and your Request ID was handled normally, so the slowdown is really client-side and tied to one of the extensions.
To find the specific extension causing it:
Extension Monitor: open Settings > Application > Experimental and turn on Extension Monitor Enabled. Then run Cmd+Shift+P or Ctrl+Shift+P and pick Developer: Open Extension Monitor. You’ll see CPU and memory per extension in real time. Use Composer and Agents for a couple minutes and watch what climbs to the top.
Manual bisect, if the Monitor doesn’t show a clear leader: disable half your extensions, restart Cursor, and test performance. Keep repeating until you find the exact one. Common culprits are heavy language servers like Pylance, Java, C/C++, Tailwind in large projects, or AI extensions that conflict with Cursor.
A couple extra notes from your logs:
The Cursor Agents window is around 1 GB, that’s the renderer for the Agents panel. After long sessions, it helps to fully quit Cursor and reopen it, not just Reload Window, since state builds up.
You have several ptyHost, PowerShell, and conpty-agent processes. Close unused terminals since they keep memory.
Once you find the extension, reply with which one it is. It’ll help other users and the team see if there’s a pattern.