Google añadió los modos Flex y Priority a la API Gemini para equilibrar precio y confiabilidad

El 2 de abril de 2026, Google añadió dos nuevos niveles de servicio a la API de Gemini — Flex y Priority, permitiendo que los desarrolladores gestionen de forma más precisa el coste, la latencia y la confiabilidad sin complicar la arquitectura. La idea es que las solicitudes de fondo y críticas del usuario puedan ahora enrutarse a diferentes niveles de servicio a través de la misma interfaz síncrona, en lugar de construir canales separados para Standard API y Batch API. La empresa describe el problema en términos bastante prácticos.

A medida que los escenarios de IA evolucionan de simples chatbots hacia agentes y flujos de trabajo compuestos, los equipos típicamente enfrentan dos clases de cargas de trabajo. La primera es tareas de fondo: enriquecimiento masivo de datos, razonamiento prolongado del modelo, ejecuciones de investigación, actualizaciones de CRM y otros procesos donde segundos adicionales no son críticos. La segunda son solicitudes interactivas: chats de usuario, copilots, moderación en tiempo real, bots de soporte y otras funciones donde importan la respuesta estable y la latencia predecible.

Anteriormente, esta división a menudo requería combinar solicitudes síncronas regulares desde el lado del producto con Batch API para procesamiento económico de fondo. Esto proporcionaba ahorros, pero añadía overhead: había que gestionar trabajos asíncronos, archivos de entrada y salida, y encuesta de estado de ejecución. En Google, dicen que Flex y Priority cierran esta brecha: ambas opciones funcionan a través de puntos finales síncronos estándar, y el cambio ocurre a través del parámetro service_tier en la solicitud.

Flex es un nuevo modo económico para tareas que pueden tolerar latencia y menor prioridad de ejecución. Google promete ahorros de hasta el 50% comparado con Standard API si el desarrollador está dispuesto a sacrificar algo de confiabilidad y velocidad de respuesta por coste. El punto clave es que Flex no convierte el trabajo en un proceso batch separado: sigue siendo una solicitud síncrona con un patrón de integración familiar.

La empresa sugiere usar este modo para actualizaciones de CRM de fondo, simulaciones de investigación a gran escala y escenarios de agentes donde el modelo puede "pensar" o "revisar" información en segundo plano. Según Google, Flex estará disponible en todos los planes pagos y se soporta en solicitudes de GenerateContent e Interactions API. Priority, por el contrario, está diseñado para el tráfico más sensible.

Es un modo premium con nivel máximo de garantía, destinado a ayudar a las aplicaciones a manejar picos de carga sin desplazar solicitudes críticas. Google declara directamente que tales solicitudes reciben el nivel más alto de criticidad, lo que significa que hay una mejor oportunidad de mantener operación estable incluso cuando la plataforma está bajo carga. Otro detalle importante es el mecanismo de degradación suave: si una aplicación excede los límites de Priority, las solicitudes excedentes no fallan con error sino que se manejan automáticamente en nivel Standard.

Para producción, esto puede ser más importante que el propio SLA, porque reduce el riesgo de degradación completa de la función durante picos de usuarios. Al mismo tiempo, Google hace el modo Priority más transparente desde el punto de vista operativo y de facturación. La respuesta de la API indicará qué nivel exacto de procesamiento manejó la solicitud específica, para que el equipo pueda analizar el comportamiento del sistema, calcular costes y rastrear escenarios reales de degradación.

Entre los casos de uso típicos, la empresa menciona bots de soporte en tiempo real, canales de moderación en directo y cualquier solicitud sensible a la latencia. Al lanzamiento, Priority estará disponible para proyectos pagos en niveles Tier 2 y Tier 3 en GenerateContent API e Interactions API. Para los desarrolladores, esta actualización importa no sólo por los precios.

Google esencialmente está intentando simplificar la elección de ingeniería entre "económico" y "confiable", sin obligar a los equipos de producto a construir dos modelos de integración diferentes. Si Flex realmente entrega los prometidos ahorros del 50% en tareas de fondo sin cambiar a arquitectura batch, esto podría reducir el coste de escenarios de agentes y pipelines masivos. Y si Priority mantiene consistentemente el tráfico crítico estable durante horas pico, la API de Gemini ganará un argumento más fuerte para productos de consumidor donde las interrupciones impactan directamente en ingresos y experiencia del usuario.

La conclusión principal es simple: Google está convirtiendo la API de Gemini de un único canal estándar en un sistema más flexible de clases de servicio. Para los equipos, esto significa la capacidad de dividir conscientemente la carga crítica y de fondo en la misma API, calcular mejor la economía unitaria y pasar más suavemente por períodos de pico. Si el enfoque cuaja, la competencia entre plataformas de IA será cada vez más una cuestión no sólo de calidad del modelo, sino de qué tan finamente el proveedor sabe vender desempeño, confiabilidad y coste adaptados a diferentes escenarios de productos.