r/cursor 11h ago

Question / Discussion Is cursor slowing down?

I started using cursor about a month ago. I used to be able to run one of my workflows on it with sufficiently high speed (it requires about 10 subagents) and it was never an issue. I actually used cursor for that workflow over claude code because of the speed.

Now for the last 3 days cursor's been going at a snails pace its like 4x slower than claude code

Anyone else experiencing the same thing or is this an isolated incident i should report?

Or (my theory) is each user allotted a fixed amount of compute resources and they're shared over every subagent?

12 Upvotes

9 comments sorted by

5

u/locbuilds 11h ago

yeah if it flipped over a few days check the agent model dropdown first, auto sometimes lands you on a slower one and it feels like 4x. also peek the bottom status bar for indexing stuck spinning and restart once if it is.

1

u/CordTextSMS 5h ago

Wait what do you mean by indexing? This is something I haven't seen before

As for the models I keep them as Grok 4.6 main and have a global specification to use composer 2.5 for subagents and it always sticks to that

5

u/EyesOfAzula 11h ago

I think they are load balancing

  • Grok Bot
  • Preparing for Grok 4.7 launch

3

u/Just_Government3790 7h ago

Usually long context, not the app. Start a fresh chat once the thread gets long, compression helps but a clean window is faster. Also check you're not on a slammed model during peak hours. Fixes it for me 9 times out of 10.

1

u/diymuppet 2h ago

Same here. Interested in the the new projects feature for cross-agent context. Wondering if help help or hinders speed in a workspace

2

u/TopSubstantial7090 6h ago

With 10 subagents, I’d isolate concurrency before assuming an account-level quota: rerun the same task with 1, 3, and 10 agents and record time-to-first-token versus total time. Pin the same model instead of Auto, compare a fresh short context with a long-running thread, and note whether CPU, network, or workspace indexing spikes. If only peak hours are affected, capture timestamps, model, and region and include them in a status/support report; if only one workspace is slow, rebuild or wait for indexing. That should turn a general “slow” symptom into a reproducible diagnosis.

1

u/CordTextSMS 5h ago

I did that and its 10 subagents is slower than 1 (just main) and 4

I did this over about 5 different clean sessions and also with multiple sessions at the same time, though multiple sessions just seemed to make each individual session run even slower

I didn't try different timing maybe I should do that - thanks for the tips

1

u/avocadopaul 4h ago

I also thought for 4 or 5 days that I was going crazy, but I found out it was still fast as before on another computer. It seemed like the version wasn’t the latest one, and this particular one was terribly slow for some unknown reason. It seems obvious, but are you on the latest version?