Google añade los modos Flex y Priority a la API de Gemini para equilibrar precio y fiabilidad

El 2 de abril de 2026, Google añadió dos nuevos modos de servicio a la API de Gemini, Flex y Priority, para que los desarrolladores controlen con más precisión el precio, la latencia y la fiabilidad sin complicar su arquitectura. La idea es que las solicitudes en segundo plano y las críticas de cara al usuario se puedan separar ahora en distintos niveles de servicio mediante la misma interfaz síncrona, en lugar de montar circuitos distintos para la API Standard y la API Batch.

La compañía describe el problema de forma bastante terrenal. A medida que los casos de uso de IA pasan de simples chatbots a agentes y flujos de trabajo compuestos, los equipos suelen acabar con dos tipos de carga. El primero son las tareas en segundo plano: enriquecimiento masivo de datos, razonamientos largos del modelo, ejecuciones de investigación, actualizaciones de CRM y otros procesos en los que unos segundos de más no importan. El segundo son las solicitudes interactivas: chats de usuario, copilotos, moderación en tiempo real, bots de soporte y otras funciones que requieren una respuesta estable y una latencia predecible.

Hasta ahora, esta separación obligaba a menudo a combinar solicitudes síncronas normales en el producto con la API Batch para el procesamiento barato en segundo plano. Eso ahorraba dinero, pero añadía carga operativa: había que gestionar trabajos asíncronos, archivos de entrada y salida, y consultar periódicamente el estado de ejecución. Google afirma que Flex y Priority cierran esa brecha: ambas opciones funcionan con endpoints síncronos estándar y el cambio se hace con el parámetro `service_tier` en la solicitud.

Flex es un nuevo modo económico para tareas que toleran retrasos y una menor prioridad de ejecución. Google promete un ahorro de hasta el 50% frente a la API Standard, si el desarrollador está dispuesto a sacrificar parte de la fiabilidad y la velocidad de respuesta a cambio de un menor coste. Lo clave es que Flex no convierte el trabajo en un proceso batch aparte: sigue siendo una solicitud síncrona con el esquema de integración habitual.

La compañía propone usarlo para actualizaciones de CRM en segundo plano, simulaciones de investigación a gran escala y escenarios con agentes en los que el modelo puede «pensar» o «navegar» información en segundo plano. Según Google, Flex estará disponible en todos los planes de pago y es compatible con las solicitudes de GenerateContent y de la Interactions API.

Priority, en cambio, está pensado para el tráfico más sensible. Es un modo premium con el máximo nivel de garantía, que debe ayudar a las aplicaciones a superar los picos de carga sin que se desplacen las solicitudes críticas. Google afirma sin rodeos que estas solicitudes reciben el máximo nivel de criticidad, lo que implica más probabilidad de mantener un funcionamiento estable incluso cuando la plataforma está saturada.

Otro detalle importante es el mecanismo de degradación suave: si la aplicación supera los límites de Priority, las solicitudes excedentes no fallan con un error, sino que se atienden automáticamente en Standard. En producción, esto puede ser más importante que el propio SLA, porque reduce el riesgo de que una función se degrade por completo cuando llega una avalancha de usuarios.

Google también hace que Priority sea más transparente en términos de operación y facturación. La respuesta de la API indicará qué nivel procesó exactamente cada solicitud, de modo que el equipo pueda analizar el comportamiento del sistema, calcular costes y rastrear escenarios reales de degradación. Entre los casos típicos, la compañía cita bots de soporte en tiempo real, flujos de moderación en vivo y cualquier solicitud sensible al tiempo. En el lanzamiento, Priority estará disponible para proyectos de pago de los niveles Tier 2 y Tier 3 en la GenerateContent API y la Interactions API.

Para los desarrolladores, esta actualización importa por algo más que los precios. Google intenta, en la práctica, simplificar la decisión de ingeniería entre «barato» y «fiable» sin obligar a los equipos de producto a construir dos modelos de integración distintos. Si Flex realmente ofrece el ahorro prometido del 50% en tareas de fondo sin pasar a una arquitectura batch, podría abaratar los escenarios con agentes y los pipelines masivos. Y si Priority mantiene de forma estable el tráfico crítico en horas punta, la API de Gemini ganará un argumento más sólido para productos de cara al usuario donde los fallos afectan directamente a los ingresos y a la experiencia.

La conclusión principal es sencilla: Google convierte la API de Gemini de un canal estándar único en un sistema más flexible de clases de servicio. Para los equipos, eso supone poder separar de forma deliberada la carga de fondo y la crítica en la misma API, calcular mejor la economía por unidad y sobrellevar mejor los periodos de pico. Si el enfoque cuaja, la competencia entre plataformas de IA girará cada vez más no solo en torno a la calidad de los modelos, sino también a lo finamente que el proveedor sepa vender rendimiento, fiabilidad y coste para distintos escenarios de producto.