El rate limiting en APIs de IA opera en múltiples dimensiones simultáneamente, y entender cada una previene mucha frustración. La mayoría de los proveedores imponen al menos dos límites: solicitudes por minuto (RPM) y tokens por minuto (TPM). RPM limita cuántas llamadas API puedes hacer sin importar el tamaño — el nivel gratuito de Anthropic podría permitir 5 RPM, mientras los niveles de pago ofrecen 1,000+ RPM. TPM limita el volumen total de tokens (entrada + salida) fluyendo por minuto. Puedes alcanzar cualquiera de los límites independientemente. Una sorpresa común: estás bien por debajo de tu límite de RPM pero alcanzando TPM porque estás enviando prompts largos con grandes ventanas de contexto. Algunos proveedores también imponen solicitudes por día (RPD) y tokens por día (TPD), creando un techo diario que se reinicia a medianoche UTC.
La mecánica de cómo los proveedores imponen estos límites sigue unos pocos patrones estándar. El más común es el algoritmo de token bucket (o su primo cercano, sliding window). Imagina un cubo que contiene, digamos, 60 unidades de capacidad en tokens. Se rellena a una tasa de uno por segundo. Cada solicitud drena del cubo proporcionalmente a su conteo de tokens. Si el cubo está vacío, tu solicitud es rechazada con un HTTP 429 (Too Many Requests). Los headers de respuesta te dicen lo que necesitas saber: x-ratelimit-limit-requests, x-ratelimit-remaining-requests, x-ratelimit-reset-requests, y sus equivalentes de tokens. El código de cliente inteligente lee estos headers proactivamente en lugar de esperar a recibir un 429. Anthropic, OpenAI y la mayoría de los otros proveedores incluyen estos headers en cada respuesta.
Cuando te limitan la tasa, el enfoque estándar es exponential backoff con jitter. Espera 1 segundo después del primer 429, luego 2 segundos, luego 4, luego 8 — y añade un componente aleatorio (jitter) para que si 50 de tus workers paralelos recibieron 429 al mismo tiempo, no todos reintenten en el mismo momento exacto y reciban 429 inmediatamente de nuevo. La mayoría de los SDKs de proveedores (el SDK de Python de Anthropic, el SDK de OpenAI) manejan la lógica básica de reintentos automáticamente, pero los sistemas de producción usualmente necesitan enfoques más sofisticados: colas de solicitudes con niveles de prioridad, rate limiting adaptativo que estrangula proactivamente basado en la cuota restante, y circuit breakers que fallan rápido cuando un proveedor está claramente sobrecargado en lugar de apilar más reintentos.
Las implicaciones estratégicas de los límites de tasa moldean cómo se arquitectan las aplicaciones serias. Si necesitas procesar 100,000 documentos a través de Claude, no puedes simplemente disparar 100,000 llamadas API concurrentes. Necesitas gestionar la concurrencia, probablemente ejecutando 20-50 solicitudes paralelas y alimentándolas desde una cola. Anthropic ofrece una Batch API con un límite de tasa separado y más alto a un 50% de descuento en costo — específicamente diseñada para este caso de uso. OpenAI tiene un endpoint de batch similar. Para aplicaciones que necesitan capacidad garantizada, los niveles empresariales y los acuerdos de uso comprometido ofrecen throughput dedicado protegido del pool compartido. La realidad no dicha es que los límites de tasa no son solo sobre equidad — son sobre asignación de GPUs. Cada solicitud que haces requiere tiempo de GPU, y los proveedores solo pueden servir tantas solicitudes concurrentes como GPUs tengan. Los límites de tasa son el mecanismo que mantiene la oferta y la demanda en equilibrio.