fallback_providersQuindi, 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.
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:
openclaw gateway probeQuella 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.
Ecco la lista di controllo, in ordine di priorità:
Apri il file config.yaml. Di solito si trova in ~/.hermes/config.yaml. Controlla:
Verifica lo stato del gateway. Se utilizzi OpenClaw come gateway, esegui openclaw gateway probe.
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 .
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 .
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) .
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.
Comments
0 comments