Limiti di frequenza

Il limite

Ambito	Limite
Per chiave API	60 richieste al minuto

Il limite si applica per chiave, non per spazio di lavoro, quindi due chiavi nello stesso spazio di lavoro hanno ciascuna la propria quota di 60 al minuto invece di condividere un unico pool. È un limite sul numero di richieste, non sul numero di token: una singola richiesta che genera una risposta molto lunga conta come una che ne genera una molto breve, e streaming o non streaming non fa alcuna differenza nel modo in cui una richiesta viene conteggiata.

Questo limite esiste principalmente come protezione contro cicli fuori controllo, un ciclo di retry senza attesa progressiva, un bug che invia una richiesta per ogni pressione di tasto, piuttosto che come un tetto significativo sull'utilizzo legittimo. Il traffico applicativo ordinario, anche un utilizzo di chat piuttosto attivo, resta ben al di sotto.

Superare il limite

Una richiesta che supera il limite riceve immediatamente un 429, senza essere messa in coda o ritardata, nella stessa struttura di errore di qualsiasi altro errore:

HTTP/1.1 429 Too Many Requests

{"error": {"message": "Rate limit exceeded. Please slow down and retry.", "type": "rate_limit_error"}}

La finestra si azzera in modo continuo, quindi la risposta corretta a un 429 è una breve pausa prima di riprovare, non passare a una chiave diversa o supporre che qualcosa si sia rotto. Un singolo 429 nel mezzo di un picco di attività è normale e previsto; 429 ripetuti su molti picchi separati sono un segnale che lo schema di richieste stesso ha bisogno di una strategia di attesa progressiva, trattata più sotto.

Attendere correttamente prima di riprovare

Ritentare un 429 immediatamente, in un ciclo stretto, peggiora la situazione invece di migliorarla: mantiene la frequenza delle richieste esattamente al livello che ha superato il limite, quindi ogni tentativo fallisce allo stesso modo. Un breve ritardo, idealmente crescente, tra i tentativi (poche centinaia di millisecondi, raddoppiando a ogni fallimento consecutivo, fino a un tetto ragionevole) risolve quasi ogni 429 entro uno o due tentativi senza influire in modo significativo sulla latenza percepita di una richiesta normale.

# Python: retry minimale con attesa esponenziale
import time

for attempt in range(4):
    try:
        response = client.chat.completions.create(model="tai-4.1", messages=messages)
        break
    except Exception as e:
        if attempt == 3:
            raise
        time.sleep(0.5 * (2 ** attempt))

Gli SDK ufficiali di OpenAI implementano già per impostazione predefinita un comportamento di retry con attesa progressiva esattamente per questo tipo di errore transitorio; se ne sta usando uno, questo è probabilmente già gestito per lei senza alcun codice aggiuntivo, e vedrà un'eccezione sollevata solo dopo che il suo stesso budget di tentativi è esaurito.

Se 60 al minuto è davvero troppo poco

Per la maggior parte delle applicazioni, il volume di richieste è naturalmente limitato dalla velocità con cui una persona o un ciclo di agente può effettivamente generare richieste, e 60 al minuto raramente è un vincolo reale. Se un caso d'uso legittimo raggiunge costantemente il limite, la prima cosa che vale la pena verificare è se le richieste possano essere raggruppate o consolidate, inviando meno richieste più grandi invece di tante piccole per lo stesso compito di fondo, prima di supporre che sia il limite stesso a dover cambiare.