Hi all. I’m new to Cursor. I’ve been using it^1 for a new work project for about a week now and I’m loving it more and more.
Over the course of this week, as I’ve added more and more code/files to the project, its speed-of-response seems to be getting longer and longer. What are some ways to improve this? Or do I need to give more info about my project/usage in order to answer that question?
Just recently, Cursor began to start most (all?) responses with the following text while it continued to think:
This is a slow request… click here to speed up.
When I click it asks me if I want to enable “usage-based pricing with a $20 monthly limit.” I assume this would mean I’ll pay more than the $20 per month for Pro? This could be an option, depending on how much more I’d have to pay.
Thanks in advance.
^1 Cursor Pro. I primarily use Composer, and so far always with model set to claude-sonnet-3.5.
It sounds like you have used up your fast request allowance, of which you have 500 requests to premium models, like Claude 3.5 Sonnet, which are instantly responded to.
Once you run out, like you seem to have, your queries are then “slow”, and are queued to be responded to - the queue gets longer the more you use it.
You can enable usage pricing, like you mentioned. For a premium request, you would pay $0.04 per request (doubled in agent mode in the Composer). Alternatively, if you switch to a non-premium model (like DeepSeek v3, which is on par with Claude 3.5 Sonnet in performance), you can use that fast as much as you want!
@danperks thanks for replying. I didn’t know that we could use DeepSeek already. Not using the agent feels like a step backwards but since I’m at the limit right now it’ll have to do.
@danperks Thanks very much for all that, and noted. I have a couple follow-up questions.
Once you run out, like you seem to have, your queries are then “slow”, and are queued to be responded to - the queue gets longer the more you use it.
When you say, “the queue gets longer the more you use it,” is this to say that, by design, the more I use it the longer I’ll be forced to wait? Or is this to say that every request of mine will be placed in the queue, and the wait to get to my request may get longer and longer if more and more people get in the queue each time? Or something else?
Alternatively, if you switch to a non-premium model (like DeepSeek v3, which is on par with Claude 3.5 Sonnet in performance), you can use that fast as much as you want!
Ok thanks for that. I was indeed planning on experimenting with non-premium models. I didn’t know that about DeepSeek, so I may start with that.
One last question while I’m here. So far, I’ve admittedly been liberal with my fast requests. By that I mean, many requests I’ve made to Composer (and its premium model) I could have maybe made to Chat instead (and its non-premium model). But can Chat and Composer share information between each other? As in, can I make a bunch of plans with Chat (using a non-premium model), then switch to Composer (using a premium model) and essentially tell it, “Add all the code needed to implement the features that Chat and I just planned.” If that was possible, I could (in-theory) significantly cut down on my fast request usage. Or is Composer unable to know about anything I told Chat and anything it told me?
To be clear, the more you use the slow pool, the longer your specific queue will be this. This to ensure that paid users who are only a few requests outside of their allowance see the least slowdown. Implementing a real queueing system for the volume of requests is not easily feasible and would likely cause larger queues than we currently enforce!
While chat and composer cannot directly share data, you can use non-premium models in the Composer and just tell it not to make any edits, as this will keep all the context in one place. We’re adding better support around this soon!
Great info, thanks so much. Based on that, I have ONE final follow-up question.
While chat and composer cannot directly share data, you can use non-premium models in the Composer and just tell it not to make any edits, as this will keep all the context in one place.
Let me be sure I understand.
First I complete these steps:
Set Composer to a non-premium model.
Use Composer to generate a plan, but make no edits.
In the same Composer conversation, change the model from the non-premium model to a premium model.
Instruct Composer (now using the premium model) to edit the code and implement the plan agreed upon in the most recent Composer message.
At this point, Composer and its premium model should have all the context it needs to make the edits (i.e. context from the previous non-premium-model messages in the same conversation).
Am I understanding that correctly? If so that could indeed be a very viable and helpful option for me. If I’m misunderstanding something though, let me know
We’re adding better support around this soon!
Sounds great. I’d love to stay abreast of all that. Are there existing posts, or open issues/work items I can follow to stay up to date?
You can now use o3-mini in beta, which is free to use, and may work well for your planning phase, and you could use DeepSeek v3, which is also non-premium, to implement the changes!
