Gemini API suma Flex y Priority: como elegir costo o confiabilidad sin partir tu arquitectura de agentes

Google publico el 2 de abril de 2026 una de esas mejoras que parecen menor si solo miras pricing, pero pegan directo en arquitectura: Gemini API ahora tiene los tiers Flex y Priority.

La pregunta útil no es “cual es más barato”. La pregunta útil es otra: que partes de tu agente necesitan confiabilidad alta y que partes pueden esperar o degradarse un poco sin romper la experiencia.

El problema que Google esta intentando resolver

Cuando un equipo serio monta agentes, casi siempre aparecen dos clases de trabajo:

• tareas de fondo, más baratas y menos urgentes;
• tareas interactivas, donde una respuesta tarde o un fallo pega directo en producto.

Google dice que hasta ahora esa separacion empujaba a dividir la arquitectura entre endpoints sincronicos y Batch API. Con Flex y Priority, intentan cerrar esa grieta usando el mismo interfaz sincronico pero con distinto nivel de criticidad.

Traducido a builder:

• Flex sirve para trabajo tolerante a latencia;
• Priority sirve para trafico donde fallar o degradar cuesta más.

Como leer Flex sin romantizarlo

Google presenta Flex como una capa de ahorro para workflows menos sensibles. La parte que atrae clics es el recorte de precio. La parte que de verdad importa es que no obliga a rehacer toda la integración como batch asincrono.

Eso abre casos utiles para:

• enrichment de CRM;
• simulaciones largas;
• evaluaciones;
• browses de agente en background;
• y procesos donde el usuario no esta esperando frente a pantalla.

El error común sería mover todo a Flex “porque cuesta menos”. Si tu flujo necesita respuesta estable o visible al usuario, el ahorro se vuelve deuda de producto.

Y como leer Priority sin comprar humo

Priority no es magia. Es una forma de decirle a la plataforma: este trafico es el que no quiero perder cuando hay presion de carga.

Google añade una pieza operativamente valiosa: si excedes los limites de Priority, el overflow puede bajar a Standard en vez de fallar directo. Para equipos que exponen agentes en soporte, moderacion o asistentes internos con SLA, eso vale más que una promesa abstracta de performance.

Lo importante no es solo elegir Priority. Lo importante es decidir que paso del workflow merece Priority:

• la respuesta visible al usuario;
• la revision final antes de ejecutar una acción;
• o la parte que bloquea una aprobacion humana.

La noticia no viaja sola: también hay spend caps

Dos semanas antes, el 16 de marzo de 2026, Google anuncio Project Spend Caps en AI Studio y cambios en Usage Tiers. Esa segunda pieza importa porque el tiering sin control de gasto se vuelve una invitacion a sorpresas en factura.

Google dice que ahora puedes poner un tope mensual por proyecto, con un retraso aproximado de 10 minutos para que el cap termine de aplicarse. Tambien automatiza la progresion de Usage Tiers y muestra mejor visibilidad de limites y billing.

Visto junto, el mensaje es claro: Google no solo quiere vender agentes; quiere que los builders separen trabajo por criticidad y presupuesto.

Mi criterio para usarlo bien

Si montara un agente hoy con Gemini, partiria el trabajo así:

Usa Flex cuando:

• el usuario no espera en tiempo real;
• el flujo puede tardar más sin dañar UX;
• el paso es exploratorio o de fondo;
• el costo agregado pesa más que la latencia.

Usa Priority cuando:

• el usuario esta bloqueado esperando;
• hay una acción sensible al tiempo;
• el flujo toca experiencia premium o soporte;
• o un fallo visible cuesta más que pagar el tier alto.

No hagas esto:

• mandar todo a Priority por miedo;
• mandar todo a Flex por ahorro;
• o mezclar costos, tiers y rate limits sin presupuesto por proyecto.