Inicio → Ayuda

Concurrency limit exceeded for user, please retry later: qué significa

Lo que ves

• 429 Too Many Requests
• Concurrency limit exceeded for user, please retry later
• A batch script that works with 1 worker and fails with 20
• An agent that fails only when it starts several subtasks at once
• Two apps on the same account that break each other

Por qué ocurre

El mensaje viene de sub2api, el gateway de código abierto sobre el que funcionan muchos servicios de relay de API, así que puedes encontrarlo en más de un proveedor. El límite es por cuenta de usuario, no por clave: dos claves de la misma cuenta comparten el mismo cupo. El valor por defecto de sub2api son 5 peticiones simultáneas.

El gateway no rechaza la sexta petición de inmediato. La pone en una cola y la arranca en cuanto se libera un hueco. Lo medimos en nuestro propio gateway el 14 de octubre de 2026 con límite 5: 10 peticiones a la vez, las 10 con éxito y la más lenta tardó 8,3 segundos; 25 a la vez, las 25 con éxito y la más lenta tardó 18,8 segundos. Las peticiones de más esperaron en lugar de fallar. Así que, cuando ves este error, no te pasaste del límite un instante: te mantuviste por encima tanto tiempo que una petición no consiguió hueco a tiempo.

Por eso aparece con peticiones largas y no con muchas cortas. Una respuesta en streaming, un modelo de razonamiento pensando un minuto o un agente esperando una herramienta ocupa su hueco todo ese tiempo. Cinco así a la vez llenan la cuenta, y todo lo que viene detrás espera hasta rendirse.

Comprueba si es esta la causa

Lanza diez peticiones idénticas a la vez y mira los tiempos:

seq 1 10 | xargs -P 10 -I{} curl -s -o /dev/null \
  -w '%{http_code} %{time_total}s\n' \
  'YOUR_BASE_URL/chat/completions' \
  -H 'Authorization: Bearer YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"model":"YOUR_MODEL","messages":[{"role":"user","content":"Count from 1 to 150."}]}'

Si las primeras vuelven rápido y el resto llega en oleadas posteriores, esas oleadas son tu límite. Si alguna devuelve 429 con este mensaje, la cola se desbordó: baja el número de -P hasta que ninguna lo haga. Ese es el paralelismo que tu cuenta soporta de verdad.

Cómo solucionarlo

1. Limita las peticiones en curso en tu clientePon un semáforo alrededor de la llamada, del tamaño del límite de tu cuenta: asyncio.Semaphore(5) en Python, p-limit en Node. Un bucle de reintentos más lento no lo arregla; el límite cuenta peticiones abiertas, así que solo ayuda tener menos abiertas.
2. Cuenta todas las claves de la cuentaSi un agente de código, una app de chat y un script comparten cuenta, comparten límite. Da a los trabajos por lotes pesados su propia cuenta o prográmalos cuando lo demás esté parado.
3. Este sí se reintenta, con espera y aleatoriedadA diferencia del 429 por saldo agotado, este se resuelve solo en cuanto terminan las peticiones en curso. Espera uno o dos segundos, añade un desfase aleatorio para que tus workers no reintenten a la vez, y vuelve a probar.
4. Baja el paralelismo dentro de los agentesLas herramientas de agentes que lanzan subtareas pueden abrir muchas peticiones de golpe. La mayoría permite limitar tareas o workers simultáneos en su configuración; ponlo igual o por debajo del límite de la cuenta.
5. Pide más límite solo para carga sostenidaSi tu trabajo de verdad necesita más peticiones abiertas durante todo el día, pídeselo a tu proveedor. Para picos, una cola en tu lado es más barata y rápida que un límite mayor.

Relacionado

Revisado por última vez el 2026-10-14. Escrito a partir de problemas diagnosticados en una pasarela compatible con OpenAI en producción, no recopilado de otras webs.