Gemini API 429 RESOURCE_EXHAUSTED: corrige limites leyendo primero el limite correcto

Gemini API 429 RESOURCE_EXHAUSTED significa que la llamada cruzo una frontera de limite. No empieces con mas retry. Primero identifica al dueno del limite: live limit en AI Studio, project quota pool compartido, billing/prepay state, burst pattern o contrato de Vertex AI.

La tabla oficial de troubleshooting de Google mapea HTTP 429 a RESOURCE_EXHAUSTED: la llamada supero un rate limit. La pagina de rate limits anade que los limites se miden por RPM, input TPM y RPD, se aplican per project, not per API key, y los active limits se revisan en AI Studio porque specified limits no equivale a capacidad garantizada.

Nota de frescura: rate limits, troubleshooting, billing, pricing y Vertex AI 429 se revisaron el 3 de mayo de 2026.

Lee 429 como rama de limite, no como caida generica

Si el body dice RESOURCE_EXHAUSTED, quedate en la rama de limite. 503 UNAVAILABLE apunta mas a capacity temporal. 400 FAILED_PRECONDITION puede ser region y billing. 429 indica que el formato paso, pero la frontera de capacidad rechazo servir la llamada.

El error frecuente es tratar todo 429 como bug de codigo. Backoff ayuda con burst traffic, pero no crea daily quota, no recarga prepay balance y no convierte un paid-only route en free route.

Conserva el cuerpo completo del error en logs. En el SDK JavaScript @google/genai, el API error expone name, message y status; eso basta para clasificar retry y para same-path evidence si escalas.

Consulta AI Studio antes de memorizar cuotas

Google explica que rate limits se miden por RPM, input TPM y RPD, se aplican per project, not per API key, y los active limits se consultan en AI Studio. La tabla publica explica el tier ladder; no sustituye el live dashboard.

Responde tres preguntas: que metric llego al limite; que model, route y project generaron el error; si el dashboard coincide con la falla. Si el dashboard esta saturado, el siguiente paso es capacity o traffic shaping. Si no coincide, junta request time, model, project, response body y usage view antes de crear mas API keys.

Separa project quota, billing y route eligibility

Project quota es el pool. Production, staging, local scripts y batch workers compiten si usan keys del mismo Google Cloud project. Billing es account state: si prepay credits llega a $0, las keys de proyectos vinculados pueden parar. Route eligibility es el contrato del modelo; un paid-only route no se estabiliza con trucos de free tier.

Esta separacion evita dos errores: tratar billing como retry problem y tratar route eligibility como free-tier tuning. Primero identifica el owner y luego elige el fix.

Retry solo sirve despues de clasificar

Retry debe ser bounded: exponential backoff with jitter, queue, concurrency cap e idempotency. Si todos los workers reintentan juntos, la capa de retry crea otro spike. Batch jobs necesitan checkpoints; apps interactivas necesitan wait state y caching.

javascript
const retryable = new Set([429, 500, 503, 504]);

async function callWithBackoff(run, maxRetries = 5) {
  for (let attempt = 0; attempt <= maxRetries; attempt += 1) {
    try {
      return await run();
    } catch (error) {
      const status = Number(error?.status || error?.code || 0);
      if (!retryable.has(status) || attempt === maxRetries) throw error;
      const delayMs = Math.min(1000 * 2 ** attempt + Math.random() * 500, 30000);
      await new Promise((resolve) => setTimeout(resolve, delayMs));
    }
  }
}

Developer API y Vertex AI tienen contratos 429 distintos

En Gemini Developer API empieza por AI Studio: API key, project, usage tier, active limits, billing plan, prepay credits. En Vertex AI empieza por Google Cloud project, endpoint, region/global endpoint, quota framework y Provisioned Throughput. Pay-as-you-go puede requerir global endpoint, truncated exponential backoff, QIR, traffic smoothing o reserved throughput.

El mismo HTTP code no significa el mismo system. En Developer API la primera evidencia suele estar en AI Studio; en Vertex AI esta en Google Cloud project, endpoint, quota framework y provisioning contract.

Cuando la respuesta es mas capacidad

Cuando route, project, billing y traffic shape ya estan probados, elige capacity. Puedes usar un model mas ligero, Batch API, quota increase, Vertex AI, Provisioned Throughput o multi-provider gateway. laozhang.ai encaja cuando ya necesitas unified routing/fallback, no para ocultar un retry loop local.

La verificacion operativa debe terminar en una decision concreta. Si se agoto RPM, baja concurrency y reparte llamadas. Si se agoto TPM, reduce context, divide documentos y cachea prompts repetidos. Si se agoto RPD, un retry inmediato no cambia nada hasta que reinicie la ventana o suba la quota. Si usage view y error no coinciden, guarda request-id, timestamp, model, project, endpoint y captura del dashboard; sin esos datos, soporte o el lead tecnico no puede confirmar same-path failure.

Preguntas frecuentes

Cada Gemini API key tiene su propio limite 429?

No. Gemini API limits se aplican per project, not per API key. Varias keys del mismo project comparten quota pool.

Activar billing siempre arregla RESOURCE_EXHAUSTED?

No siempre. Billing cambia tier y eligibility, pero no arregla shared project, depleted prepay balance, daily exhaustion ni burst pattern.

Siempre hay que reintentar un 429?

No. Retry ayuda con temporary pressure y bursts. Daily quota, billing state y paid-only route no se arreglan con retry.

Donde se ve el limite actual de Gemini API?

Usa el active rate-limit view de AI Studio para el mismo project y model. Los documentos publicos explican la mecanica y el tier ladder, pero specified limits no debe tratarse como guaranteed serving capacity.

Regla practica

Primero same error body, same project, same model, same endpoint, same time window. Luego elige el fix mas estrecho: billing action, project isolation, traffic smoothing, model change, quota increase, Vertex capacity o gateway fallback.