Limites de Gemini API y errores 429 en 2026: como funcionan de verdad los tiers, AI Studio y billing

Un 429 RESOURCE_EXHAUSTED de Gemini API ya no se entiende bien con una sola tabla publica de cuotas. En 2026, un 429 suele caer en una de cuatro causas: tu project ha chocado con un live limit visible en AI Studio, varias apps estan compartiendo la misma cuota de project, el billing state no esta sirviendo como crees, o el patron de trafico es tan bursty que dispara el limit antes de lo esperado.

Lo importante no es que los tiers hayan dejado de importar. Lo importante es que la respuesta correcta vive ahora en otro sitio. La escalera publica de tiers sigue siendo importante y Google sigue documentando las mechanics de rate limits que importan a los desarrolladores. Pero la rate-limits page actual te manda a AI Studio para ver los active rate limits y avisa de que los valores publicados no estan garantizados. Por eso la pregunta practica ya no es "cual es la cuota de Gemini API" en abstracto, sino "sobre que live limit esta corriendo mi project ahora mismo y que parte del problema esta senalando este 429".

La respuesta se reparte entre varias fuentes oficiales: la rate-limits page para las reglas vigentes, la billing page para los requisitos de tier y la logica de prepay, la pricing page para ver que rutas siguen siendo free-capable y cuales son paid-only, la API keys guide para la relacion entre key y project, y la troubleshooting guide para el camino oficial de Google ante un 429.

Nota de actualidad: el contenido de abajo se reviso contra la documentacion actual de Google sobre rate limits, billing, pricing, API keys, troubleshooting y el anuncio de Gemini cost controls del 16 de marzo de 2026 el 3 de abril de 2026.

Empieza por estas cuatro comprobaciones:

• AI Studio: mira el active RPM / TPM / RPD del model y del project exactos antes de asumir que una tabla publica sigue respondiendo todo.
• Project quota: las cuotas de Gemini se aplican por project, no por API key, asi que varias keys y varias apps pueden seguir compitiendo por un solo pool.
• Billing / prepay: el paid tier depende del estado de la billing account y un prepay en $0 puede parar el servicio.
• Traffic pattern: retries bursty, contextos largos y demasiada concurrencia tambien pueden disparar 429.

Lo que los tiers siguen controlando ahora

Los tiers siguen importando. Deciden en que clase de capacidad estas, si ciertas rutas paid-only estan abiertas y que billing gates ya has cruzado. Lo que cambio es que la escalera de tiers ya no responde por si sola toda la parte operativa. Los docs publicos siguen mostrando el ladder, pero la respuesta viva de tu project ahora se lee en AI Studio.

Segun la documentacion publica de Google revisada en abril de 2026, la estructura actual se entiende mejor asi:

Por eso los articulos viejos basados en tablas envejecen mal. Los docs publicos siguen confirmando lo que sigue siendo verdad para todos: los limits se miden por RPM, TPM y RPD; las quotas se aplican por project y no por key; los requests per day se reinician a medianoche en Pacific Time; y los tiers altos desbloquean mas limits. Pero esos mismos docs ahora te mandan a AI Studio para los active limits y dicen que los valores publicados no estan garantizados.

En otras palabras, los tiers siguen controlando eligibility, billing state y la clase general de capacity, pero ya no te dan la respuesta viva completa de tu project. Si intentas explicar un 429 con una tabla antigua, estas mirando la capa equivocada.

Las cuatro comprobaciones que explican la mayoria de los 429

La mayoria de los 429 de Gemini se reduce a estas cuatro comprobaciones. El orden importa porque evita que conviertas todo demasiado pronto en "sube de tier" o "mete mas retries" sin saber que capa esta fallando de verdad.

1. Mira AI Studio antes de interpretar el error

La primera pregunta es si el project esta realmente tocando un live rate limit. Google ya te envia desde los rate-limits docs a AI Studio para ver active limits, asi que ahi es donde debes comprobar si la metrica que esta poniendose roja es RPM, TPM o RPD. Si el dashboard muestra una fila de model cerca del live ceiling, el 429 esta diciendo exactamente lo que debe: tu project ha tocado el limite real que tiene ahora mismo.

Eso es muy distinto de pensar "Tier 1 deberia darme mas margen". El tier ladder describe la clase de account. El dashboard describe lo que esa account esta sirviendo de verdad ahora. Si AI Studio ya muestra un cap real, deja de buscar un bug misterioso y pasa a la siguiente decision: bajar carga, cambiar de ruta, pedir quota increase o cambiar de capacity path.

