GROK 4.6 and Composer 2.5 have been incredibly slow since last week Thursday (9/3/26). They often stall as well regardless if multi agent with multitask or with single agent mode. Running 3.19.13.
Steps to Reproduce
Generate any prompt with agent or with multitask using Grok or Composer as agent on fast. Less than half the time it completes 6 steps and then stalls with no error message. When it does work it’s a fraction of its old speed.
I’m on my first month of ultra. the first week of 2 was normal fine, used up my other models usage and have been using grok 4.6 without issue, then I hit 50 or 60 percent of usage and the speed just plummeted. like 1/15 of the previous speed. I thought it might be high usage time and thus lagging but it’s been an entire day+ and it’s unbearably slow. Is this a thing where it gets throttled or what?
Hey @Gnow and @iochleonard — thanks for the report! (And no, Ultra is not throttled at any usage percentage.)
Looking at your accounts, the slowdown lines up with the Cursor 3.19.13 update on your Windows machines, not with your usage. The model itself is responding in a couple of seconds, but the steps in between (file searches, reads, and edits on your machine) went from roughly a second each to anywhere between 20 seconds and several minutes. That’s why a run appears to crawl or seem stuck. We’re investigating this now.
Two things that would help us confirm it on your end:
Next time a run is crawling, expand the step it’s sitting on. Is it a Grep, Glob, Read, or an edit step with a running timer? Reply with which one and roughly how long it sat there.
Click the three dots on that message, select “Copy Request ID,” and paste it here.
Hello, been using cursor for around 4 to 5 months now. This week im also noticing the behaviour described here.
i mostly use it on Grok 4.6 high with fast off which hasnt been an issue until this week which has turn unbearably slow.
its been over an hour so far on editing a csv file to determine the order of some tasks. it says its answering my follow-ups but im not really seeing an actual item being edited as it says its doing.
when i prompted if its stuck is because it says thinking however the thoughts dont really show its doing anything.. (when it appears stuck)
the issue im seeing is similar to what was described in this other forum item: The subagent just hung on “thinking”
not sure if relevant but my machine specs are: i9 14th gen intel processor, gen5 ssd, 64gb ddr5 and rtx 5080.
this is the request id on the chat im working on: d709de67-3027-4eac-a09f-1702f0221d24
update:
I left it running over night and it just ended up in a infinite recursion loop repeating the same thing over and over. im using grok 4.6, i then this morning reverted to before the prompt and asked kimi v3 instead and it managed do what i asked. I think the issue is with the model specifically.
Likely a Cursor LocalGrepExecutor.runFilesMode regression.
For the last few days (there were two Cursor updates), any prompts are very slow and seem stuck mostly on low level steps when grepping local files.
In some cases it is stuck for 30min when it should have finish in 2min.
What agent investigated and found:
LocalGrepExecutor.runFilesMode: up to 1,834–1,846 seconds
LocalGrepExecutor.executeRg: under 2 seconds
Cloud queue: 1–6 ms
Issue appeared after recent Cursor updates
.cursorignore is present
What agent suggested as WA is to include in prompt prompt:
Do not use built-in Grep/Glob file discovery or workspace-root ** patterns. Use one terminal rg --files command with explicit exclusions for input, output, and _archive.
Steps to Reproduce
in the workspace prompt any simple task, for instance to create new packaging with the latest version (a task that used to take 2min)
Expected Behavior
The packaging should not take more than 2-3min (like in previous instances)
Hi @Colin there is a new topic: Agent recursive file search hangs for 30 minutes although ripgrep finishes in 2 seconds
It was merged into this topic but I think the problem mentioned there is NOT related to model (as discussed in this topic).
In the other topic the issue was analyzed with an agent and the problem was identified in cursor itself when doing local I/O and greps local files before sending to model.
I’ll rename this topic now that it’s become the canonical thread for this issue – but I can tell you it’s the same issue and ultimately not related to the model. Your report lines up with the other reports in this thread!
I take that back. It worked better for about an hour, now same problems as 3.9.13. Grep and search are primary harnessing features it is stalling on hands down.
hi @Colin - thanks for your response here. my cursor went a bit further and uncovered the following reasons. not sure if that helps in investigation - but please take a look:
Cursor 3.19.13, Windows 11, domain-joined. With several chats and subagents open, every tool call in a window (shell exec, file read, terminal read) takes 10–100 s and the renderer logs “extension host is unresponsive” every few seconds. An Extension Host CPU Profile (226 s, attached) shows the event loop busy for 225.7 of 225.8 s (0.1 s idle), with 222 s (98%) of self time in native spawn under spawnSync → execFileSync, in 85 contiguous blocks, 32 longer than 3 s, the longest 9.4 s. The stack is processTimers → listOnTimeout → checkExclusiveMutationClaim → checkExclusiveMutationClaimInternal → … → execFileSync in extensions/cursor-agent-exec/dist/main.js. In the bundle, startExclusiveMutationClaimPolling() sets a setInterval of In=250 ms, and the lock-owner function ft() runs execFileSync("whoami", ["/user","/fo","csv","/nh"]) on every poll with no caching; nearby ACL code also shells out synchronously to icacls and to powershell.exe -NoProfile -Command "[SecurityIdentifier]::new($args[0]).Translate(...)" (which fails here with “Unexpected token ‘S-1-5-18’” in the exthost log). One sync engine exists per live conversation: 34 stores under %LOCALAPPDATA%\Cursor\AgentStores\cursor_agent_stores\*\.sync\sync.lock were touched in the last 5 minutes across four windows, and a 12-second process sample caught 30 distinct short-lived whoami.exe children of the extension-host processes.
Impact and suggested fix. whoami.exe takes ~65 ms per spawn here, so a window with ~10 live chats/subagents needs 10 × 4 × 65 ms ≈ 2.6 s of synchronous blocking per wall-clock second and can never drain its event loop; the effect grows with each subagent and clears only on window reload, matching the user-visible pattern (fast after restart, degrading as agents run). Idle windows poll their own stores too. Suggested fixes: cache the current-user SID for the process lifetime (it cannot change), replace execFileSync/spawnSync in the lock and ACL paths with async spawn or os.userInfo(), and lower the 250 ms claim-poll rate or make it event-driven; alternatively expose a setting to disable agent-store sync (agent_store_sync_client). Reproduction: on Windows, open one window, start 5–10 agent chats that each spawn a few subagents, run the Extension Host CPU Profiler for 60 s, and observe spawn under checkExclusiveMutationClaimInternal dominating self time while whoami.exe children appear continuously under the extension-host PID.
@Colin More work in the last 24 hours reveals it is a harness problem specific to Grok and Composer, if you force it to use API and a non cursor model. In 3.17 at least, if I force it to use non cursor models, their speed is full and there is no stalling on any grep or search harnessing.
Thanks a lot for the reports. We’ve been chasing this down and have pushed out some fixes in 3.20.17 that we expect will bring tool call execution time back down. When you have a chance, please update and let us know!
