Google adiciona modos Flex e Priority à API do Gemini para equilibrar preço e confiabilidade

Em 2 de abril de 2026, o Google adicionou dois novos modos de atendimento à API do Gemini, Flex e Priority, para que os desenvolvedores controlem com mais precisão preço, latência e confiabilidade sem complicar a arquitetura. A ideia é que requisições em segundo plano e requisições críticas voltadas ao usuário possam agora ser separadas em níveis de serviço diferentes pela mesma interface síncrona, em vez de montar circuitos distintos para a API Standard e a Batch API.

A empresa descreve o problema de forma bem pé no chão. À medida que os casos de uso de IA saem de chatbots simples e chegam a agentes e fluxos de trabalho compostos, as equipes costumam acabar com duas classes de carga. A primeira é a de tarefas em segundo plano: enriquecimento massivo de dados, raciocínios longos do modelo, rodadas de pesquisa, atualizações de CRM e outros processos em que alguns segundos a mais não fazem diferença. A segunda é a de requisições interativas: chats de usuários, copilotos, moderação em tempo real, bots de suporte e outras funções que exigem resposta estável e latência previsível.

Antes, essa separação costumava exigir a combinação de requisições síncronas comuns no produto com a Batch API para processamento barato em segundo plano. Isso gerava economia, mas trazia custo operacional: era preciso gerenciar jobs assíncronos, arquivos de entrada e saída e consultas periódicas ao status de execução. O Google afirma que Flex e Priority fecham essa lacuna: as duas opções funcionam por endpoints síncronos padrão, e a troca é feita pelo parâmetro `service_tier` na requisição.

O Flex é um novo modo econômico para tarefas que toleram atraso e menor prioridade de execução. O Google promete economia de até 50% em relação à API Standard, se o desenvolvedor aceitar abrir mão de parte da confiabilidade e da velocidade de resposta em troca de custo menor. O ponto-chave é que o Flex não transforma o trabalho em um processo batch separado: continua sendo uma requisição síncrona, com o esquema de integração habitual.

A empresa sugere usá-lo em atualizações de CRM em segundo plano, simulações de pesquisa em larga escala e cenários com agentes em que o modelo pode "pensar" ou "navegar" por informações em segundo plano. Segundo o Google, o Flex estará disponível em todos os planos pagos e é compatível com requisições GenerateContent e Interactions API.

O Priority, por sua vez, é voltado ao tráfego mais sensível. É um modo premium com o maior nível de garantia, que deve ajudar aplicações a atravessar picos de carga sem que requisições críticas sejam deslocadas. O Google diz abertamente que essas requisições recebem o mais alto nível de criticidade, o que aumenta a chance de manter a operação estável mesmo quando a plataforma está sobrecarregada.

Outro detalhe importante é o mecanismo de rebaixamento suave: se o aplicativo ultrapassar os limites do Priority, as requisições excedentes não falham com erro, mas são atendidas automaticamente no Standard. Em produção, isso pode ser mais relevante que o próprio SLA, porque reduz o risco de degradação total de uma função num momento de pico de usuários.

O Google também deixa o Priority mais transparente do ponto de vista de operação e cobrança. A resposta da API indicará qual nível processou cada requisição, de modo que a equipe possa analisar o comportamento do sistema, calcular custos e acompanhar cenários reais de degradação. Entre os casos típicos, a empresa cita bots de suporte em tempo real, pipelines de moderação ao vivo e quaisquer requisições sensíveis ao tempo. No lançamento, o Priority estará disponível para projetos pagos dos níveis Tier 2 e Tier 3 na GenerateContent API e na Interactions API.

Para os desenvolvedores, a atualização importa por mais do que os preços. O Google tenta, na prática, simplificar a escolha de engenharia entre "barato" e "confiável", sem obrigar as equipes de produto a construir dois modelos de integração diferentes. Se o Flex realmente entregar a economia prometida de 50% em tarefas de fundo sem exigir uma arquitetura batch, pode baratear cenários com agentes e pipelines em massa. E se o Priority conseguir sustentar de forma estável o tráfego crítico nos horários de pico, a API do Gemini ganha um argumento mais forte para produtos voltados ao usuário, nos quais falhas afetam diretamente a receita e a experiência.

A conclusão principal é simples: o Google está transformando a API do Gemini de um canal padrão único em um sistema mais flexível de classes de serviço. Para as equipes, isso significa poder separar de forma consciente a carga de fundo e a crítica na mesma API, calcular melhor a economia unitária e atravessar os períodos de pico com mais tranquilidade. Se a abordagem pegar, a concorrência entre plataformas de IA passará a girar cada vez mais não só em torno da qualidade dos modelos, mas também da sofisticação com que o provedor consegue vender desempenho, confiabilidade e custo para diferentes cenários de produto.