Your prototype ran all weekend on an API key from Google AI Studio. You flip the client over to Vertex AI, change nothing else, run it, and the first call comes back 403. Same model, same prompt, same SDK. The key is the problem. Vertex AI does not accept an AI Studio key, because it wants a Google Cloud identity, not a string you pasted from a web page.

That single 403 is the whole story of this part. Google gives you two front doors to the exact same Gemini models, and the model is the least interesting difference between them. What changes is who you authenticate as, where your prompt is processed, whose quota you spend, and who signs the contract. Get the door right and migration is a one line change. Get it wrong and you rebuild auth the week before launch.

Two front doors to the same models

Start with the names, because Google uses three of them and they overlap. Google AI Studio is a browser tool at aistudio.google.com where you type a prompt, pick a Gemini model, and get an API key with two clicks. The Gemini Developer API is the endpoint that key calls, served at generativelanguage.googleapis.com. Think of AI Studio as the front desk and the Developer API as the phone line behind it. They are the same door.

The second door is Vertex AI, Google Cloud's managed platform for building and serving models, which we have used since Part 2. Vertex serves the same Gemini models through its own endpoint at aiplatform.googleapis.com, but the request lands inside a Google Cloud project with its billing account, its IAM policy, its quota, its audit logs, and its network controls wrapped around every call. The model on the far end is the same Gemini. The machinery around the call is not.

Google now labels the Vertex generative offering the Gemini Enterprise Agent Platform in some of its docs, but the endpoint, the SDK path, and the product most people say out loud are still Vertex AI, so that is what I use here. The picture below is the whole mental model. Two doors, one set of models.

What actually changes when you switch doors

People expect the models to differ between the two doors. They mostly do not. What differs is everything wrapped around the call. Here is the side by side I keep in my head, row by row, for the questions that actually decide a project.

Rows verified against Google's migrate-to-Vertex documentation for this run. Feature availability shifts, so confirm residency and provisioned throughput on the current docs before you promise them.

Read that table top down and a pattern falls out. Every row where the Developer API says no or limited is a row an enterprise cares about, and every row where it wins is a row a solo builder cares about. That is not an accident. Google built the Developer API to remove friction for the first hour and built Vertex to satisfy an auditor for the next three years. Neither is better. They are aimed at different weeks of the same project.

How the two handle authentication

Authentication is the difference you feel first, and it is the 403 in the opener. The Developer API takes an API key, a long string tied to a project that grants whoever holds it the right to call. It is fast because it skips identity. It is risky for the same reason: a key in a leaked commit is a working credential until someone rotates it, and it carries no notion of which human or service is calling.

Vertex AI authenticates with a Google Cloud identity. In development that means Application Default Credentials, or ADC, a local credential you create once by running a login command, after which the SDK finds it automatically. In production it means a service account, a non human identity with a narrow IAM role such as Vertex AI User, attached to the workload so there is no key to leak at all. Every call is then tied to a principal you can see in the audit log, revoke in one click, and scope to a single project. That is the trade: a minute of setup for an identity you can actually govern.

Google has been adding an express mode that lets Vertex accept an API key for a faster start, which blurs this line a little. It is handy for a quick trial, but it is not the identity model you want under production traffic, so treat it as a convenience, not the destination.

Where your data goes, and who governs it

This is the row that ends most debates, and it is the one people skip because it is boring until it is a lawsuit. The question is simple: after your prompt reaches Google, where is it processed, and can Google use it to improve its models. The answer depends on the door and, for the Developer API, on whether you are on the free tier.

On the free tier of the Gemini Developer API, Google may use your prompts and responses to improve its products. That is the price of free, and it is fine for a throwaway demo and disqualifying for anything touching customer data. On the paid tier of the Developer API, Google states it does not use your data to train its models. Vertex AI goes further: your data is not used to train Google's models, and you also get region pinning so the request is processed where you say, VPC Service Controls to keep the traffic inside a perimeter you draw, and customer managed encryption keys if you want to hold the key yourself.

Data-use behaviour verified against Google's Gemini API terms and Vertex AI data governance docs for this run. Terms change, so re-read them before a compliance sign-off.

Does the bill change between them?

Barely, and that surprises people who assume the enterprise door costs more. Both doors bill Gemini per token at rates that track each other closely, the same input and output token model we priced in Part 3. The Developer API adds a free tier the enterprise door does not have, and Vertex adds reserved-capacity options the Developer API does not, but for ordinary pay as you go traffic the per token number is close enough that price is not the deciding factor. Here is a workload priced on both.

