Fallback-loopen i Hermes: Slik fikser du den irriterende «rate limited»-feilen for godt

Når en slik feil oppstår, bevarer Hermes hele samtalekonteksten og fortsetter sømløst med reservemodellen. Den kritiske detaljen her er at dette kun skjer for den enkeltstående turen (per-turn). Ved hver nye melding du sender, prøver Hermes først primærleverandøren igjen.

Hvorfor loopen oppstår

Du sitter fast i en loop fordi mekanismen fungerer akkurat som den skal, men den underliggende årsaken er ikke løst.

1. Primærkilden er fortsatt utilgjengelig: Den vanligste årsaken er at primærleverandøren din fortsatt returnerer en HTTP 429-feil på grunn av rate limiting. Så lenge denne tilstanden varer, vil hver eneste nye melding fra deg feile på første forsøk, og deretter trigge fallback-mekanismen.
2. Falsk trygghet via delte ressurser: Her ligger trolig kjernen i ditt spesifikke problem. Fallback-løsningen din peker mot sg-claude-opus-4.7 via custom. Dette indikerer at du bruker et egendefinert endepunkt (custom endpoint), konfigurert i config.yaml. Dersom både primærleverandøren din og dette egendefinerte endepunktet rutes gjennom den samme bakenforliggende gatewayen eller bruker den samme API-nøkkelpoolen, vil begge bli rammet av den samme rate limitingen. Du bytter i praksis fra en overbelastet vei til en annen identisk overbelastet vei, noe som kan gi inntrykk av at feilen vedvarer uansett hva du gjør.
3. Problemer med lange kontekster: Noen ganger utløses 429-feilen spesifikt fordi du sender svært lange meldinger eller har en omfattende samtalehistorikk. Leverandører som Anthropic kan da kreve «extra usage» og avvise forespørselen direkte.

Slik diagnostiserer og fikser du problemet

For å bryte ut av loopen må du identifisere og fjerne flaskehalsen. Start alltid med konfigurasjonsfilen.

1. Inspiser config.yaml

Dette er kommandosentralen. Åpne filen (vanligvis plassert i ~/.hermes/config.yaml) og se etter følgende:

• Primærmodell: Hvilken leverandør og modell er satt som hovedmodell?
• fallback_providers: Her ser du listen over reservemodeller, inkludert din sg-claude-opus-4.7 via custom.
• Egendefinerte endepunkter: Sjekk hvordan det egendefinerte endepunktet for sg-claude-opus-4.7 er satt opp. Hvilken URL og autentiseringsmetode bruker det?

Den store mistanken din bør være om primærendepunktet og det egendefinerte fallback-endepunktet deler samme bakenforliggende infrastruktur.

2. Kjør tilkoblingstester

Hvis du bruker en gateway som OpenClaw, kan du kjøre diagnostikkverktøy for å få klarhet i de faktiske feilmeldingene:

• openclaw gateway probe: Sjekker om gatewayen er responsiv og hvilket autentiseringsnivå som er oppnådd.
• openclaw gateway status --all: Viser detaljert status for alle tilkoblinger og eventuelle feil.

Se etter klare HTTP-statuskoder som 429. Dokumentasjonen bemerker at 429-feil spesifikt kan oppstå ved lange kontekster og krever feilsøking på gateway-nivå.

3. Sjekk API-nøkler og miljøvariabler

Autentiseringsfeil kan også trigge fallback, selv om problemet er et annet. Hvis gatewayen din leser nøkler fra miljøvariabler:

• Forsikre deg om at nøkkelen ligger i riktig ~/.openclaw/.env-fil på maskinen som kjører gatewayen.
• Etter endring, start gateway-prosessen på nytt og verifiser med openclaw status.

4. Vurder lange kontekster

Hvis problemet oppstår oftere i lange samtaler, kan du ha nådd en grense for kontekstlengde. Dette er en form for rate limiting der leverandøren krever høyere kvote, og vises gjerne som en spesifikk HTTP 429-feilmelding.

Oppsummering

Du ser denne meldingen gjentatte ganger fordi Hermes gjør akkurat det den skal – den prøver alltid primærkilden først, og faller tilbake når den feiler. For å stoppe loopen må du ikke tukle med fallback-innstillingene, men i stedet løse det underliggende kapasitetsproblemet. Den mest sannsynlige synderen er at primær- og fallback-konfigurasjonen din ubevisst konkurrerer om de samme, begrensede ressursene. Start jakten i config.yaml.