Una respuesta 429 de una API de IA puede significar cuatro cosas diferentes: demasiadas solicitudes por minuto, demasiados tokens por minuto, demasiadas conexiones simultáneas o un saldo de cuenta agotado. Las cuatro devuelven el mismo código de estado, por lo que la solución depende de diagnosticar qué límite alcanzó realmente, no de intentar reintentar con más insistencia. Esta guía desglosa los modos de fallo, muestra qué evidencia está disponible (y cuál no) sobre los límites actuales y le proporciona un patrón de reintento y respaldo que se mantiene en producción.
Puntos clave
- Un
429puede significar un techo de solicitudes, presupuesto de tokens, límite de concurrencia o saldo de cuenta agotado. Cada uno necesita una solución diferente, y los reintentos generales solo resuelven uno de los cuatro. - Lea los encabezados de límite de tasa en las respuestas exitosas, no solo después de los errores, y aplique limitación (throttling) antes de acercarse al techo.
- El conteo de tokens del lado del cliente es una estimación, no una garantía. Las discrepancias de tokenizador entre su biblioteca y el conteo real del proveedor pueden dejar un margen de seguridad más estrecho de lo que cree.
- Los techos exactos de RPM/TPM por modelo y nivel no se publican en la evidencia disponible para este artículo. Trate cualquier número que vea en otro lugar como algo que debe verificar con el panel de control de su propia cuenta, no como una constante fija.
- Los reintentos resilientes necesitan retroceso exponencial (exponential backoff), jitter, un conteo máximo de reintentos y respeto por el encabezado
retry-after. Nunca reintente operaciones no idempotentes a ciegas.
Comprender la limitación de tasa de la API de IA: los cuatro modos de fallo
Límites de solicitudes
La mayoría de los proveedores cuentan las solicitudes por minuto (RPM). Si los excede, obtendrá un 429 instantáneo, a menudo con un cuerpo vacío. Un usuario que navega rápidamente por los resultados o un trabajo cron que se ejecuta sin limitación son desencadenantes comunes.
Límites de tokens
La trampa que los equipos subestiman más. Los proveedores suelen aplicar los tokens por minuto (TPM) por separado de las RPM, por lo que puede alcanzar un 429 mientras está cómodamente por debajo de su techo de solicitudes. Los modelos de contexto grande empeoran esto: según la evidencia de precios en vivo de TokenLab (observada el 2026-07-07), Claude Opus 4.8 y GPT-5.5 admiten aproximadamente más de 1,000,000 de tokens de contexto. Una llamada que carga un documento grande, una base de código completa o un historial de chat largo en esa ventana puede consumir una gran parte de su presupuesto de tokens por minuto en una sola solicitud, a pesar de ser solo "una" solicitud. Este es un riesgo de planificación de capacidad basado en el tamaño de la ventana de contexto, no en un conteo de tokens por llamada medido, así que valide el uso real contra sus propios registros en lugar de asumir una cifra fija.
Límites de concurrencia
Los proveedores pueden tolerar su volumen promedio por minuto hasta que abra cincuenta transmisiones a la vez. Los límites de concurrencia limitan las solicitudes o conexiones simultáneas en curso. Las respuestas en streaming mantienen las conexiones abiertas por más tiempo, lo que agota los espacios de concurrencia más rápido que las llamadas cortas de una sola vez. Los agentes de codificación creados en Claude Sonnet 5 o Kimi K2.7 Code, y las interfaces de voz que transmiten desde Gemini 3.5 Flash, son desencadenantes comunes porque mantienen muchas conexiones de larga duración abiertas a la vez.
Agotamiento de cuota o saldo
Esto se ve idéntico a un límite de tasa en su panel de control: las llamadas dejan de funcionar. Pero la solución es diferente. Si su cuenta se queda sin créditos prepagos o alcanza un límite de gasto diario estricto, la API devuelve un error que se asemeja a un límite de tasa. El retroceso (backoff) no hace nada aquí. Debe recargar el saldo o aumentar el umbral de gasto.
Instantánea de la fuente
| Punto de datos | Fuente | Observado el |
|---|---|---|
| Ventanas de contexto del modelo y precios por token | Evidencia de precios/modelos en vivo de TokenLab | 2026-07-07 |
| Nombres SSOT del modelo (Claude Sonnet 5, GPT-5.5, Gemini 3.5 Flash, etc.) | SSOT de modelos de TokenLab | 2026-07-07, expira el 2026-07-14 |
| Límites de nivel RPM/TPM oficiales del proveedor | No disponible en este conjunto de evidencia | No verificado, consulte el panel de control de la cuenta del proveedor |
| Comportamiento de normalización de encabezados de puerta de enlace de TokenLab | No disponible en este conjunto de evidencia | Verifique en la documentación de la API de TokenLab antes de confiar en un esquema de encabezado único |
Ventanas de contexto y precios actuales de los modelos (Evidencia en vivo de TokenLab)
Estas cifras provienen directamente de la instantánea de precios en vivo de TokenLab. No son límites de RPM o TPM, muestran por qué una sola llamada en un modelo de contexto grande puede consumir desproporcionadamente un presupuesto de tokens.
| Modelo | Proveedor | Ventana de contexto | Entrada $/MTok | Salida $/MTok | Fuente | Observado |
|---|---|---|---|---|---|---|
| Claude Sonnet 5 | Anthropic | 1,000,000 | $2.00 | $10.00 | Evidencia de precios en vivo de TokenLab | 2026-07-07 |
| Claude Opus 4.8 | Anthropic | 1,000,000 | $5.00 | $25.00 | Evidencia de precios en vivo de TokenLab | 2026-07-07 |
| Claude Fable 5 | Anthropic | 1,000,000 | $10.00 | $50.00 | Evidencia de precios en vivo de TokenLab | 2026-07-07 |
| GPT-5.5 | OpenAI | 1,050,000 | $5.00 | $30.00 | Evidencia de precios en vivo de TokenLab | 2026-07-07 |
| GPT-5.5 Batch/Flex | OpenAI | 1,050,000 | $2.50 | $15.00 | Evidencia de precios en vivo de TokenLab | 2026-07-07 |
| Gemini 3.5 Flash | 1,048,576 | $1.50 | $9.00 | Evidencia de precios en vivo de TokenLab | 2026-07-07 | |
| GLM-5.2 | Z.ai | 1,048,576 | $0.93 | $3.00 | Evidencia de precios en vivo de TokenLab | 2026-07-07 |
| Kimi K2.7 Code | Moonshot AI | 262,144 | $0.74 | $3.50 | Evidencia de precios en vivo de TokenLab | 2026-07-07 |
| DeepSeek V4 Pro | DeepSeek | 1,048,576 | $0.44 | $0.87 | Evidencia de precios en vivo de TokenLab | 2026-07-07 |
| DeepSeek V4 Flash | DeepSeek | 1,048,576 | $0.09 | $0.18 | Evidencia de precios en vivo de TokenLab | 2026-07-07 |
| Qwen3.7 Plus | Alibaba | 1,000,000 | $0.32 | $1.28 | Evidencia de precios en vivo de TokenLab | 2026-07-07 |
| MiniMax M3 | MiniMax | 1,048,576 | $0.30 | $1.20 | Evidencia de precios en vivo de TokenLab | 2026-07-07 |
Nota sobre el SSOT del modelo: estos nombres reflejan el SSOT de modelos de TokenLab observado el 2026-07-07, que expira el 2026-07-14. Los nombres y la disponibilidad cambian con frecuencia. Antes de codificar una cadena de modelo en el código de producción, confirme que todavía se resuelve en el directorio de modelos de TokenLab o en la tabla de clasificación de modelos.
Solucione los fallos de límite de tasa sin crear lógica de reintento desde cero
Todo lo anterior es diagnóstico. El trabajo de remediación, decidir a qué modelo recurrir, rastrear la concurrencia por usuario y mantener una imagen en vivo de qué familias de modelos están saludables, es exactamente lo que la capa de enrutamiento de TokenLab está diseñada para absorber. En lugar de crear manualmente una matriz de respaldo en cinco proveedores, usted dirige las solicitudes a TokenLab y deja que la puerta de enlace seleccione entre el catálogo de modelos actual según la disponibilidad y sus reglas de respaldo.
Una advertencia honesta: TokenLab se encuentra frente a múltiples proveedores ascendentes, y cada uno devuelve su propio conjunto de encabezados, formato de error y semántica de reintento. Si la puerta de enlace normaliza completamente cada encabezado de límite de tasa en un esquema consistente, o si pasa algunos encabezados ascendentes sin cambios, no está confirmado en la evidencia disponible para este artículo. Verifique el comportamiento actual de los encabezados en la documentación de la API de TokenLab antes de escribir una lógica de análisis que asuma un esquema unificado único en cada modelo. Construya su analizador de encabezados de forma defensiva, comprobando la presencia de cada campo en lugar de asumir que existe.
Lectura de encabezados de límite de tasa
Los proveedores devuelven información sobre el límite de tasa en los encabezados de respuesta, aunque los nombres exactos varían según el proveedor. Un patrón común se ve así:
x-ratelimit-limit-requests: 500
x-ratelimit-remaining-requests: 499
x-ratelimit-reset-requests: 12s
retry-after: 0
Lea estos en las respuestas exitosas, no solo después de un 429. Mantenga un conteo continuo del presupuesto restante y reduzca la velocidad cuando caiga por debajo de un umbral de seguridad, normalmente entre un 10 y un 20 % de margen, aunque el número correcto depende de la ráfaga de su tráfico y no es algo que este conjunto de evidencia pueda especificar para usted.
Lógica de reintento con manejo de errores explícito
Un asistente de reintento debe manejar más que el caso 429. Debe distinguir los errores transitorios (429, 503, tiempos de espera) de los errores del cliente (4xx distintos de 429) que nunca tendrán éxito en un reintento, y debe respetar retry-after cuando esté presente.
async function callWithRetry(fn, maxRetries = 4) {
for (let attempt = 0; attempt <= maxRetries; attempt++) {
try {
return await fn();
} catch (err) {
const status = err.status;
// Los errores del cliente distintos de 429 no tendrán éxito en un reintento
if (status && status >= 400 && status < 500 && status !== 429) {
throw err;
}
// Rendirse después de los reintentos máximos independientemente del tipo de error
if (attempt === maxRetries) throw err;
// 429: respetar retry-after si está presente, de lo contrario retroceder con jitter
if (status === 429) {
const retryAfter = parseRetryAfterHeader(err);
const delay = retryAfter
? retryAfter * 1000
: Math.pow(2, attempt) * 1000 + Math.random() * 1000;
await sleep(delay);
continue;
}
// 503 o tiempo de espera de red: retroceder y reintentar, registrar para observabilidad
if (status === 503 || err.code === 'ETIMEDOUT' || err.code === 'ECONNRESET') {
await sleep(Math.pow(2, attempt) * 1000 + Math.random() * 1000);
continue;
}
// 5xx desconocido: reintentar con retroceso, limitar los intentos estrictamente
if (status && status >= 500) {
await sleep(Math.pow(2, attempt) * 1000 + Math.random() * 1000);
continue;
}
throw err;
}
}
}
Nunca envuelva operaciones no idempotentes, como un cargo de pago o una escritura con efectos secundarios, en un bucle de reintento ingenuo. Confirme la idempotencia o use una clave de idempotencia antes de reintentar esas llamadas.
Precisión de la estimación de tokens: por qué los conteos locales se desvían de los conteos del proveedor
Las bibliotecas de conteo de tokens del lado del cliente aproximan el tokenizador que realmente utiliza un modelo determinado. tiktoken coincide estrechamente con la familia de OpenAI, pero no se garantiza que coincida exactamente con los tokenizadores de Anthropic, Google o de pesos abiertos. Las diferencias aparecen en torno a los tokens especiales, los caracteres multibyte y el formato de las instrucciones del sistema, y se agravan en conversaciones largas.
Pasos prácticos para reducir la desviación:
- Lea el uso real de tokens devuelto en el cuerpo de la respuesta (la mayoría de los proveedores incluyen conteos de tokens de solicitud y finalización) y utilícelo para calibrar su estimador local con el tiempo.
- Mantenga un margen de seguridad, no un límite estricto. Si el límite de TPM de su proveedor está cerca de su uso estimado, retrase o divida la solicitud en lugar de enviarla justo al límite.
- Si sus solicitudes son grandes o repetitivas entre llamadas, consulte la cobertura de TokenLab sobre el comportamiento de tokenización y las estrategias de división de solicitudes para obtener formas concretas de reducir los tokens por solicitud antes de alcanzar un techo. Reducir los tokens por llamada suele ser una solución más barata que negociar un nivel superior.
Modelado de tráfico y respaldo de modelos
Retroceso exponencial con jitter. Duplique la espera después de cada reintento y agregue jitter aleatorio para que los clientes simultáneos no reintenten al mismo tiempo.
Modelado de tráfico por usuario o tarea. Limite las llamadas simultáneas por usuario (por ejemplo, 3 simultáneas, 5 solicitudes por segundo de ráfaga) para que un usuario pesado no pueda agotar su límite de toda la cuenta y degradar a los demás.
Estimación del presupuesto de tokens antes del envío. Cuente los tokens del lado del cliente y, si una solicitud lo empujara por encima de su presupuesto de TPM rastreado, retrásela o divídala en lugar de enviarla y esperar.
Respaldo de modelos como red de seguridad. Cuando un modelo principal devuelve un 429, diríjase a uno alternativo con límites separados y capacidad comparable. Una tarea de codificación puede fallar desde Claude Sonnet 5 a DeepSeek V4 Pro o Kimi K2.7 Code. Una carga de trabajo de alto volumen y bajo costo puede fallar entre DeepSeek V4 Flash, Gemini 3.5 Flash y Qwen3.7 Plus, todos los cuales se encuentran en el nivel de enrutamiento de bajo costo del catálogo de modelos actual.
Lista de verificación para el manejo de límites de tasa
| Categoría | Qué verificar | Acción inmediata | Solución a largo plazo |
|---|---|---|---|
| Límites de solicitudes | Valores de encabezado RPM, frecuencia de ráfaga | Limitar las solicitudes del cliente, agregar un limitador de tasa local | Niveles por usuario, colas del lado del servidor |
| Límites de tokens | Presupuesto TPM por modelo, tokens promedio por llamada, uso reportado en respuesta | Pre-contar tokens, dividir solicitudes grandes, retrasar llamadas cerca del techo | Procesamiento por lotes con presupuesto de tokens, enrutar trabajo de alto volumen a modelos de menor costo |
| Límites de concurrencia | Máximo de transmisiones o conexiones simultáneas | Limitar solicitudes simultáneas por cliente, cerrar transmisiones inactivas | Agrupación de conexiones, lanzamientos de transmisión escalonados |
| Cuota / saldo | Saldo de cuenta, límites de gasto diario | Recargar créditos, ajustar umbrales de gasto | Alertas de saldo bajo, recarga automática prepaga |
Rangos de límites típicos: lo que podemos y no podemos confirmar
Las búsquedas secundarias sobre este tema a menudo quieren una tabla de números de RPM/TPM "típicos". No vamos a inventar una. Los límites publicados por nivel cambian con frecuencia, varían según el historial de la cuenta y el nivel de uso, y no forman parte de la evidencia disponible para este artículo.
| Pregunta | Estado | Paso de verificación |
|---|---|---|
| ¿Cuál es un límite de RPM "típico" para un modelo de frontera? | No confirmado en este conjunto de evidencia | Consulte el panel de control de la cuenta de su proveedor o los encabezados de respuesta de límite de tasa directamente |
| ¿Cuál es un límite de TPM "típico" para un modelo de 1M de contexto? | No confirmado en este conjunto de evidencia | Registre el uso real de los encabezados de respuesta durante una semana de tráfico para construir su propia línea base |
| ¿El nivel de uso cambia estos números? | Plausible según el comportamiento general del proveedor, no comparado aquí | Confirme los límites de nivel actuales en la consola de su proveedor |
| ¿Los límites agregados de TokenLab coinciden exactamente con los límites del proveedor ascendente? | No confirmado en este conjunto de evidencia | Verifique en la documentación de la API de TokenLab antes de la planificación de capacidad |
Limitaciones
- No hubo cifras oficiales de RPM/TPM disponibles para GPT-5.5, Claude Opus 4.8, Gemini 3.5 Flash o cualquier otro modelo referenciado aquí. Cada número en las tablas de precios anteriores es el tamaño de la ventana de contexto y el costo por token, no un límite de tasa.
- Si la puerta de enlace de TokenLab unifica completamente los encabezados de límite de tasa en todos los proveedores ascendentes, o si pasa algunos sin cambios, no está confirmado en este conjunto de evidencia. Trate el análisis de encabezados como específico del proveedor hasta que verifique el comportamiento actual de la puerta de enlace en la documentación.
- Los nombres de los modelos en este artículo reflejan el SSOT de modelos de TokenLab observado el 2026-07-07, que expira el 2026-07-14. Confirme la disponibilidad actual en el directorio de modelos antes de enviar código que codifique una cadena de modelo.
- La precisión de la estimación de tokens frente al conteo del lado del proveedor no se comparó en este conjunto de evidencia. Calibre su propio estimador contra el uso reportado en la respuesta en lugar de confiar en un desplazamiento fijo.
Preguntas frecuentes
¿Por qué mi aplicación recibe errores 429 aunque el conteo de solicitudes está por debajo del límite? Verifique primero el presupuesto de tokens por minuto (TPM). Una sola solicitud grande puede agotar la asignación de tokens mientras que el conteo de solicitudes se mantiene bajo. También verifique la concurrencia: las conexiones de transmisión abiertas pueden bloquear nuevas solicitudes incluso cuando las RPM y TPM parecen estar bien.
¿Debo reintentar inmediatamente cuando recibo un 429?
No. Espere el período especificado en retry-after, o use retroceso exponencial con jitter si ese encabezado está ausente. Los reintentos inmediatos corren el riesgo de un efecto de "manada atronadora" y pueden extender su ventana de bloqueo.
¿Cómo sé si mi conteo de tokens local coincidirá con lo que el proveedor realmente me factura? No lo sabe exactamente. Los tokenizadores del lado del cliente son aproximaciones. Lea el uso de tokens devuelto en cada cuerpo de respuesta y utilícelo para calibrar su estimador con el tiempo, y mantenga un margen de seguridad en lugar de enviar solicitudes justo en su techo estimado.
¿TokenLab expone un conjunto unificado de encabezados de límite de tasa en cada modelo? No confirmado en la evidencia disponible aquí. Diferentes proveedores ascendentes devuelven diferentes formatos de encabezado, y cuánta normalización aplica TokenLab es algo que debe verificar en la documentación actual de la API en lugar de asumir.
¿Cómo puedo evitar los límites de tasa sin actualizar mi plan? Combine el presupuesto de tokens, los límites de concurrencia locales y el respaldo de modelos. Estime los tokens antes de enviar, divida las solicitudes largas y diríjase a un modelo alternativo, por ejemplo, de Claude Sonnet 5 a DeepSeek V4 Pro, cuando se alcance su límite principal.
Comience
Los límites de tasa son un hecho al construir sobre APIs de IA, pero no tienen por qué causar interrupciones. La puerta de enlace de TokenLab le da acceso al catálogo de modelos actual y a datos de precios y rendimiento en vivo para que pueda enrutar alrededor de los límites en lugar de adivinarlos. Si también está evaluando las compensaciones de los agregadores, la comparación de OpenRouter cubre el comportamiento de respaldo y la sobrecarga operativa con más profundidad. Obtenga su clave API en tokenlab.sh y cree la lógica de reintento y respaldo una vez, no por proveedor.
Fuentes
Precio observado el 2026-07-07
- TokenLab model directoryObservado el 2026-07-07



