The wait time used to be dynamic: when there is a long wait line, you wait long, but you can also get instant response when there is no long queue.
We’re speaking of the slow requests after you ran off the 500 requests coming with your plan, of course.
But Cursor obviously just implemented a hard-coded wait time for slow requests, increased to a few minutes in the past two days.
If you enable usage-based, it still goes through Cursor’s server and you get instant response.
That means: Cursor’s servers are not overloaded, you just wait because you ran out of your fast request.
Now your slow request is not dependent upon whether the servers are busy, but you’ll simply have to wait for minutes for each request, or you’ll need to buy another 500 requests for 20 dollars.
Hey, just want to clarify what maybe happened here!
With the release of Claude 3.7, we had some incorrect config on our server that meant the slow pool was not working as intended, and was allowing slow requests to execute too quicker than we could manage, putting significant strain on our ability to serve fast requests to users without errors.
Once we realised this, we’ve brought the slow pool parameters inline with where Claude 3.5 has been for a while.
While we’ve not necessarily “increased” the wait time for the slow pool, this resolution would in effect cause what you are seeing!