Home → Assistenza

Concurrency limit exceeded for user, please retry later: cosa significa

Cosa vedi

• 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

Perché succede

Il messaggio viene da sub2api, il gateway open source su cui girano molti servizi di relay API, quindi puoi incontrarlo presso più di un fornitore. Il limite è per account utente, non per chiave: due chiavi dello stesso account attingono allo stesso pool. Il valore predefinito di sub2api è 5 richieste simultanee.

Il gateway non rifiuta subito la sesta richiesta. La mette in coda e la avvia appena si libera un posto. L'abbiamo misurato sul nostro gateway il 14 ottobre 2026 con limite 5: 10 richieste insieme, tutte e 10 riuscite e la più lenta ha impiegato 8,3 secondi; 25 insieme, tutte e 25 riuscite e la più lenta ha impiegato 18,8 secondi. Le richieste in eccesso hanno aspettato invece di fallire. Quindi, quando vedi questo errore, non hai superato il limite per un attimo: ci sei rimasto sopra abbastanza a lungo che una richiesta non ha trovato posto in tempo.

Per questo compare con richieste lunghe e non con tante brevi. Una risposta in streaming, un modello di ragionamento che pensa per un minuto o un agente che aspetta uno strumento occupa il suo posto per tutto il tempo. Cinque così insieme riempiono l'account, e tutto ciò che viene dopo aspetta finché non rinuncia.

Verifica se la causa è questa

Invia dieci richieste identiche nello stesso momento e guarda i tempi:

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."}]}'

Se le prime tornano subito e le altre arrivano a ondate successive, quelle ondate sono il tuo limite. Se alcune restituiscono 429 con questo messaggio, la coda è traboccata: abbassa il valore di -P finché non succede più. Quello è il parallelismo che il tuo account regge davvero.

Come risolvere

1. Limita le richieste in corso nel clientMetti un semaforo attorno alla chiamata, grande quanto il limite dell'account: asyncio.Semaphore(5) in Python, p-limit in Node. Un ciclo di retry più lento non risolve; il limite conta le richieste aperte, quindi aiutano solo meno richieste aperte.
2. Conta tutte le chiavi dell'accountSe un agente di codice, un'app di chat e uno script condividono un account, condividono un limite. Dai ai lavori batch pesanti un account a parte, o pianificali quando il resto è fermo.
3. Questo si ritenta, con attesa e casualitàA differenza del 429 per credito esaurito, questo si risolve da solo appena finiscono le richieste in corso. Aspetta uno o due secondi, aggiungi uno scarto casuale perché i worker non ritentino tutti insieme, e riprova.
4. Riduci il parallelismo dentro gli agentiGli strumenti ad agenti che avviano sottoattività possono aprire molte richieste in un colpo. Quasi tutti permettono di limitare attività o worker simultanei nelle impostazioni; impostalo pari o sotto il limite dell'account.
5. Chiedi un limite più alto solo per carico costanteSe il tuo lavoro ha davvero bisogno di più richieste aperte tutto il giorno, chiedilo al fornitore. Per i picchi, una coda dalla tua parte costa meno ed è più veloce di un limite più alto.

Articoli correlati

Ultima verifica: 2026-10-14. Scritto a partire da problemi diagnosticati su un gateway compatibile con OpenAI in produzione, non raccolto da altri siti.