2. Comprueba si varias apps comparten la misma quota de project

Las Gemini API keys no crean quota pools independientes. La API key docs explica que cada key esta asociada a un Google Cloud project y la rate-limits docs deja claro que las quotas se aplican por project. Eso significa que el tipico movimiento de "creo otra key para el worker" no agrega headroom si ambas keys siguen dentro del mismo project.

Esta es una de las razones mas comunes por las que el limit parece "roto". La web app, staging, un batch interno y un experimento puntual pueden estar golpeando el mismo project. Entonces el 429 parece aleatorio porque el noisy neighbor esta en otra parte del stack. Si el dashboard se acerca al limite mas rapido de lo esperado, primero revisa que workloads comparten ese project antes de asumir que billing no funciono o que Google esta contando mal.

El siguiente paso aqui no es "crear mas keys". Es identificar todos los workloads conectados al project, separar los ruidosos a projects distintos cuando la aislacion tenga sentido, y volver a mirar AI Studio.

3. Comprueba billing y prepay, no solo si alguna vez activaste billing

El paid access ya no es solo una casilla que se marca una vez. Los billing docs actuales de Google dicen que los usuarios nuevos empiezan por defecto en prepay, que el paid setup puede requerir una compra minima y que el servicio se detiene cuando el prepay balance llega a $0. Los mismos docs tambien dicen que los tier qualifications y los billing-account caps se determinan a nivel de billing account.

Por eso "activamos billing el mes pasado" no es un diagnostico completo. La pregunta practica es otra: a que billing account esta vinculado el project, en que tier real esta esa account y si el balance y el billing state pueden seguir sirviendo trafico ahora mismo. En algunos casos, un 400 FAILED_PRECONDITION significa que el free tier no esta disponible en la region y hay que habilitar billing. En otros, un 429 en un setup que parecia paid termina siendo un problema de billing-account state y no un problema puro de rate limits.

Si el billing state es incorrecto, la retry logic no ayuda. Primero corrige el account binding, el tier setup o el prepay balance, y luego vuelve a AI Studio.

4. Comprueba si el problema real es el patron de requests

Algunos 429 son problemas de estado de capacity. Otros son problemas de forma del trafico. Si el dashboard dice que tu project esta cerca de su live limit, puede que la solucion no sea subir de tier de inmediato sino suavizar la carga. Prompts muy largos, demasiada concurrencia, retries agresivos y bursts repentinos pueden llevar a RESOURCE_EXHAUSTED incluso cuando la carga media parecia razonable.

Aqui tambien importa un detalle pequeno pero muy util de los billing docs: las requests fallidas con 400 y 500 no se facturan, pero si cuentan contra quota. Si tu aplicacion esta golpeando la API con malformed requests o retries demasiado agresivos, puedes quemar quota sin generar valor. El manejo temporal de errores termina convirtiendose en parte del problema.

Solo cuando sabes que el limit es real las code changes vuelven a tener sentido. Antes de eso muchas "optimizaciones" son solo movimiento.

Cuando los cambios de codigo si arreglan el problema

La mitigacion a nivel de codigo ayuda cuando el problema de fondo es burstiness, saturation temporal o una ruta de model demasiado pesada para ese workload. No ayuda cuando la route ya es paid-only, cuando la billing account no esta sirviendo de verdad o cuando el project esta en una clase de capacidad que simplemente se queda corta.

En la practica, tres movimientos de ingenieria suelen resolver una parte importante de los 429:

• meter exponential backoff con jitter para que los retries no golpeen todos el mismo hot limit;
• bajar la concurrencia o poner cola para que los picos por minuto no parezcan abuse;
• cambiar a una route mas adecuada para la carga, por ejemplo una ruta mas barata y con mas throughput si la calidad lo permite.

Un wrapper minimo en JavaScript puede verse asi:

javascript
async function callWithBackoff(run, { maxRetries = 5, baseDelayMs = 1000 } = {}) {
  for (let attempt = 0; attempt <= maxRetries; attempt += 1) {
    try {
      return await run();
    } catch (error) {
      const status = error?.status || error?.code;
      const retryable = status === 429 || status === 500 || status === 503 || status === 504;

      if (!retryable || attempt === maxRetries) throw error;

      const waitMs = Math.min(baseDelayMs * 2 ** attempt + Math.random() * 500, 30000);
      await new Promise((resolve) => setTimeout(resolve, waitMs));
    }
  }
}

