Vercel AI Gateway Adds Gemini Models and Service Tiers for Cost-Latency Control

Summary

Vercel has added Gemini 3.6 Flash and Gemini 3.5 Flash-Lite to AI Gateway while introducing service tiers for supported OpenAI and Gemini models. Together, the updates give teams more control over model selection and the trade-off between latency, throughput, and inference cost.

Vercel positions Gemini 3.6 Flash for coding, agentic workflows, and web development, claiming improved output with fewer tokens and model calls. Gemini 3.5 Flash-Lite targets lighter-weight agentic work, including subagents responsible for narrow parts of a larger task.

AI Gateway provides a common interface for model calls alongside usage and cost tracking, routing controls, retries, failover, reporting, and API-key budgets. Vercel says inference is billed at upstream provider list prices without an additional platform markup, including for Bring Your Own Key requests.

Key Updates

- Gemini 3.6 Flash and Gemini 3.5 Flash-Lite are available through the model identifiers google/gemini-3.6-flash and google/gemini-3.5-flash-lite.

- Service tiering is initially available for supported OpenAI and Gemini models across AI Gateway’s API formats.

- The available tiers are default for standard processing, priority for faster processing at a higher price, and flex for lower-cost workloads that can tolerate additional latency.

- Vercel estimates that priority processing costs approximately 1.8–2 times the default rate, while flex processing costs approximately half the default rate. Actual billing is based on the tier that serves the request.

- Tier selection is best-effort. When the requested tier is unavailable, AI Gateway can process the request on the default tier and return the tier actually used through provider metadata.

Why It Matters

The more important signal is not simply that two additional Gemini models are available. It is that workload-level economic decisions are becoming configurable at the request layer.

A team can use priority processing for latency-sensitive user interactions, default processing for ordinary application traffic, and flex processing for batch jobs or background agents. Because the tier option is exposed through the gateway rather than a provider-specific integration, teams can change supported models without redesigning the surrounding application logic.

That creates a more practical control surface for AI operations. Product and infrastructure teams can connect service-level objectives, workload priority, and budget policy to individual requests instead of treating every inference call the same way.

However, service tiers do not automatically reduce total costs. The result will depend on task success rates, token consumption, retries, fallback frequency, response latency, and the operational effect of slower processing. IBM Research similarly argues that model routing should be treated as a system optimization problem across cost, quality, and latency—not simply as a model-selection problem. Serving conditions, caching, provider load, and routing overhead can all affect end-to-end performance.

Builder Takeaway

Teams should treat service tiers as a policy layer to benchmark rather than an automatic cost optimization.

Start with representative workload categories:

- Interactive requests: Compare default and priority tiers using median and tail latency, output quality, throughput, and cost per successful request.

- Background and subagent work: Compare default and flex tiers using completion time, failure rate, fallback rate, token consumption, and cost per completed task.

- Model selection: Evaluate Gemini 3.6 Flash and Gemini 3.5 Flash-Lite against the same task set rather than assuming the lighter model will deliver the lowest total cost.

Record the tier actually returned in provider metadata because the requested tier may not be the one that serves the request. Define latency objectives, quality thresholds, and spending limits before automating tier selection. The strongest implementation will route according to measured workload characteristics—not model labels or headline token prices alone.