⚠️ Rate limited: Hermes passa in continuazione al fallback — perché succede e come fermare il loop

Quindi, tradotto in parole povere: Hermes sta funzionando come previsto. Il problema è che il provider primario non riesce a smaltire il rate limit, e a ogni turno ci riprova invano.

Perché il messaggio si ripete a ogni messaggio

La causa immediata è quasi sempre un rate limit (HTTP 429) sul provider principale . Finché quel limite non viene rimosso — per scadenza della finestra temporale, per aumento della quota, o per intervento lato configurazione — ogni nuovo turno parte con un tentativo verso il primario, fallisce, e il ciclo ricomincia.

Due dettagli importanti che emergono dalla documentazione:

1. Rate limit e contesti lunghi. OpenClaw segnala che l'errore 429 può essere innescato specificamente da richieste con contesti molto ampi ("Extra usage is required for long context requests") . Se la conversazione è particolarmente lunga o il prompt è massiccio, il provider potrebbe rifiutare la richiesta o applicare restrizioni più aggressive.
2. Gateway e stato del client. Errori 429 possono dipendere anche da disallineamenti tra client e gateway. Il comando

   openclaw gateway probe

   permette di verificare se il gateway è raggiungibile e se l'autenticazione è valida .

L'elemento chiave nel tuo caso: "sg claude opus 4.7 via custom"

Quella dicitura ci dice una cosa precisa: il fallback sta passando attraverso un endpoint personalizzato già configurato in Hermes, non attraverso un provider completamente diverso .

Questo dettaglio è cruciale perché introduce uno scenario molto probabile: primario e fallback potrebbero condividere lo stesso gateway, lo stesso pool di risorse o la stessa chiave API. In quel caso, anche se Hermes "cambia modello", nella pratica stai ancora bussando alla stessa porta già congestionata, e il problema persiste .

Non abbiamo prove sufficienti per affermare con certezza che i due percorsi condividano il backend — solo un controllo diretto del file di configurazione può confermarlo — ma è la prima ipotesi da verificare.

Cosa controllare per risolvere il problema alla radice

Ecco la lista di controllo, in ordine di priorità:

1. Apri il file config.yaml. Di solito si trova in ~/.hermes/config.yaml. Controlla:

   • Qual è il provider primario attualmente impostato.
   • La lista fallback_providers e in particolare se il fallback

     sg-claude-opus-4.7 via custom

     usa lo stesso gateway, endpoint o chiave API del primario .

2. Verifica lo stato del gateway. Se utilizzi OpenClaw come gateway, esegui

   openclaw gateway probe

   per controllare raggiungibilità e autenticazione. Se il gateway è in cooldown o presenta errori di autenticazione, potrebbe restituire falsi positivi di rate limit .

3. Controlla le chiavi API. Assicurati che le chiavi siano presenti e corrette sulla macchina che esegue il gateway. Se il gateway gira come servizio (systemd/launchd), le variabili d'ambiente vanno messe in ~/.openclaw/.env e il servizio va riavviato dopo la modifica .

4. Gestisci i contesti lunghi. Se l'errore compare prevalentemente in conversazioni molto lunghe, riduci la dimensione del contesto o verifica se il tuo piano provider ha limiti specifici per le richieste long-context .

5. Valuta un fallback su provider diverso. Se primario e fallback attuale condividono la stessa infrastruttura, valuta di aggiungere un secondo fallback che punti a un provider realmente separato (es. OpenRouter con un modello diverso, o un endpoint self-hosted) .

In sintesi

• Il messaggio si ripete perché Hermes sta facendo il suo lavoro: fallback per-turn, con tentativo di rientro sul primario a ogni nuovo messaggio .
• Il problema vero è che il provider primario è ancora in rate limit — o perché la finestra temporale non è scaduta, o perché primario e fallback condividono lo stesso collo di bottiglia .
• Per uscire dal loop devi intervenire sul primario, sulla catena di fallback o sul gateway, non sull'avviso stesso.

Vuoi una diagnosi precisa? Se mi dai accesso al file config.yaml attuale, posso indicarti esattamente qual è il primario che sta fallendo, dove punta il fallback sg-* e perché il loop si autoalimenta.