Quotas are where the free door bites, not price. The free Developer tier caps you at a low ceiling of requests per minute, enough to build against and nowhere near enough to serve users. Paid tiers on the Developer API raise that ceiling in steps as your spend history grows. Vertex quota is per project and per model, visible in the console, and you file for an increase against a specific model in a specific region. If you have hit a wall on the free tier, that wall is a rate limit, and the fix is either enabling billing on the Developer API or moving to Vertex, not a bigger key.

One SDK, one flag to move

Here is the good news that makes the whole choice low risk. Google ships a single client library, the Google Gen AI SDK, published as google-genai, that talks to both doors. Your prompt code, your streaming, your function calling, your tool definitions all stay the same. The only thing that changes between the Developer API and Vertex is how you build the client. Google states plainly that code written for one door runs on the other, so the migration is a constructor swap, not a rewrite.

The snippet below builds both clients side by side and calls the same model through each. In real code you build one, chosen by an environment variable, so the same image runs against the Developer API in dev and Vertex in prod with no code change.

# pip install google-genai
from google import genai

# Door 1: Gemini Developer API, auth is one API key from AI Studio
dev = genai.Client(api_key='AIza...your-studio-key')

# Door 2: Vertex AI, auth is your Google Cloud identity via ADC
# run once first:  gcloud auth application-default login
vertex = genai.Client(
    vertexai=True,
    project='my-genai-project',
    location='us-central1',
)

MODEL = 'gemini-2.5-flash'   # same id works through both clients

def ask(client, prompt):
    r = client.models.generate_content(model=MODEL, contents=prompt)
    return r.text

print(ask(dev, 'Give me a one line refund policy.'))     # prototype path
print(ask(vertex, 'Give me a one line refund policy.'))  # production path

Expected output: the same kind of one line answer printed twice, because the model is identical across both clients. Only the constructor changed. Failure modes: on the Vertex client a 403 PERMISSION_DENIED means ADC is not set, so run the gcloud login line, or the Vertex AI API is not enabled on the project; a 404 means the model id does not serve from your location, so pick a region where it does. On the Developer client a 400 with API_KEY_INVALID means the key is wrong or the Generative Language API is not enabled on the key's project.

Which door for which stage of the build

The clean way to think about this is not one door versus the other, it is which door fits the stage you are at. A weekend prototype has no auditor and no users, so the Developer API key is exactly right. A pilot with real internal users has data you cannot leak, so paid Developer or Vertex. Anything with external customers or a compliance line gets Vertex, full stop. Map the door to the stage and the choice stops being a debate.

This is the same shape of question you hit on other clouds, where the choice is which managed service a project belongs in rather than which model. If you are comparing across providers, the Azure piece on Azure OpenAI versus Foundry versus Azure Machine Learning walks the same decision on Microsoft's stack, and the vendor neutral Generative AI guide covers the token and pricing basics under all of them.

Prototype in AI Studio, ship on Vertex AI

Here is my recommendation without the hedge. Start every Gemini idea in Google AI Studio with a Developer API key, because nothing gets you to a working call faster and the friction of Vertex setup will kill a prototype that has not proven itself yet. Keep that key on your machine, never in a repo, and only ever feed it test data. The instant the project earns real users or real data, move it to Vertex AI on a service account, because that is where IAM, region pinning, audit logs, and a raiseable quota live, and those are the things a launch actually needs. Because it is one SDK and one flag, you can make that move in an afternoon rather than a sprint.

Do not treat the free tier as a cost saving for anything real, because the training clause on your prompts is a data path, not a discount. And do not reach for Vertex on day one for a toy, because you will spend your first hour on IAM instead of on the idea. The next part goes deeper on the Vertex side of the wall, into pricing, provisioned throughput, and context caching, where the reserved capacity and cache options that the Developer door does not have start to change your bill. Your move today: find every AI Studio key in your projects and check what data has passed through it, because that audit takes ten minutes and tells you which ones need to move to Vertex this week.

References

• Migrate from the Gemini Developer API to Vertex AI, Google AI for Developers
• Google Gen AI SDK overview, Google Cloud documentation
• Gemini API rate limits and tiers, Google AI for Developers
• Cross-series: Azure OpenAI vs Foundry vs Azure Machine Learning

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts