A 24 de marzo de 2026, la respuesta más segura es esta: Gemini 3 Pro Image Preview sigue las reglas públicas de cuota de Google, pero Google ya no publica fuera de AI Studio toda la tabla numérica activa. La documentación oficial todavía confirma lo que sí cambia decisiones: las cuotas se aplican por proyecto, no por API key; las cargas de imagen pueden estar limitadas por RPM, TPM, RPD e IPM; los modelos preview son más restrictivos; y la cuota diaria se reinicia a medianoche en hora del Pacífico. Si necesitas el número exacto vigente para tu proyecto, Google ahora te envía a AI Studio, no a una tabla pública estática.
Puede sonar menos cómodo que los posts antiguos con capturas de cuotas, pero operativamente es más útil. Cuando los números en vivo pasaron detrás de inicio de sesión, la pregunta dejó de ser "¿qué límite publicó un blog el mes pasado?" y pasó a ser "¿qué muestra hoy mi proyecto y qué bucket estoy agotando?". Si ya estás viendo errores 429, el siguiente paso por defecto es confirmar billing y cuota activa en AI Studio, y decidir si el cuello de botella es el burst, la cuota diaria o un tier de pago todavía bajo. Si ves 503 en lugar de 429, trátalo como problema de capacidad, no de cuota.
Resumen rápido
Si solo necesitas la versión corta, usa esta tabla.
| Pregunta | Respuesta actual | Por qué importa |
|---|---|---|
¿Dónde están los límites activos exactos de gemini-3-pro-image-preview? | En Google AI Studio con sesión iniciada | La página pública de rate limits ahora indica que ahí se consultan los valores activos |
| ¿La cuota es por API key? | No, es por proyecto | Rotar keys dentro del mismo proyecto no aumenta throughput |
| ¿Qué buckets importan para generación de imágenes? | RPM, TPM, RPD e IPM | Un flujo de imagen puede fallar por throughput de imágenes, burst de requests o tope diario |
| ¿Cuándo se reinicia la cuota diaria? | A medianoche en hora del Pacífico | Equipos globales deben planificar con esa zona horaria, no con la local |
| ¿Activar billing siempre arregla un 429? | No | Billing ayuda solo si tu tier actual es el límite; una carga con picos puede seguir chocando con cuotas |
| ¿503 significa lo mismo que 429? | No | 429 es agotamiento de cuota; 503 es sobrecarga temporal o falta de capacidad |
Hay dos matices más importantes que cualquier captura copiada.
Primero, Google sigue publicando las reglas, pero no una tabla numérica pública completa y activa para cada proyecto y modelo. Por eso siguen circulando posts viejos con cifras exactas mientras la documentación oficial actual te manda a revisar AI Studio.
Segundo, Gemini 3 Pro Image Preview sigue siendo un modelo preview. Los modelos preview suelen tener límites de tasa más restrictivos, pueden cambiar más y pueden mostrar un comportamiento de capacidad menos estable que un carril general-availability maduro.
Lo que Google confirma públicamente sobre los límites de Gemini 3 Pro Image Preview
La respuesta oficial pública está repartida en cuatro páginas de Google, no en una sola matriz compacta.
En la página de rate limits de Gemini API, Google indica que los límites se miden por requests per minute (RPM), tokens per minute (TPM) y requests per day (RPD), con images per minute (IPM) para modelos con capacidad de imagen. Esa misma página también aclara que los límites se aplican por proyecto, no por API key, y que RPD se reinicia a medianoche en hora del Pacífico. También indica que los modelos preview tienen límites más restrictivos que los estables.
Eso ya corrige tres errores habituales:
- crear una API key nueva no crea un pool de cuota nuevo dentro del mismo proyecto
- "mi día se reinicia a medianoche local" es incorrecto salvo que vivas en hora del Pacífico
- un modelo preview de imagen no debe tratarse como promesa estable de throughput a largo plazo
La siguiente pieza clave es que Google ya no usa los docs públicos como fuente numérica completa y en vivo para las cuotas online. La página de rate limits dice explícitamente que debes ver los límites activos en AI Studio. Es decir: los docs públicos siguen definiendo cómo funciona el sistema, pero los valores exactos actuales para tu proyecto viven en el panel con sesión iniciada.
Ese cambio explica buena parte de la confusión en el SERP. Algunos artículos todavía citan valores IPM o RPM exactos por modelo como si Google publicara una tabla universal. En la práctica, la superficie oficial actual es más prudente: explica dimensiones de cuota, lógica de tiers y reglas de reinicio, y luego te envía a AI Studio para el valor vivo.
Pricing añade otra restricción práctica. En la página de precios de Gemini Developer API, gemini-3-pro-image-preview aparece como carril solo de pago dentro de la tabla pública. Eso importa porque muchos 429 siguen siendo, en realidad, problemas de tier de facturación. Si asumías que este modelo tenía un carril API gratuito público, la página oficial de precios ya no respalda esa lectura.
Por último, Google es claro en que el modelo es reciente y sigue en preview. Las release notes marcan el lanzamiento de Gemini 3 Pro Image Preview el 20 de noviembre de 2025, y la página de modelos mantiene Nano Banana Pro en la familia preview de imagen, mientras avisa aparte de que Gemini 3 Pro Preview, el modelo de texto, se apagó el 9 de marzo de 2026. Esa limpieza de nombres importa porque mucha confusión de cuotas empieza cuando se mezcla el modelo de texto retirado con el modelo de imagen actual.
Qué significan esos límites en cargas reales de generación de imágenes
Las etiquetas de cuota son simples. Cómo fallan en sistemas reales de imagen no lo es tanto.
RPM es la más fácil de entender: enviaste demasiadas requests en muy poco tiempo. Si tu app convierte una acción del usuario en varias llamadas de imagen, el tráfico con picos en frontend puede agotar RPM mucho antes de que la cuota diaria parezca preocupante. Por eso un equipo puede mirar el panel y decir "todavía queda cuota" mientras los usuarios ya reciben 429. Puede sobrar margen diario y, al mismo tiempo, estar agotando el bucket de ventana corta.
TPM es más fácil de ignorar hasta que añades prompts más ricos, imágenes de referencia o contexto multimodal más grande. Un flujo de imagen en Gemini no es solo "una imagen = una request". El prompt de texto, los medios de entrada y las partes de texto de salida consumen presupuesto de tokens. Si tu pipeline construye prompts pesados o hace edición multiimagen, TPM puede convertirse en el limitador invisible aunque el conteo de requests parezca moderado.
RPD es donde muchos equipos se sorprenden en prototipos y demos internas. Puedes comportarte bien por minuto y aun así quemar el tope diario si QA, diseño o procesos batch ejecutan muchas generaciones sobre el mismo proyecto. Como el reinicio ocurre a medianoche en hora del Pacífico, tu "fin de día" puede llegar en mitad de tu jornada local.
IPM es la métrica más intuitiva y también de las más duras para imagen. En la práctica responde: ¿cuántas generaciones de imagen puede sacar este proyecto en el corto plazo? Incluso cuando Google no publica toda la tabla numérica en abierto, este suele ser el bucket que primero siente quien construye producto. Si tu trabajo es generación visual por cola, IPM suele ser más accionable que RPM puro porque se parece más al throughput que ve el usuario.
Por eso la regla de planificación más importante no es "memoriza un número". Es "diseña para el bucket que tu producto puede agotar primero". Para muchos equipos de imagen eso implica:
- encolar requests en vez de dispararlas en paralelo
- suavizar picos de tráfico con pacing en workers
- reintentar con inteligencia en vez de reintentar al instante
- separar generación offline de generación interactiva
Si la carga no es interactiva, la propia página de rate limits sugiere que Batch API puede ser el carril correcto. Google lista límites de batch separados con reglas propias de requests y tokens. La señal es clara: no gastes presupuesto interactivo en trabajo masivo que puede ir por pipeline batch.
Si quieres un modelo mental más limpio: los docs públicos te dicen qué tipos de bucket existen, AI Studio te dice el tamaño actual de esos buckets en tu proyecto, y tu arquitectura de producción decide con cuál chocas primero.
Por qué puedes seguir recibiendo 429 incluso después de activar billing
Esta parte es de las más frustrantes, porque activar billing parece que debería cerrar el tema.
A veces lo cierra. Si tu proyecto estaba en un tier de arranque muy limitado, enlazar billing puede abrir una superficie mayor de cuota. La página pública de rate limits también explica la lógica actual de tiers: los tiers altos exigen gasto acumulado y antigüedad de cuenta, y esas subidas son las que amplían los límites disponibles con el tiempo.
Conviene dejar esas reglas públicas por escrito porque condicionan la respuesta más de lo que reconoce la mayoría de páginas de "fix 429":
- Free: proyecto activo o free trial
- Tier 1: empieza cuando configuras y enlazas una cuenta de billing activa
- Tier 2: hoy requiere $100 de gasto acumulado y al menos 3 días desde el primer pago exitoso
- Tier 3: hoy requiere $1,000 de gasto acumulado y al menos 30 días desde el primer pago exitoso
Eso significa que "activé billing ayer" y "estoy en un tier maduro de alto throughput" no son la misma frase. Muchos equipos se saltan ese paso intermedio y asumen que activar pago ya debería comportarse como escala de producción.
Pero billing no es un interruptor mágico por tres motivos.
Primero, billing no cambia que la cuota es por proyecto. Si cinco workers, varios entornos de test y la app en vivo comparten proyecto, también comparten el mismo pool de cuota. Un proyecto de pago puede comportarse mal si demasiadas cargas presionan el pool al mismo tiempo.
Segundo, los modelos preview siguen siendo más restrictivos que los estables. Incluso en tier de pago, sigues en un carril preview de imagen cuyas cuotas pueden ser más estrechas de lo esperado. Los docs públicos lo dicen, y por eso envejece mal el consejo de "sube de plan y listo".
Tercero, billing no corrige patrones con picos. Si tu app envía muchas requests a la vez, el sistema puede rechazarte por el bucket de ventana corta aunque tu coste mensual sea bajo. Un tier de pago puede fallar igual con una arquitectura espigada.
Aquí es donde las tablas de cuotas reportadas por comunidad deben leerse con cautela. Seguirás viendo hilos, capturas y guías de terceros con valores IPM o RPM concretos por tier. Pueden servir como contexto aproximado, pero no equivalen a una garantía oficial activa para tu proyecto. El flujo fiable es:
- confirmar estado de billing
- abrir AI Studio y leer los valores de cuota en vivo del proyecto
- identificar si el problema es burst de requests, throughput de imagen o tope diario
- solo entonces decidir si hace falta crecer de tier o cambiar arquitectura
Si tu problema real es más de coste que de cuota, la lectura siguiente correcta es nuestra guía de precio de Gemini 3 Pro Image Preview o el desglose de coste por imagen. En este modelo, decisiones de rate limit y de coste van muy unidas, así que normalmente necesitas ambas respuestas.
429 frente a 503: cómo separar un problema de cuota de un problema de capacidad
La guía oficial de troubleshooting de Google aquí es muy clara:
- 429
RESOURCE_EXHAUSTEDsignifica que superaste un límite de tasa - 503
UNAVAILABLEsignifica que el servicio está temporalmente sobrecargado o no disponible
Esa distinción debe definir tu siguiente acción inmediatamente.
Cuando recibes 429, pregunta:
- qué bucket agotamos realmente
- si el proyecto está en el tier de billing correcto
- si estamos metiendo demasiado burst
- si estamos tratando un solo proyecto como si fuera un pool sin límite
Cuando recibes 503, pregunta:
- si el servicio está temporalmente sobrecargado
- si toca hacer backoff y reintentar más tarde
- si necesitas un modelo fallback o proveedor alternativo para esa carga
El error caro es responder igual a ambos códigos. Equipos enteros pierden tiempo pidiendo aumentos de cuota para incidentes que eran 503 de capacidad, o reintentan 429 en bucle cerrado como si esperar milisegundos fuera suficiente.
En Gemini 3 Pro Image Preview esta confusión es común porque los workloads preview de imagen pueden sufrir ambos tipos de presión en la misma franja temporal. Una carga con picos puede empujarte a 429 y, además, una ventana de tráfico global alta puede producir 503 cerca en el tiempo. Si no separas temprano los estados, los logs se vuelven ruido.
Usa esta tabla en vez de adivinar:
| Síntoma | Causa probable | Qué hacer después |
|---|---|---|
429 RESOURCE_EXHAUSTED tras un burst de requests de imagen | Bucket de cuota del proyecto agotado | Revisar límites activos en AI Studio, desacelerar la cola y verificar tier de billing |
429 aunque la cuota diaria parezca bien | Límite de ventana corta como RPM o IPM | Reducir concurrencia y añadir retries con pacing |
503 UNAVAILABLE o model is overloaded | Problema temporal de capacidad del servicio | Hacer backoff, reintentar más tarde o cambiar de carril |
| Mezcla de 429 y 503 en horas pico | Puede haber presión de cuota y de servicio al mismo tiempo | Diagnosticar cada estado por separado en vez de una regla única de retry |
Si el modo de fallo dominante es 503, ve directo a nuestra guía dedicada sobre errores 503 overloaded de Gemini 3 Pro Image (fallback en inglés, todavía sin versión en español). Si los fallos van más allá de un único status code, la siguiente lectura correcta es la guía general de errores Gemini API para 429, 400 y 500.
Qué hacer si Gemini 3 Pro Image Preview se te queda corto para tu carga
La respuesta correcta suele ser más aburrida de lo que uno espera. Casi nunca es "buscar un truco secreto". Casi siempre es "aplicar el siguiente paso de escalado en el orden correcto".
Empieza aquí:
- Confirma la cuota activa en AI Studio. No optimices contra capturas antiguas ni tablas de terceros.
- Revisa billing y estado de tier. Si el proyecto sigue en un carril de entrada, quizá el siguiente salto es de tier y no solo de código.
- Aplica pacing al workload. Encola requests, limita concurrencia y usa exponential backoff en vez de tormentas de retry.
- Saca lo no interactivo del carril interactivo. Si es generación batch, usa la ruta batch y no gastes presupuesto interactivo.
- Haz sharding solo después de cumplir los cuatro puntos anteriores. El sharding por proyecto es decisión de arquitectura, no workaround de primera línea.
Ese orden importa porque el atajo más común es el menos educativo: crear más API keys, meter más workers y esperar que desaparezca el problema. Dentro de un mismo proyecto, eso suele volver la presión más caótica.
Si todavía estás en fase temprana de producto, otra pregunta útil es si Gemini 3 Pro Image Preview debe ser realmente tu carril por defecto para esta carga. Si buscas volumen alto, coste sensible y menor dependencia de text rendering premium o layouts de estudio, otros carriles de imagen de Gemini suelen escalar más fácil. Nuestra guía de rutas actuales de Gemini image API gratis y de bajo coste ayuda aquí, porque muchos problemas de rate limit son en realidad problemas de selección de modelo.
Si estás comprometido con Gemini 3 Pro Image Preview porque necesitas salida premium, el camino no es misterioso:
- mantener el tráfico estable
- separar cargas interactivas de cargas offline
- monitorizar el bucket que realmente limita
- asumir el comportamiento preview como realidad actual, no como un bug de expectativas
Suena menos emocionante que un hack, pero es como los sistemas de producción dejan de caerse.
Checklist actual de límites que usaría antes de salir a producción
Antes de declarar este modelo como production-ready, yo validaría estos siete puntos en orden.
1. La cuota exacta en vivo está registrada desde AI Studio, no copiada de un blog.
Si el número sale de una captura guardada hace semanas, ya es una base débil para capacidad.
2. El equipo sabe que la cuota es por proyecto.
Si varias apps, workers o entornos comparten proyecto, también comparten el mismo dolor.
3. El equipo conoce la zona horaria de reinicio.
Medianoche en hora del Pacífico es una restricción real del producto, no una nota al pie.
4. Los retries usan backoff y jitter.
Reintentar al instante es la forma más rápida de convertir una cuota ajustada en una caída autoinducida.
5. 429 y 503 se tratan como incidentes diferentes.
Agotamiento de cuota y sobrecarga del servicio no deberían compartir una sola rama de "esperar y rezar".
6. Los trabajos de imagen interactivos y no interactivos están separados.
La generación masiva debe ir por un camino distinto al de generación de cara al usuario.
7. La elección de modelo sigue encajando con la carga.
Si la mayor parte del trabajo es generación utilitaria de alto volumen y no activos premium, vuelve a validar si Pro Image es el carril correcto antes de comprar más throughput alrededor.
El mejor resultado al terminar este artículo no debería ser "me memoricé un número". Debería ser "ya sé de dónde sale el número en vivo, qué regla es oficial, qué error significa qué y qué siguiente paso sí merece la pena".
Conclusión
Los límites de Gemini 3 Pro Image Preview no son totalmente opacos, pero tampoco son ya totalmente públicos. Google sigue publicando las reglas clave, y esas reglas bastan para decidir bien: la cuota es por proyecto, los modelos preview son más restrictivos, la cuota diaria se reinicia a medianoche en hora del Pacífico, 429 significa agotamiento de cuota y 503 significa sobrecarga temporal. Para el límite numérico activo exacto de tu proyecto, AI Studio es ahora la fuente autoritativa.
Eso hace que el flujo práctico en marzo de 2026 sea directo. Si recibes 429, confirma billing y cuota activa en AI Studio, luego desacelera la carga o sube al tier correcto. Si recibes 503, aplica backoff y trátalo como presión del servicio, no como fallo personal de cuota. Y si sigues buscando un número estático universal para memorizar, estás resolviendo la versión 2025 del producto, no la de 2026.