Ni la API ni las suscripciones son un grifo infinito. Los límites de uso son los topes que
el proveedor pone a cuánto puedes consumir en una ventana de tiempo. Aparecen de varias formas
y conviene conocerlos antes de que te frenen en producción.
Tipos de límite
Rate limits (API): peticiones por minuto (RPM) y tokens por minuto (TPM). Protegen la
infraestructura del proveedor y suelen subir según tu nivel de gasto/antigüedad.
Cuotas de suscripción: el cupo incluido en tu plan (p. ej. “N mensajes cada 5 horas” o un
volumen semanal). Al agotarlo, esperas a que se renueve la ventana o pagas extra.
Límites por modelo: los modelos más caros suelen tener topes más estrictos que los
pequeños.
Concurrencia: cuántas peticiones simultáneas admite tu cuenta.
Cómo te topas con ellos
Un agente en un loop intensivo puede quemar el rate limit en
minutos: hace muchas llamadas seguidas.
Un pico de tráfico en tu app dispara errores 429 Too Many Requests.
Una sesión larga de coding agent agota la cuota del plan antes de lo esperado.
Qué hacer
Backoff exponencial y reintentos ante 429: es el patrón estándar en la API.
Elegir el modelo adecuado: no gastes el cupo del modelo premium en tareas triviales.
Distribuir la carga en el tiempo si el trabajo lo permite (colas, batching).
Subir de nivel cuando el límite es estructural, no un pico.
Vigilar el consumo con alertas antes de chocar con el techo.
Errores comunes
No implementar reintentos con backoff: un 429 sin manejar tumba tu integración.
Confundir “se acabó la cuota del plan” con “el servicio falla”: muchas veces solo hay que
esperar la renovación de la ventana.