Google’s Gemini API gets Flex and Priority tiers — here’s what changed

Google just rolled out two new inference tiers for the Gemini API: Flex and Priority. If you’ve been using the API, you already know the default is a one-size-fits-all approach that tries to balance speed and cost. That works for a lot of cases, but it’s not ideal when you’re building something that cares a lot about one or the other.

Priority is the expensive, fast lane. It’s for when you need a response right now — think real-time chat, voice interactions, or any user-facing feature where a half-second delay feels like an eternity. You pay more, you get the compute reserved for you. Simple.

Flex is the opposite. It’s cheaper, but you don’t get any latency guarantees. Google says it’ll process your request when capacity allows, which means it’s fine for batch jobs, background processing, or anything where a few extra seconds won’t ruin the experience. I’ve seen this pattern before in cloud services — it’s essentially a spot instance model for LLM inference.

The real question is whether the price difference is big enough to make Flex worth the hassle. If you’re doing heavy data processing overnight, sure. But if your users are waiting for a response, don’t cheap out. I’ve tried similar tiers from other providers and the savings are real, but the unpredictability gets old fast.

Google didn’t publish exact pricing yet, but they confirmed the tiers are available now for Gemini 1.5 Pro and Flash models. No word on when older models get it. If you’re already on the API, check your dashboard — it should show up as an option in the request parameters.

One thing I appreciate: this isn’t a lock-in move. You can switch between tiers per request, so you could use Flex for data prep and Priority for the actual user-facing calls. That kind of flexibility is what makes APIs worth building on.

I’d still like to see clearer guidance on what “when capacity allows” actually means in practice. Google says Flex requests might get queued during peak hours, but they don’t specify how long that queue can get. If you’re planning to rely on Flex for anything time-sensitive, I’d test it thoroughly first.

Overall, this is a solid addition. It doesn’t revolutionize anything, but it gives developers more control over their cost-performance tradeoffs. And in a world where every API call costs real money, that’s a welcome change.