Current "monthly reset" billing model is a productivity killer

Feedback
1

As politely as possible, another begging, pleading appeal for Cursor to finally get around to reviewing the way billing works. Based on previous responses I got a year ago, I know a review has been “pending” (promised) for at least that long. Please, let’s un-pend it.

I’m nearly at my 1000 and we’re a few days from the end of the month. That means I pretty much have to write off using Cursor until the month changes. There’s no point me adding another 500 now, because they’ll get taken away from me in a few days.

  • “Use a non-premium model” you might say. I’m running at the limits of sonnet’s understanding with the project complexity, so it’s really a non-starter.

  • “Use the slow requests” you might say. But based on my previous experiences of this, waiting over five minutes for a query that might fail or return a nonsense result, and then trying again, is beyond impractical (320 seconds seems the standard countdown I’ve reached after a couple of requests in all recent times I’ve hit the slow queue).

  • “Pay per use” you might say. But I shouldn’t have to. I’m already paying an annual subscription. That would mean being punished financially on top of that subscription, for every single request I make.

I know designing billing models can sometimes be non-trivial, but with this many users and that much technical expertise at HQ it shouldn’t be beyond reach.

At the very least, let us use an annual subscription for the year, like it implies, instead of stealing back our credits every month. Or better yet, roll credits over, have a “top up” model where you get to keep the credits you’ve actually paid for. Something, anything but the current scheme.

Team Cursor: please please please please please please please please try to bump a serious, data-driven review of usage and pricing up your priority list, it’s way past due and it’s making me loathe the last week of every month. :frowning:

Thanks.

3 Likes
2

Business decisions as crucial as pricing often do not come down to UX, but to revenue. You’re asking them to do something that will potentially cost them money.

  • “But they’ll actually make more my way if you think about it” you might say. That’s an interesting theory. I’m sure they are aware of that theory. But what they have now is revenue. It takes a pretty good theory to win a fight against revenue.
  • “But [ other_reason ]” you might say. That’s why I said ‘potentially’.

“Use a non-premium model” you might say. I’m running at the limits of sonnet’s understanding with the project complexity, so it’s really a non-starter.

Extremely valid. However given the next two, I am skeptical of the fact that you are right about this, or have the understanding to determine it.

320 seconds seems the standard countdown

Those are not seconds. I believe they are people in line, might be requests in line if those are different. In any event, it doesn’t take anywhere near 5 minutes for that to run. More like 20 seconds to 1 minute. And typically it’s lower than 320. I would estimate the average wait time to be about 15 seconds. With a maximum of two minutes, which is rare.

This does not mean your general point is wrong, I’m just clarifying your misunderstanding of how this slow request mode works.

“Pay per use” you might say. But I shouldn’t have to. I’m already paying an annual subscription. That would mean being punished financially on top of that subscription, for every single request I make.

This basically amounts to ‘I don’t want to’. And it is by far your weakest argument.

Pay per use is an excellent compromise to this situation. What you’re asking for is identical to pre-paying pay per use. Which from a financial perspective is worse for you. (Lookup ‘time value of money’ if you don’t understand why).

  • “But pay per use costs more” you might say. If that’s the case, I was lacking understanding there. But it loops back to what I said up top. Asking them to potentially make less money.
1 Like
3

I’ll mostly breeze past your ad hominem tone, and agree with some of what you’ve said.

or have the understanding to determine it.

On the contrary, I’ve been using Cursor for well over a year (as well as various other LM tech on a day to day basis) and I’m pretty familiar with its limits. If you think I’m only using it for small stuff, check out An Idiot’s Guide To Bigger Projects for context.

Those are not seconds.

… your misunderstanding of how this slow request mode works

You really piled in hard on this point huh? :slight_smile:

But actually I was very much talking about my experience of waiting 320 seconds, no misunderstanding. The change to showing the queue order is a very new feature. For the longest time, seconds is exactly what you got, and not even estimated seconds, but a real full-on three hundred and twenty second countdown. It sounds like you didn’t have any experience of that, and in which case I’m very happy that you haven’t had the same frustrations as me. I’m also pleased to see the new queueing-based approach come into action. But I did not misread or misunderstand anything here.

In case you still don’t believe me, it’s pretty easy to try searching the forums for other examples, e.g.,

(and those are just some with 320 seconds in the title)

This basically amounts to ‘I don’t want to’

You’re right I absolutely do not want to pay for credits I’ve already paid for. That is most definitely financially worse. Note the emphasis in my original post – “on top of that subscription”. Nowhere have I said that pay per use isn’t a viable model. I’ve said that paying for credits in a subscription, having them summarily taken away, and then being made to pay for them over again is poor.

I don’t disagree with your point about a change having the potential to make Cursor less money, you’re right it could, done badly.

But a decrease in profits per capita doesn’t necessarily result in lower long term gains. There’s a reason shops don’t charge $85 per loaf of bread. Much like Laffer curves, there’s a sweet spot for optimum yield and I’m not convinced that we’re at that sweet spot right now. Nor do I think we can assume that sweet spot will never change, especially as competitors appear and the technology accelerates.

I believe I was more articulate than just saying “if you think about it” too. I’m not suggesting anyone merely ‘has a think’; “a serious, data-driven review of usage and pricing” is what I asked for and I stand by that. It’s something the development team alluded to over a year ago in conversations I had on these very forums, but it hasn’t happened yet.

So returning to my original point – we’ve been promised a review for over a year and it hasn’t been forthcoming. Now I’m renewing my call (politely begging and pleading without being aggressive or trying to undermine anyone personally) for the expertise at Cursor HQ to be applied to all that rich usage data they have, and see if they can’t do better.

For themselves, and for us.

4

I did not. And it’s nothing like that for me now. I am running slow mode now and they are going through with no delay. Sounds like things improved.

I absolutely do not want to pay for credits I’ve already paid for. That is most definitely financially worse.

It’s worse for you, this month. That isn’t what I meant. I meant if you made the game-theoretically correct decision in each scenario. You’d be coming out ahead paying per request vs buying in bulk - assuming the cost per request is the same. The reason is time value of money: in short, you can stick that money in the bank and earn interest on it.

But a decrease in profits per capita doesn’t necessarily result in lower long term gains. There’s a reason shops don’t charge $85 per loaf of bread.

I already addressed this. This is your theory and it sounds nice. Surely Cursor is well aware of this theory but it appears they have a theory of their own.

5

A monthly burst allowance wouldn’t be the worst, especially if you had credits remaining from the last billing cycle(s). By that I mean it’s friendlier (for the dev) than the current hard-limit approach, and seemingly wouldn’t be “giving away the farm” from Cursor’s financial perspective.

Billing is definitely something that is designed by a committee, unfortunately. I’m sure it has been discussed to an exhausting degree internally, though.

My current go-to: I’ve got all my project context and documentation in my project in Claude. It’s a great fallback for when queue times are long with “slow mode”. It’s not the best, and I miss working directly in Cursor when I do this. I also refuse to pay even more (I mean, I pay for OpenAI, Cursor, Anthropic, and probably others that I’m forgetting) so I’m not plugging the Anthropic API key into Cursor during these times.

Hopefully something comes along that can help in this arena. “Bursting” is not a new concept, especially in software, so maybe they’ll employ at least something like that.

1 Like
6

is there an official explanation of how this works exactly?
I am at $80 per month (4x), used a bit more than 1500 out of 2000, it says I won’t be charged next month and I have absolutely no idea of what’s going on :slight_smile: