Google AI Studio is the right tool for exploring an AI idea, prototyping a working app, and showing what is possible. It is not the right tool for production deployment of an AI feature that real users will depend on. The boundary between "prototype that works" and "production system" has shifted in 2026 with AI Studio’s expanded Build mode and the new "ship to Cloud Run" deployment path, but the boundary is still meaningful for most non-trivial AI applications. When a prototype has outgrown what AI Studio can support as a production surface, the standard graduation path is to Vertex AI, Google Cloud’s production AI platform.
This piece walks through the graduation pattern. We cover what AI Studio and Vertex AI are designed for, the concrete differences in API surface, the code changes required to migrate a typical AI Studio prototype, the operational decisions that move from defaults to explicit configuration, the integration patterns with the broader Google Cloud surfaces that production deployment usually reaches for, and the cost considerations that shift from AI Studio’s generous free tier to Vertex AI’s usage-based production pricing. The goal is a working migration playbook for teams whose prototype has succeeded and now needs to handle real production load.
What changes between the two services
AI Studio and Vertex AI both provide access to Gemini models. They are operated by the same Google AI Platform backend and they share the same model catalog. The differences are at the platform layer: how applications authenticate, where requests go, how billing works, what operational controls are available, and what the production support story is.
AI Studio’s API surface is simple. Applications use an API key, point to the AI Studio endpoint, send requests, and get responses. The endpoint URL is generativelanguage.googleapis.com. The API key is generated in the AI Studio UI and is a single string that authorizes all requests. The billing flows through the AI Studio billing relationship, with the free tier generous enough that many prototyping workloads stay within it.
Vertex AI’s API surface is more elaborate. Applications use a Google Cloud service account or IAM-managed credentials, point to a region-specific Vertex AI endpoint, send requests scoped to a Google Cloud project, and get responses. The endpoint URL is regional, taking the form <region>-aiplatform.googleapis.com. Authentication uses Google Cloud’s standard IAM model, which means an application identity rather than a single API key. The billing flows through the Google Cloud project’s billing account, using Google Cloud’s full billing infrastructure.
The simplification of AI Studio is the right design for prototyping. The elaboration of Vertex AI is the right design for production. The migration from AI Studio to Vertex AI is the process of moving from the simpler surface to the more capable one. The capabilities you gain in the migration are the ones that production deployment needs (IAM-based access control, regional deployment, quota management, observability, governance). The simplicity you give up is appropriate for production but not for prototyping.
The code changes
The most common AI Studio prototype is a Node.js or Python application that calls the AI Studio API to invoke Gemini. The migration to Vertex AI involves changing the endpoint, changing the authentication, and (in most cases) changing the SDK package.
For a Node.js application using the @google/generative-ai package (which is the SDK for the AI Studio API), the migration is to the @google-cloud/vertexai package (which is the SDK for Vertex AI). The two SDKs have similar but not identical interfaces. A typical AI Studio call looks like:
import { GoogleGenerativeAI } from "@google/generative-ai";
const genAI = new GoogleGenerativeAI(process.env.AI_STUDIO_API_KEY);
const model = genAI.getGenerativeModel({ model: "gemini-3-pro" });
const result = await model.generateContent("Summarize this document...");The equivalent Vertex AI call looks like:
import { VertexAI } from "@google-cloud/vertexai";
const vertexAI = new VertexAI({
project: process.env.GCLOUD_PROJECT,
location: "us-central1",
});
const model = vertexAI.getGenerativeModel({ model: "gemini-3-pro" });
const result = await model.generateContent("Summarize this document...");The differences are in the construction (Vertex AI takes a project and location rather than an API key), in the authentication (Vertex AI uses the ambient Google Cloud credentials from the environment), and in the SDK package (different npm package). The actual call surface (getGenerativeModel, generateContent) is the same.
For Python applications, the migration is from the google-generativeai package to the google-cloud-aiplatform package. The patterns are analogous to the Node.js case.
A practical observation is that maintaining two code paths (one for AI Studio in development, one for Vertex AI in production) is unusual. The typical pattern is to migrate the entire codebase to Vertex AI and run against Vertex AI in development as well as production. The Vertex AI free tier through Google Cloud has enough credit to cover normal development needs.
Authentication migration
The authentication change is the operationally significant one. AI Studio uses a single API key. Vertex AI uses Google Cloud’s IAM system, which means application identities are tied to service accounts and access is scoped through IAM roles.
For a Cloud Run deployment, the application runs as a service account. The service account is granted the roles/aiplatform.user IAM role on the Google Cloud project, which permits Vertex AI access. The application code does not handle credentials directly; the Google Cloud SDK automatically uses the ambient service account credentials.
For a local development environment, the developer typically uses Application Default Credentials, set up through gcloud auth application-default login. This gives the developer’s local environment access to the configured Google Cloud project’s resources, including Vertex AI, without requiring API keys to be in the local environment.
For deployments outside Google Cloud (a Vercel app, an AWS Lambda function, a self-hosted Kubernetes cluster), the application authenticates with a service account JSON key downloaded from Google Cloud IAM and stored as a secret in the deployment environment. The application loads the service account key at startup and uses it to authenticate with Vertex AI. This pattern requires more care around key management than the Google-Cloud-native pattern but works the same way logically.
A specific consideration is that the Google Cloud service account key, like any credential, should be handled through whatever secrets backend the deployment environment supports (Vercel environment variables, AWS Secrets Manager, Kubernetes Secrets) rather than being checked into source control. This is the standard secret-handling guidance and applies the same way to Vertex AI credentials as to any other credential.
Regional deployment
Vertex AI is region-aware in a way that AI Studio is not. AI Studio’s endpoint is global with Google’s underlying infrastructure routing to the right place. Vertex AI’s endpoint is per-region: a request to us-central1-aiplatform.googleapis.com is processed in the Iowa region; a request to europe-west4-aiplatform.googleapis.com is processed in the Netherlands region; and so on.
The regional choice has three consequences. The first is latency: a request from a user in Europe to a US-region Vertex AI endpoint incurs cross-Atlantic latency. The second is data residency: data sent to a region stays in that region for processing, which matters for regulatory compliance in jurisdictions with data-residency requirements. The third is feature availability: some Vertex AI features are not available in all regions, and the model catalog can vary by region (the smaller regions tend to lag the major regions in newest-model availability).
The right region choice for a production deployment depends on the application’s user base, the regulatory requirements, and the feature requirements. A globally-distributed application typically deploys to multiple Vertex AI regions and routes requests to the geographically nearest. A regionally-scoped application deploys to a single region close to its users. A regulated application deploys to a region in the regulated jurisdiction.
Multi-region deployment is operationally meaningful. The application needs region routing logic, and the deployment needs IAM roles granted per region. Google Cloud’s regional architecture is the model for this; teams familiar with multi-region Cloud Run or GKE will find the Vertex AI multi-region patterns natural.
Auto-scaling and quotas
AI Studio’s quota model is invisible to the user beyond a free-tier cap and a per-API-key rate limit. Vertex AI’s quota model is explicit and configurable.
Vertex AI quotas are set per Google Cloud project per region per model. The default quotas are reasonable for typical workloads (typically 60 requests per minute for the major models in the major regions, with some variation by model and region) but are insufficient for high-volume applications. Quota increases are requested through Google Cloud’s quota request flow.
The quota request flow is more bureaucratic than the AI Studio "just hit the API harder" pattern. A quota increase request specifies the project, the region, the model, the desired quota, and the business justification. Approvals typically take a few business days for moderate increases and longer for large increases. The implication is that capacity planning for Vertex AI production deployment requires explicit advance work that AI Studio prototyping does not.
A second consideration is that Vertex AI supports provisioned throughput for high-volume applications. Provisioned throughput is a commitment to a baseline level of capacity that the application pays for whether or not it uses, in exchange for guaranteed availability of that capacity. For applications with predictable high volumes, provisioned throughput can be cheaper per request than on-demand and avoids the quota-limit issues that on-demand can hit at peak times.
Auto-scaling for the application itself (as opposed to the Vertex AI capacity) is handled by whatever deployment surface the application uses. Cloud Run auto-scales the application instances based on request volume; the Vertex AI side scales independently within the project quotas. Both layers need to be sized for the expected load.
Observability
AI Studio has a usage dashboard that shows token consumption and request count. Vertex AI integrates with the full Google Cloud observability stack: Cloud Logging for request logs, Cloud Monitoring for metrics, Cloud Trace for distributed tracing, Error Reporting for application errors.
The richness of the observability is one of the meaningful gains in the migration. Production AI workloads benefit substantially from being able to see request rates, latency distributions, error rates, and token consumption patterns. Cloud Monitoring exposes Vertex AI-specific metrics (per-model request count, per-model token consumption, per-model error rate) that production operations needs.
The observability integration is mostly automatic. A Vertex AI request from an authenticated application is logged in Cloud Logging with the request metadata. The metrics are available in Cloud Monitoring without additional configuration. The integrations with Cloud Trace and Error Reporting require small amounts of application-side instrumentation but are straightforward.
A specific operational pattern that the observability stack enables is per-feature cost attribution. A production application that uses Vertex AI for several distinct features (summarization, chat, translation, code generation) can tag each Vertex AI request with a feature label, and Cloud Monitoring can produce a per-feature cost breakdown. This visibility is critical for understanding which features are driving cost growth and where optimization effort should focus.
Integration with broader Google Cloud
Production AI deployment typically reaches for several other Google Cloud services beyond Vertex AI. The common integrations:
Cloud Run hosts the application that calls Vertex AI. Cloud Run is the simplest of the Google Cloud compute options and is the typical first choice for HTTP-serving applications. It auto-scales, handles TLS, and integrates natively with the rest of the Google Cloud stack.
Cloud Storage holds artifacts that the application uses or produces. A summarization application might pull source documents from a Cloud Storage bucket and write summaries to another bucket. The IAM integration with Vertex AI means the same service account that calls Vertex AI can be granted access to the relevant buckets through a single permissioning pattern.
BigQuery holds analytics data that the application produces or queries. A common pattern is to log every Vertex AI request to BigQuery with the request metadata, the response token counts, and the cost. BigQuery’s analytics capability over time supports cost attribution, performance analysis, and capacity planning.
Cloud Build runs the application’s CI/CD pipeline. The typical pattern is to push code to a GitHub repository, which triggers a Cloud Build pipeline that runs tests, builds the application container, and deploys to Cloud Run. The pipeline can include Vertex AI evaluation steps that test the application’s AI behavior on a held-out set before deployment.
Cloud Run for Anthos or GKE for applications that need more control than Cloud Run provides. The Vertex AI integration works the same way (IAM-scoped service account, regional endpoints) regardless of which compute platform is used.
The pattern that has settled out is that production AI applications on Google Cloud use Cloud Run as the default hosting choice, Cloud Storage for artifacts, BigQuery for analytics, and Cloud Build for CI/CD. The teams that diverge from this pattern usually do so because they have a specific operational requirement that one of the alternatives serves better.
Cost considerations
The shift from AI Studio’s free tier to Vertex AI’s usage-based pricing is the cost change that most surprises teams making the migration. AI Studio’s free tier is generous enough that many prototyping workloads do not exceed it. Vertex AI charges from the first request, with pricing aligned with the standard Gemini API pricing through the Google AI Platform.
The Gemini API pricing in mid-2026, for the major models, is approximately $4 per million input tokens and $20 per million output tokens for Gemini 3 Pro, $0.40 per million input tokens and $2.40 per million output tokens for Gemini 3 Flash. The exact pricing varies by region and is subject to change; Google’s pricing page is the authoritative reference.
For a production workload at moderate scale, the Vertex AI costs are typically the largest single line item in the Google Cloud bill, often by a large margin. Compute costs (Cloud Run, GKE), storage costs (Cloud Storage), and analytics costs (BigQuery) typically come in well below the Vertex AI line. Teams making the migration should plan for the Vertex AI cost to be the dominant cost in production.
Cost mitigation patterns include using cheaper models for lower-stakes work (Flash for classification and simple summarization, Pro only for the highest-capability work), caching responses when the same prompt is sent repeatedly (Cloud Memorystore is the typical caching layer), using Vertex AI’s batch API for non-realtime work (which is meaningfully cheaper than the real-time API), and using provisioned throughput for predictable high-volume workloads (which is cheaper per request than on-demand if used efficiently).
The cost transition from AI Studio to Vertex AI is not a reason to delay the migration. The free tier of AI Studio is appropriate for prototypes; the cost of Vertex AI is appropriate for production. Teams should plan for the cost change as part of the migration plan rather than being surprised by it.
When not to migrate
Most prototypes that succeed end up needing the migration to Vertex AI. There are situations where staying on AI Studio is appropriate.
The first is when the application stays a prototype indefinitely. Internal-only tools, exploratory projects, or experiments that are unlikely to become production systems can stay on AI Studio. The simplicity advantages of AI Studio matter more than the production capabilities of Vertex AI for these cases.
The second is when the application is small enough that the AI Studio free tier and rate limits are sufficient. A consumer side-project that gets a few hundred requests per day can stay on AI Studio for its entire useful life.
The third is when the application has been built into one of AI Studio’s new "ship to Cloud Run" deployment paths and the deployment is already production-ready through that path. The 2026 expansion of AI Studio’s production capabilities has reduced the cases where an explicit Vertex AI migration is necessary, though the explicit migration remains the typical path for non-trivial applications.
Frequently asked questions
Can I use Vertex AI without using other Google Cloud services? Yes. Vertex AI is an independent service that can be called from any application that can authenticate with a Google Cloud service account. The application can run on AWS, on a self-hosted server, or anywhere else with internet access.
Does Vertex AI support the same Gemini models as AI Studio? Yes. The model catalogs are aligned. Newest-model availability sometimes hits AI Studio first by a few days, but the production-stable models are available identically through both surfaces.
Can I keep using my AI Studio API key with Vertex AI? No. AI Studio API keys and Vertex AI credentials are separate. The migration requires setting up the new credentials. Existing AI Studio API keys continue to work against AI Studio after the migration but are not accepted by Vertex AI.
Is the response format the same between AI Studio and Vertex AI? Yes. The structured response from both APIs is the same shape. Applications that have processed AI Studio responses do not need to change their response-handling code beyond the SDK swap.
How long does the migration typically take? For a simple application, the migration is a few hours of work plus a day or two of testing. For a complex application with substantial integration with Google Cloud’s other services, the migration can be a multi-week project. Most migrations fall in the 1-2 week range when CI/CD setup and observability integration are included.
Can I run Vertex AI in a different Google Cloud project than the rest of my application? Yes, though this is unusual. The standard pattern is to put Vertex AI in the same project as the application that uses it for simpler IAM management. Cross-project Vertex AI access works but requires additional IAM configuration.
Does Vertex AI support the same fine-tuning capabilities as AI Studio? Vertex AI supports more fine-tuning capabilities than AI Studio, including the supervised fine-tuning and the RLHF flows. Applications that use the basic fine-tuning available in AI Studio will find equivalent capability in Vertex AI; applications that need advanced fine-tuning capabilities will find them in Vertex AI but not in AI Studio.
Is there a "Vertex AI Lite" tier for smaller deployments? Not formally. The closest equivalent is using Vertex AI with Cloud Run and accepting the usage-based pricing. The Vertex AI free tier through Google Cloud’s normal free credit applies, which gives a usage allowance that covers small workloads’ development needs.
