Google Gemini API account: keys, billing, and quotas
Setting up access: AI Studio against Vertex AI, generating and securing keys, what the free tier actually permits, and how billing and quotas behave once you move to production.
Osman Ramadan10 min read
On this page
Getting a Gemini API key takes about a minute. Deciding which of Google's two routes you should be on, and understanding what the free tier does with your data, is the part worth spending ten minutes on before you build anything you intend to keep.
This page covers the account side: the two access paths and how to choose, generating and protecting keys, what the free tier permits, and how quotas and billing behave. For the API itself, the model families, and migrating from PaLM, see the Gemini API guide.
What we'll cover
Two routes, and which one you want
Google offers Gemini through two products, and they are genuinely different rather than being two names for one thing.
Google AI Studio is the direct route. You sign in with a Google account, generate an API key, and start making requests. There is no cloud project to configure, no permissions model to understand, and a usable free tier. It is the right choice for prototypes, side projects, internal tools, and any application where simplicity matters more than governance.
Vertex AI is the same model family inside Google Cloud. Access is through cloud credentials rather than a simple key, which brings identity and access management, audit logging, regional control over where requests are processed, private networking, and the contractual and compliance posture that Google Cloud carries. Setup is meaningfully more involved.
The dividing line in practice is whether anyone will ask you where the data went. If you are handling personal data, working in a regulated sector, or need to tell a customer which region processed their request, that is Vertex AI. For most other work AI Studio is sufficient and considerably less trouble.
Starting on AI Studio and moving later is a normal path, and the application code changes less than you might expect, since the request and response structures are shared. Authentication and the client library setup are what differ.
Creating a key in AI Studio
- Go to aistudio.google.com and sign in with a Google account.
- Open the API keys section from the left-hand navigation.
- Choose to create a key. You will be asked to associate it with a Google Cloud project, and AI Studio will offer to create one for you if you have none.
- Copy the key immediately and store it somewhere sensible. It is displayed once.
The project association catches people out, because it appears even on the free path. What it means is that every key belongs to a cloud project whether or not you ever open the cloud console, and that project is where billing attaches when you decide to enable it.
Test the key before building anything around it. A single request from a terminal confirms the key works and that your region permits access, which saves debugging an application against a key that was never valid.
What the free tier actually permits
The free tier is genuinely useful, and it has three characteristics worth knowing before you rely on it.
Rate limits are modest. Requests per minute and per day are capped at levels suited to development and light use. They are easy to reach with any parallel processing, and the limits differ by model, with the faster models permitting more.
Data may be used to improve Google's products. This is the significant one. On the free tier, Google's terms allow prompts and responses to be used for product improvement, including human review. That is a reasonable trade for free access and an unreasonable one for customer data, confidential documents, or anything covered by an agreement you have signed with someone else.
Availability varies by region. The free tier is not offered everywhere, and available models differ by location.
The rule that follows is straightforward: the free tier is for building and testing with data you would not mind being read. The moment real user data enters the picture, move to paid, where the terms are different.
Moving to paid
Enabling billing changes the terms as well as the limits, and the terms change is usually the more important half.
Attach a billing account to the cloud project your key belongs to, through the Google Cloud console. Once billing is active, that project's usage is charged per token, rate limits rise substantially, and paid-tier data handling applies: prompts and responses are not used to improve Google's products.
Three things worth doing at the same time:
Set a budget with alerts. Cloud billing budgets send notifications at thresholds you choose. Configure one before the first production request rather than after the first surprising invoice.
Separate projects by environment. Development and production in different cloud projects means separate keys, separate quotas, and separate billing lines. A load test cannot then exhaust the allowance production depends on, and you can see what each actually costs.
Understand what you are billed for. Charging is per token, input and output, at different rates, and varies by model family. The long context window means a single request can carry a great many tokens, so a workflow sending whole documents repeatedly costs more than its request count suggests.
Setting up Vertex AI
The longer path, appropriate where governance requirements make it necessary.
- Create or choose a Google Cloud project and enable billing on it.
- Enable the Vertex AI API for that project.
- Create a service account for your application and grant it the Vertex AI user role. Resist granting broader roles for convenience, since this is the credential your application will hold.
- Generate credentials for the service account, or better, use workload identity federation so no key file exists to leak.
- Choose your region deliberately. Vertex AI lets you specify where requests are processed, which is frequently the entire reason for being on this path.
- Configure the client library with the project, location, and credentials rather than an API key.
The operational differences are the point. Requests are logged in Cloud Logging, access is governed by IAM and can be scoped per service account, data residency is controllable, and usage appears in the same billing structure as the rest of your cloud estate. For an organization that already runs on Google Cloud, this is much less additional work than it sounds.
Keeping keys safe
A Gemini API key is a bearer credential: whoever holds it can spend your money.
Never put a key in client-side code. A key in a web front end or a mobile application is a published key, regardless of obfuscation. Requests must go through a backend you control.
Never commit one to source control. Use environment variables or a secret manager. If a key does reach a repository, rotate it rather than removing the commit, because the history remains and scanners find these quickly.
Restrict the key where you can. API keys support restrictions, and applying them limits what a leaked key can do.
Rotate on a schedule and on departure. Keys do not expire on their own. Rotating periodically, and whenever someone with access leaves, keeps the exposure bounded.
Use separate keys per application. Shared keys make it impossible to tell what is spending your budget, and force you to rotate everything when any one thing is compromised.
Watch for unexpected usage. A sudden change in consumption is the signal that a key has escaped. This is what the billing alert is genuinely for.
An alternative worth considering for business workflows is not holding keys at all. On CodeWords you describe the automation in plain language and Cody, the automation builder, builds it, with model access provided as part of the platform rather than as credentials you manage and rotate. Automations connect to more than 3,000 integrations. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.
Quotas and what to do when you hit them
Quotas apply per project, per model, and per minute or day, and a 429 response means one of them is exhausted.
Identify which quota bound. Requests per minute and tokens per minute behave differently and have different remedies. The error message and your cloud console quota page tell you which.
Retry with exponential backoff and jitter. A pause and a retry resolves a genuine rate limit. Retrying immediately, or all your failed requests simultaneously, reproduces the collision.
Check whether you are still on the free tier. A surprising proportion of quota problems in applications that feel like they should be paid turn out to be a project where billing was never actually enabled.
Request an increase where you need one. Vertex AI quotas can be raised through the cloud console, with a justification. This takes time, so it is worth doing before a launch rather than during one.
Reduce what you need. Moving a step to a faster model, caching repeated context, and batching work that is not time-sensitive all lower consumption without any quota change.
Frequently asked questions
Is the Gemini API free?
There is a free tier with modest rate limits, and on it Google's terms permit prompts and responses to be used for product improvement. Paid usage is charged per token and carries different data handling. The free tier suits development; production with real user data belongs on paid.
Do I need a Google Cloud account?
For AI Studio, not in any meaningful sense, though your key is still associated with a cloud project created behind the scenes. For Vertex AI, yes, along with billing and IAM configuration.
Can I use one key for several applications?
You can, and it makes attribution and rotation considerably worse. Separate keys per application let you see what each costs and rotate one without disturbing the others.
What happens if my key leaks?
Whoever has it can make requests billed to your project. Delete the key immediately, create a replacement, and review usage for anything unexpected. A budget alert is what tells you this happened at all.
How do I move from AI Studio to Vertex AI?
Enable the Vertex AI API on a cloud project, create a service account with appropriate permissions, and change your client configuration to use project, location, and credentials rather than an API key. Prompts and request structures carry over, so the application logic largely stays as it is.
Why is my key not working in my region?
Availability differs by location, particularly on the free tier, and some models are not offered everywhere. Google's availability documentation lists the current position, and Vertex AI gives explicit regional control where this matters.
Does the free tier really allow human review of my prompts?
Google's free-tier terms permit use of the data for product improvement, which can include human review. Treat anything sent on the free tier as potentially readable, and keep confidential or customer data on paid usage where those terms do not apply.
Can I share one project between several teams?
You can, and quotas and billing are then shared, which means one team's load test is another team's outage and nobody can tell what they individually cost. A project per team, or at least per environment, is worth the small amount of extra setup.
What is the quickest way to check my account is working?
Make a single request from a terminal with the key in a header and a trivial prompt. If it returns content, the key, the project, the region, and your model access are all confirmed at once. Debugging that inside an application takes considerably longer.