How to limit my budget cost say $30 a month spent for Gemini api?

+1 Looking forward to this feature

Hi, as many others, I just dropped my Gemini API keys until there is some budget limiter in place.

Not having this, it is simply the greatest way to go bankrupt while sleeping and the api key gets stolen, the AI agent goes crazy, your website AI feature gets a spike of use… and any other thousand of unimaginable ways…

Please Google, fix this as sson as possible.

1 Like

This is a clear roadblock for me to use Gemini cli and their products. Very sad :cry:

1 Like

Same for me, I’m not using Google API anymore because of this. And their budget limit notification is useless because of the latency…

2 Likes

WHAT?!?! Are you saying that if someone steals the API key, then they can charge up a MILLION dollars with no way to stop them until you notice that it is happening?!?!?! THIS CANNOT POSSIBLY BE REALITY. Is Google seriously asking for another class action ??

1 Like

Any news or follow ups on this? Seriously this feature is a must.

1 Like

Any news for this ? i really need it urgently

1 Like

That’s the gist of it, and why it’s so dangerous, and one of the reasons why people want the hard cap. There’s also another thread where a huge bill was generated when Gemini was running in a loop, the costs kept accumulating even after the API keys were all revoked. While it’s true that Google waived the bill, depending your existence on someone feeling pity (or generous) is a risky maneuver. I hope this change comes soon, because I don’t feel safe using the API until the hard cap is in place. And when I can’t use the API, then at some point it’s also risky to just have an API key (that someone could use) and billing information (where someone could create an API key if they got into the account) in place, so I’ll best remove that too.

In a way, the Google API key is a bigger deal than your bank account. If someone got in, they could put my bank account at $0, but here they can rack up a huge debt.

1 Like

While I am generally very satisfied with Google’s ecosystem, I find the current decision-making regarding this specific feature difficult to reconcile. It appears to prioritize monetization at the expense of user experience and product utility, which seems counterproductive to long-term adoption. I would appreciate more transparency on the reasoning behind this approach, as it feels inconsistent with the core values I usually associate with your organization. I hope this strategy can be re-evaluated to better serve the developer and user community.

So, the best solution is to set up a Credit Card with a spending limit set by the bank? Maybe one of those Revolut cards?

Hi all, working on spend caps, so hopefully we’ll have a solution in AI Studio here soon!

Good to hear this is being worked on. With the drama that’s happening with OpenAI, I’m sure a lot of people are ready to jump ship. I suggest rolling spending limits out ASAP if you all want that sweet sweet business.
I tested using Gemini API for my use cases and it’s been great, but the fear of a misconfigured app or leaked API key costing me thousands is stopping me from making the switch.

Nope, if they steal the key and steal a million in usage or whatever, you’re still bankrupt. It doesn’t matter whether you can’t get auto-debited, you owe them the money.

Here’s the best workaround I’ve found. Using the CLI, do the following:

  • List your GCP projects that have generativelanguageapi enabled
  • For each of those projects, set rate limit to 0 for all models
  • Set non-zero rate limit for the models you actually want to use
  • Configure a spending notification alert
  • Configure a pub/sub job that turns off the API if the notification limit is reached

I used Claude Code to do this, but it’s not too difficult to do manually or with some other assistant.

Using this approach your exposure will probably be pretty minimal if you keep the expensive models off. If your key was stolen you might be able to contest charges that occur between the notification alert being triggered and actually received too.