L’email del limite di richieste dell’API è arrivata alle 16:00 di un venerdì. Il mio agente stava elaborando richieste felicemente per tutta la settimana e, da qualche parte tra l’automazione del caffè mattutino e la revisione del codice pomeridiana, ha oltrepassato il limite.
Essere limitati non è imbarazzante: succede a tutti. Essere limitati senza sapere di essere vicini al limite è imbarazzante. Significa che non hai nessuna visibilità sul consumo della tua API, e questo è un problema che avrei dovuto risolvere settimane prima.
Dove i limiti colpiscono
La maggior parte dei fornitori di API per l’AI applicano più limiti e quello che ti sorprende non è mai quello che ti aspettavi:
Richieste al minuto. Il più ovvio. Invia troppe richieste in un breve lasso di tempo e sarai limitato. Le operazioni in batch sono il colpevole abituale: elaborare 50 elementi genera 50 richieste in rapida successione.
Token al minuto. Meno ovvio. Anche se stai inviando poche richieste, ognuna potrebbe elaborare una grande finestra di contesto. Tre richieste con 50K token ciascuna = 150K token al minuto, il che supera molti limiti standard.
Token al giorno. Il più subdolo. Potresti essere ben al di sotto dei tuoi limiti per minuto, ma accumuli gradualmente durante la giornata. Conversazioni lunghe, lavori cron e compiti in background contribuiscono tutti.
Collegamenti concorrenti. Il più frustrante. Anche se hai budget rimanenti, avere troppe connessioni simultanee aperte ti fa limitare.
La mia strategia per i limiti di richieste
Dopo essere stato colpito, ho costruito un approccio a tre strati:
Strato 1: Consapevolezza. Un semplice widget di dashboard che mostra l’uso attuale come percentuale di ciascun limite. Aggiornato ogni 60 secondi. Quando l’uso supera il 70%, il widget diventa giallo. A 90%, diventa rosso. Questo richiede 10 minuti per l’implementazione e salva ore di sorprese.
Strato 2: Riduzione automatica. Quando l’uso si avvicina all’80% di qualsiasi limite, il sistema rallenta automaticamente le richieste non critiche. I messaggi interattivi degli utenti passano immediatamente. I compiti in background (lavori cron, elaborazione in batch) vengono messi in coda e distribuiti su un lasso di tempo più lungo.
L’implementazione: un limitatore di velocità a bucket di token che si colloca tra OpenClaw e l’API. Tiene traccia dell’uso rispetto a tutti e quattro i tipi di limiti e controlla le richieste di conseguenza.
Strato 3: Degrado controllato. Quando un limite viene effettivamente raggiunto (risposta 429), il sistema:
1. Si ritira con un delay esponenziale (1s, 4s, 16s)
2. Passa i compiti non critici a un modello più economico/lento se disponibile
3. Mi avvisa che è stato raggiunto un limite (così posso indagare se inaspettato)
4. Mette in coda qualsiasi richiesta che può aspettare
L’intuizione chiave: non tutte le richieste sono uguali. Un utente che aspetta una risposta in Slack è molto diverso da un lavoro di analisi in background. Il limitatore di velocità dovrebbe dare priorità di conseguenza.
Ridurre il consumo dell’API
La migliore strategia per i limiti di richieste è consumare meno token API:
Cache dei prompt. Se lo stesso prompt di sistema viene inviato con ogni richiesta (e di solito è così), chiedi al tuo fornitore della cache dei prompt. Anthropic memorizza nella cache la prima parte del prompt e addebita meno per i token memorizzati. Questo può ridurre i costi del 30-50% per i carichi di lavoro ripetitivi.
Cache delle risposte. Per domande a cui il tuo agente viene ripetutamente posto, memorizza la risposta e servila senza fare una nuova chiamata API. “Qual è la nostra politica di rimborso?” non ha bisogno di essere elaborato dal modello AI ogni volta.
Potatura del contesto. La più grande fonte unica di consumo non necessario di token è un contesto di conversazione gonfiato. Vecchi messaggi che non sono pertinenti alla domanda attuale vengono comunque inviati all’API e consumano token. Abilita la compattazione. Potatura la storia. Sii aggressivo nell’eliminare contesti irrilevanti.
Routing intelligente dei modelli. Compiti semplici (classificazione, formattazione, domande sì/no) non hanno bisogno del tuo modello più costoso. Inviabili a un modello più economico che è adeguato per il compito. Risparmia il modello premium per ragionamenti complessi.
Monitorare ciò che importa
Le metriche che monitoro quotidianamente:
– Token totali consumati (input e output, separatamente)
– Token per interazione (media e p95)
– Tasso di ripetizione (quale percentuale di richieste ha necessitato una ripetizione)
– Profondità della coda (quante richieste in background stanno aspettando)
– Costo per interazione (per il budgeting)
La metrica più utile per l’ottimizzazione: token per interazione. Se questo numero aumenta nel tempo, il mio contesto sta crescendo o i miei prompt si stanno gonfiando. Se esplode all’improvviso, qualcosa è cambiato e dovrei indagare.
Il risultato pratico
Dopo aver implementato tutto questo:
– Zero eventi inaspettati di limite di richieste negli ultimi 4 mesi
– Consumo di token ridotto di circa il 35% (da potatura del contesto e routing intelligente)
– Costi API ridotti di circa il 40% (da cache dei prompt e routing a modelli più economici)
– Nessun impatto sulla qualità della risposta per interazioni orientate all’utente
L’email del limite di richieste che ha dato inizio a tutto questo è stata in realtà un regalo. Mi ha costretto a costruire visibilità e controllo sul mio consumo dell’API. Senza di essa, sarei ancora volando alla cieca, pagando più del necessario e occasionalmente rimanendo sorpreso.
🕒 Published: