Ok, since Cursor staff is oddly silent and showing current ambivalence about talking to us about this currently let’s pool some observations.
Sonnet 4
Yesterday was probably an outlier. I had at least ~40 requests for the day until I saw the Rate limit. Then after a couple hours I got ~10 more before bed.
Today I got ~5 in, ~4 hour wait, ~9 in and I’m now at another ~4 hours waiting to see if I get more.
–edit-- after I posted this it has unlocked for 1 request.. so about 5 hours to get 1 additional request.
What have you seen, make sure to include the LLM you are using, how many requests you got, how long you had to wait for a “recharge”, and then how many you got until the next limit.
I’m not interested in token utilization or context windows, this is a back of the napkin math concept here. Sharing is caring and at least we can see if this is an even bias of maybe there are buggies running around.
Could the Cursor devs please comment on this? I’m just trying to figure out which day was the “normal” one by design and which was a bug. I understand new pricing can have glitches, but I’m really not sure what the endgame is supposed to be. Because what he’s talking about (and showing) with 1 message every few hours sounds awful.
If you’re not interested in tokens and context windows, you might have a hard time making some sense of these rate limits. It’s been suggested by devs that they depend on compute usage rather than on raw request numbers. Which would partly explain why some users get plenty of requests and don’t hit the limit, while others reach it very quickly, even when not using MAX mode.
I set about 10 complex background tasks that each ran for about 15 minutes each, plus I did around 30 Max calls, all with Opus Max and haven’t hit a rate limit on my Ultra plan. I’ll push it harder tomorrow, as I’m developing multiple projects at the moment and setting up background tasks to code, deploy, test and repeat.
Also, I haven’t had any ‘too busy’ or connection error glitches at all since upgrading to Ultra. Plus it’s turning out to be a lot cheaper than my PAYG plan. Very impressed so far.
I code all day every day with O3 and have never hit a rate limit with it.
A couple of days ago, I coded for about 9 hours with o3 continuously. I then sent one Opus request and immediately got rate limited. And then just swapped back to 03 and carried on coding for hours.
I find it interesting that I created a thread to log observations and no one except the Ultra’s have datapoints to share. I signed up to Claude Pro to use their Code tool and see how it marries with the IDE and works, and it works well, and it’s amazing how well it tells you when you are approaching your limit and exactingly how long it will take to reset. Simply bad early deployment of this new methodology with Cursor.
Now this morning I got 14 solid requests in, and I was running Claude Pro at the same time and they both reached capacity around the same time which was somewhat telling. The difference is I know that at 3pm I get my limits reset there and I still have no idea what will happen, when it will happen, or what limits will be reached when Cursor will open back up.
Still like to hear more from the Cursor Pro users, how is today fairing for you. Do you feel like you got some clean utility? If I can get the same amount of work I got done this morning this afternoon I’d feel good that Cursor has the right allotment for Pro users, like Claude users, but if it doesn’t then Claude Pro has more utility than Cursor for the dollar. I also have the option of moving up to $100 with Claude and that’s still a nice middle tier vs jumping to $200 with Cursor. So Cursor, you have to quickly get a way for us to understand the limits and the refresh periods and it needs to be on par with what you are trying to mirror or you’ll be making friction, and no user likes friction.
