What happens if I subscribe Cursor pro and register (OpenAI) API key simultaneously?

For example, then can I use more than 10 req to o1-mini if so?
(Cursor Pro limits 10 o1-mini reqs/day)

Hi @jjangga0214

If you have your API key, you’re not limited by anything.

1 Like

Thank you!
I wonder how it’d be counted.

Is it true that cursor quota(e.g. 10 o1-mini reqs/day) is consumed first, and then API is used only when the cursor limit is exceeded?

Nope, you manage your API key expenses on your own.

I also was thinking to apply my own keys - I have Open AI and Google Gemini. Like, why pay in three places right? But constraints that Cursor imposes on external models are pretty much ruining whole point of using Cursor in first place. So I didn’t apply them in the end.

May I ask if we misunderstand each other?

I meant I expect something like this.
For instance,

  1. On Monday morning, I subscribed to Cursor Pro.
  2. I also registered my OpenAI API key in Cursor.
  3. On Monday, I made 9 requests to o1-mini from Cursor.
  4. Since Cursor Pro provides 10 requests per day for o1-mini, I was not charged by OpenAI.
  5. The next day, I made 11 requests to o1-mini from Cursor.
  6. The first 10 requests on Tuesday were covered by my Cursor Pro subscription, but the additional 1 request was executed using the API. Thus, OpenAI only charged me for that 1 request.

Conclusion(Expectation): API cost is $0 on Monday, but not on Tuesday.

This was my expectation and I wanted to know whether this assumption is true.
Do you mind if I ask again, to make it sure?

You control your API key expenses. There’s a switch in the settings for that. When you need it, you turn it on, and from that point, your subscription quota isn’t counted — it’s counted directly from the API. As far as I know, you get 10 requests per day, then you’re switched to slower requests.

there is a hotkey right?

was it CTRL SHift 0 ?

Yes, this shortcut is for the OpenAI API key.

2 Likes

Ah, I see.
So you meant that a user have to MANUALLY switch it.
IMHO, it’d be somewhat inconvenient.
I think the option for “automatic switch”, which is similar to what I described, will be great.
I actually expected this behavior as the sane default.
What do you think?

I don’t think automatic switching is the best option. Imagine you have a Pro subscription, use up your 10 requests without realizing it, and then you’re automatically switched to the API where you don’t have enough funds. I think manual control is better to avoid complaints like, “I didn’t want the API to kick in, but it did without any notice, and I ended up spending a lot of money.”

1 Like

a convenient manual switch would be the best for most people, with a simple button/icon

Even better if we could actually see how much free requests we did that day :wink:

Right now the only way is to go to the website and manually count by going through a tedious (also cause the site lows slowly despite 2 MS latency)

website-> settings-> click “Optional Usage-Based Pricing” and wait till it shows up

having a way to see in the IDE or anywhere else would be very convienient. (1st World problems i guess haha)

The current system aslo doesnt seem to track properly either, is there a token limit too?

For example a few days ago on the 21 October used 4 requests of GPT4-o-128k Long context.
2 of those were charged, mentioning “(392eabec)”
which is weird when only 4 in total were used, my only guess could be its a bug, i mean its just 20 cents but it made me stop using the long context mode with GPT4o and only cause i randomly check every now and then

I think, instead of changing default, “just providing an option” would be good.
I believe users should be able to choose what they prefer.
Some people, including me, may find that an automatic switch suits their usage style better.

API where you don’t have enough funds

This may be a problem if automatic switch is default.
But as long as it’s an non-default option, users activate it by their free will.
So it makes sense.

2 Likes

an API would be nice, so we can create our own rules, like condition based switching

also via an API we could implement features like, when does a slow request start or or daily usage so we can swap to custom models or API or when something would go above context window, swap to larger model