Gemini API adds a half-price Flex tier and a Priority tier that costs up to double

Google has added two new inference tiers to the Gemini API, according to an entry on the Gemini API changelog. Flex charges half the standard rate for slower, best-effort responses, while Priority charges more for low latency.

The changelog describes the change in one line: it introduces the Flex and Priority tiers, “offering more options for optimizing cost or latency.” The entry is dated April 1, 2026, and links to separate documentation pages for each tier. Those pages carry the specifics below.

Flex trades waiting time for half the price

According to Google’s Flex documentation, the tier is billed per token at 50% of standard API rates. Requests stay synchronous, but latency varies: the page gives a target of 1 to 15 minutes, against seconds for Standard and Priority and up to 24 hours for Batch.

Developers opt in by setting service_tier to "flex" in a request. Leaving the field out means the request runs on Standard.

The catch is reliability. Google says Flex traffic is sheddable, so requests can be preempted during Standard traffic spikes, and callers may see 503 (at capacity) or 429 (rate or resource limits) errors. The documentation states that the system will not automatically upgrade a Flex request to Standard if Flex capacity is full. Developers must write their own retries with exponential backoff and raise client timeouts to 10 minutes or more. Flex also counts toward general rate limits and does not get the extended limits that Batch has.

Google positions it for offline evaluations, background agents and budget-limited research.

Priority pays a premium for steadier service

Priority is the opposite trade. The documentation labels it a preview, bills per token at 75-100% more than Standard, and targets seconds-level responses for interactive, user-facing apps. Its traffic is treated as the highest criticality and is non-sheddable. It is enabled with service_tier set to priority.

Priority has its own rate limits, set by default at 0.3x the standard limit for each model and tier. When a customer exceeds them during congestion, overflow requests are downgraded to Standard processing instead of returning a 503 or 429, and billed at the Standard rate. Google advises watching the x-gemini-service-tier response header to see how often that happens.

Both tiers list the same ten models, including Gemini 4 Argon, Gemini 3.8 Flash, Gemini 3.6 Flash, Gemini 3.1 Pro Preview and the 2.5 family. The Priority page does not set out separate eligibility requirements.

Strategy: One API, a price ladder by urgency

The tiers turn the Gemini API into a ladder: Flex for work that can wait, Standard in the middle, Priority for work that cannot, and Batch for jobs that can take up to a day. That fills a gap in the lineup. Until now, developers who wanted lower prices mostly had to move to asynchronous batch jobs, which Google has also been making easier to run. As we reported, the API now notifies a server when batch jobs finish. Flex offers a cheaper option that keeps the familiar request-and-response pattern.

It also fits how developers are already cutting costs. Google described a test in which a cheap classifier sent easy coding tasks to Flash-Lite. A service tier is another lever on the same bill: routing by model size and routing by urgency can be combined.

Priority’s downgrade behavior is the detail that matters most for production teams. Because overflow silently falls back to Standard, an application keeps working but may not get the latency it paid for, so the tier header becomes a monitoring signal. Flex has no such cushion, so workloads on it must tolerate failures.

What the documentation leaves open

The pages do not say how often Flex requests are preempted or how long queues run in practice; the 1 to 15 minute figure is a target, not a guarantee. Priority is still in preview, and its premium is given as a range (75-100%) rather than a fixed price, so the exact cost per model has to be checked on Google’s pricing pages. The changelog entry itself is also undated beyond April 1, 2026, and we have not verified Google’s latency or reliability claims independently.