Lo importante no es la sintaxis sino el boundary. Si AI Studio te muestra que estas lejos del live limit, deja de ajustar retry logic y vuelve a revisar billing state, project ownership o route eligibility. Si AI Studio muestra saturation real, entonces backoff, cache, queueing y menos concurrencia si son las herramientas correctas.

Si necesitas una taxonomia de errores mas amplia que 429, puedes mirar la guia en ingles Gemini API error troubleshooting guide.

Mapa actual de acceso a modelos

Parte de la investigacion de 429 es, en realidad, un error de seleccion de modelo. Si la route que quieres ya es paid-only en API, ningun ajuste del free tier la convertira en un camino unpaid estable.

Segun la pricing documentation de Google revisada el 3 de abril de 2026, la separacion practica queda asi:

Por eso la pregunta "debo subir de tier?" a veces llega demasiado tarde. La mejor primera pregunta es si el modelo pertenece de verdad a la conversacion de free tier. Si no pertenece, el camino de diagnostico cambia desde el inicio.

Si tu pregunta principal es que sigue siendo gratis, nuestra guia del plan gratuito de Gemini API es el mejor siguiente paso. Si lo que quieres es gemini-3.1-pro-preview, entonces conviene leer antes la guia de Gemini 3.1 Pro free API.

Cuando la respuesta es simplemente mas capacidad

Cuando el dashboard, el shared project usage, el billing state y el traffic pattern ya estan claros, la pregunta que queda es si la capacity basta. En ese punto el problema ya no es de depuracion ingeniosa. Es una decision de capacidad.

Los caminos habituales son cuatro:

1. Si el live limit es real pero el workload aun es pequeno, pasa de Free a Tier 1 y confirma que el billing-account setup esta realmente completo.
2. Si el workload ya supero Tier 1, deja que los thresholds publicos de Tier 2 y Tier 3 hagan su trabajo.
3. Si el live limit de ese project es demasiado bajo, usa la via de quota increase de Google en lugar de esperar que los retries simulen mas capacidad.
4. Si el 429 de un solo proveedor ya es un riesgo operativo, sube una capa y disena fallback multi-provider.

Ese ultimo caso es donde una aggregation layer puede ser util. Si ya sabes que necesitas provider fallback o un multi-model control plane mas simple, un gateway unificado como laozhang.ai puede ser mas facil de operar que construir tu propio vendor routing desde cero. La clave es tomar esa decision de forma deliberada, no como reaccion de panico ante un solo 429.

Lo que no funciona es pensar que mas keys dentro del mismo project crean mas quota, o seguir tratando una route paid-only como si fuera un problema de ajuste fino del free tier. Eso no es una optimization mistake. Es una forma equivocada de entender el problema.

FAQ

Cada Gemini API key tiene su propio rate limit?

No. Las quotas de Gemini se calculan por project, no por API key. Varias keys dentro del mismo project comparten el mismo pool.

Activar billing siempre arregla los 429?

No. Billing cambia el tier y la route eligibility, pero no arregla por si solo el shared project usage, un prepay agotado o un patron de trafico demasiado bursty.

Donde miro ahora el live limit real de Gemini API?

En AI Studio. Los rate-limits docs actuales de Google te mandan alli para ver los active limits y explican que los numeros publicados no estan garantizados.

Cuales son ahora los thresholds de Tier 2 y Tier 3?

Segun la documentacion oficial revisada el 3 de abril de 2026, Tier 2 requiere paid account + $100 cumulative spend + 3 days. Tier 3 requiere paid account + $1,000 + 30 days.

Por que un project paid puede seguir devolviendo 429?

Porque el paid access no responde todo. El live project limit puede seguir siendo bajo, otras apps pueden compartir el mismo project, el billing-account state puede ser incorrecto o el patron de trafico puede ser demasiado bursty.

Regla practica

Usa los public docs para el tier ladder, la pricing page para la model eligibility, AI Studio para el live limit y la billing page para el account state. Cuando esas cuatro superficies encajan, un 429 de Gemini deja de parecer misterioso. Antes de que encajen, agrandar el retry loop suele ser solo una forma mas lenta de descubrir que el problema nunca fue una sola tabla fija de quota.