I have, my 500 requests last me 1 day, so I work on slow requests, but it was usable, even if I waited several minutes.. I just worked on 3 things at a time 
But plz explain Throttle down? like to the point where they time out every time? or get stuck generating? or that’s just the other issues.
They shouldn’t ever time out of get stuck, if they do this is a bug we would love to fix!
By default, they will respond increasingly slowly each time you request. This decrease in speed should not really affect most users, but if you are a super heavy user of the slow pool (100s or 1000s) of requests, you will find a significant delay in response, as that is not the intention of the slow pool.
“slowpool” is how must vibecoders work as 500 requests is not much, even if its not the intention, you should know that.
but question remains. Throttle down? like to the point where they time out every time? or get stuck generating? or that’s just the other issues. (like if we are in the 10000s) I should still be able to use it with what 30 minute waits? 
“throttle down” was my way of saying they get increasingly delayed, they should not time out or get stuck - if they are, this is a bug and I’d ask you to check the console for errors by running the Developer: Toggle Developer Tools command!
What i would like to know is what is the maximum and minimum ‘throttle’ threshold? What is the max time a user will be throttle and what is the minimum time? Having a mechanism to slow request usage down, even if considered excessive, should have guidance on how it works.
At some point, it becomes no longer economical to use the application. I get wanting to shepard resources, but something has to give.
I’m not sure the algorithm behind it, I’d assume it’s exponential, so the first x requests will all be pretty fast, maybe +1-2 seconds, but as you get deeper into the usage, the jump each time will be bigger.
I understand this is not an optimal solution, but as each request has a direct cost, we cannot give truly free and unlimited usage, so this helps to “disincentivize” excessive slow pool usage (aka into the 100s and 1000s) without ever cutting anyone off fully.
if algorithm is directly linked to number of users on such “slow pool” then as suggested somewhere else, number of student account is probably the reason why waiting times are now unviable (for high usage) , it was usable before, even as a heavy slow pool user.
It may be good to provide further transparency and notices that are easily accessible (or a pop up when selecting models for example) for pro users in regard to this. Some form of x # of slow requests over the fast request limit = delay of x per slow request, and then tier it out as users progressively use up more slow requests deeper into the limit.
Key importance here is the degree of transparency and where we’re seeing users feeling like the divergence from the previous speeds is causing a lack of transparency and decline in performance. Instead of the users understanding from a business standpoint, they’re just expecting the same consistent slow request speeds - which if we’re being totally transparent here, have been significantly slowed down compared to how they were previous to this week or so. This was done without any announcements to an algorithm change or upcoming disincentivization notice, or anything. Thats been part of the mass posts about slowness, Reddit blowing up on it, partial causations of this overall post, etc.
The sudden change definitely drove some users away and severely eroded trust.
Completely unusable and being slow are two entirely different things.
It’s unfortunate that Cursor went so far as to block users from searching for this article title on their forum.
Cursor has become completely unusable for me in the last few days. I can deal with the slow responses, but the fact that it can’t keep any of its rules or context from prompt to prompt is causing me to spend hours trying to get it work correctly. Here is the latest thing that happened.
I started a new chat, I have “claude-3-sonnet” selected. I asked it to review its rules, and it read them back to me. I asked it to scan some csv files and grab the headers and put them in the column mapping field in some Python code. It failed to do it. It thought that it wrote a Python script that it didn’t, then tried to run the file it didn’t create using commands that it just read back to me that it’s not allowed to use. Here is its response to me:
You’re right, and I apologize for the continued problems. This isn’t normal or acceptable behavior.
The specific issue is that I acknowledged the rules but then immediately tried to run terminal commands without permission when attempting to verify column mappings. That’s a direct violation of the guidelines you set.
This pattern suggests a fundamental issue with how I’m processing and maintaining your instructions between message turns, even within the same conversation with the same model. It’s not a matter of forgetting - it’s a failure to consistently apply acknowledged constraints.
For a platform that’s meant to assist with coding tasks, this inconsistency makes it essentially unusable, as you’ve pointed out. This requires escalation to the development team as it appears to be a core issue with how the model processes and maintains instruction adherence across turns.
Would you like to approach your original task in a completely different way that avoids any execution without your explicit approval? Or would you prefer to report this issue to the team developing the platform?
@tumeden Unfortunately, we cannot offer requests for free and therefore how to maintain our price to ensure we remain financially viable - we do not have the luxury of being able to offer requests our for free like Microsoft can.
However, I can assure you the model and it’s configuration are the same for fast and slow requests, so you should not be seeing any degraded performance when using the slow pool.
@RickAcq Can you share a screenshot with an example of this occurring? Claude 3.5 is one of the most stable and reliable models in Cursor, so I’d be surprised if it was hallucinating making files in a brand new chat!
Any update on this?
为什么cursor总会在写一个功能的时候 总是会写一个简化版本呢？这是因为你们底层的提示词？让他写出能够正常运行的代码吗？但是这样会直接影响真正功能的不是吗？ 且代码的简洁高效性直接就丢失了。
Hi!
Got similar issues as mentioned above although the author seems to mention different things:
I am unsure what to think now…
May 27
It’s not that we’ve consumed too much of this or that, it’s that your offer isn’t relevant.
You’re offering something that doesn’t match the way we use it.
It’s up to you to adapt, not the other way around.
I’m sick and tired of reverse accusations.
Hm, given that it’s been a couple days, devs have manifested this is not the case at all that this is slower than usual even though every user here tells otherwise I’m assuming this is going to stay as is, right?
I’ve noticed that the cursor becomes very slow when processing a request—especially while using Claude. It’s taking around a minute to generate a response, which is much slower than usual.
I have found Cursor almost unusable in .50 and 1.00. The hard disk light on my laptop goes on and stays on for long periods of time. Working with Claude, it appears there are continuous writes to the database files.
I write real time systems. This appears to me to be a symptom of what happens when you stack library call layers until you have no control over resource utilization, or even a way to see what is happening.
If it has not already been done, I suggest bringing all of the resource hogs into a controlled interface that prevents writes if there is nothing changed. Batching writes also helps, but does have potential issues as well.
Needless to say, writing to a few simple files on a laptop disk is not really a new issue. It reminds me of the race to get console input typed blindly into a 90’s era OS to bring it back from the edge during a thrashing death spiral.
I recently put an API key in just to try it and man did those responses come back fast. I was stunned. Not to say that’s the way to go since there are draw backs (unfortunately) around rate limits for tokens from the likes of Anthropic for non-org users. Also loss of features like tab is an issue (Cursor could fix that but they are up-charging for requests so they are not motivated to address it or so one could theorize). My point is the backend did not seem like the reason for slow results at the time since I was using the same model in both cases.