There was a recent topic about not losing the monthly requests. I agree with keeping the calendar month of the requests as they are. However, converting to usage based with the potential larger costs can be risky, especially for the individual developer. I also don’t fully understand ‘usage based’ in relation to request based billing. The ‘usage based’ terminology sounds too much like token counting instead of request counting. That unknown is a large part of why I don’t do it.
But, there is a way to help the users hitting their limit and add some additional revenue in the process.
If a user uses all of their 500 requests, they could buy an add-on of 100 extra requests (or possibly of differing quantities). These requests could be used before the monthly 500, but would not expire at the end of the month. It would let a user use their 500, buy 100 more, use 50 of the add-on in that same month, and in the next month, use the remaining 50 of the add-on and then use the 500 from that monthly allocation.
This method would allow a user to buy more premium requests instead of just swapping to a different tool while they wait for their monthly allotment to reset. That’s something I have done. Not having available Cursor requests encourages me to explore other options. I’m guessing that encouraging a user to explore alternatives while waiting for their requests to reset is not your intent. This method would solve that issue and keep users using Cursor along with a bump in revenue, of course.