⚠️ Rate limited — switching to fallback provider... Por que essa mensagem aparece sem parar?

Se o seu Hermes Agent insiste em exibir a mensagem “⚠️ Rate limited — switching to fallback provider... 🔄 Primary model failed — switching to fallback: sg claude opus 4.7 via custom”, saiba que o comportamento está correto — mas a causa raiz é outra.

O que a mensagem realmente significa

• O Hermes Agent foi projetado para trocar automaticamente de modelo quando o principal encontra erros como rate limit, sobrecarga do servidor, falha de autenticação, queda de conexão ou resposta corrompida.
• Assim que o fallback é acionado, a conversa continua sem perda de contexto, usando o modelo reserva.
• Porém, o fallback vale apenas para aquele turno. Na requisição seguinte, o Hermes tenta novamente o modelo principal. Se ele continuar indisponível, o ciclo se repete.

Por que o alerta fica aparecendo sem parar

• O provedor principal ainda está sob limite de requisições (rate limit). A cada nova mensagem, a tentativa de voltar ao principal falha e o fallback é disparado outra vez.
• Quando o erro real é um

  HTTP 429

  , a documentação do OpenClaw classifica isso como um limite do provedor upstream. Não se trata de um problema de interface, mas de cota ou restrição no gateway.
• Em alguns cenários, o 429 está ligado a requisições de contexto longo (long‑context requests). Se o prompt ou o histórico da conversa for muito extenso, o provedor pode recusar ou apertar ainda mais a cota.

O ponto mais suspeito no seu caso

• O fallback aparece como “sg‑claude‑opus‑4.7 via custom”, o que indica que ele está passando por um endpoint customizado já configurado no Hermes, e não trocando para um provedor nativo completamente diferente.
• Se o modelo principal e o fallback usam o mesmo gateway, mesmo pool de chaves ou o mesmo backend, a troca acontece, mas o gargalo continua. Embora não seja possível afirmar categoricamente sem ver sua configuração real, essa é a hipótese mais provável.
• Os custom endpoints ficam salvos no config.yaml. A cadeia de fallback também fica lá, sob a chave fallback_providers.

O que você deve verificar agora

• Qual é o modelo principal atual e para onde a cadeia de fallback está apontando. Ambas as informações estão no config.yaml.
• Se o modelo principal e o

  sg‑claude‑opus‑4.7 via custom

  estão consumindo a mesma chave de API, o mesmo gateway ou o mesmo pool.
• Se estiver rodando sobre o gateway do OpenClaw ou um gateway customizado, execute uma sonda (

  openclaw gateway probe

  ) para confirmar se o erro real é 429, falha de autenticação ou um cliente/gateway desatualizado.
• Se o gateway lê a chave de uma variável de ambiente, certifique‑se de que a variável existe no host que roda o gateway e reinicie o processo após qualquer alteração.
• Se o problema aparece principalmente em conversas longas, verifique os limites de contexto longo — a documentação do OpenClaw alerta que “extra usage is required for long context requests” e isso pode gerar 429.

Resumo

• O alerta se repete porque o Hermes está seguindo à risca o mecanismo de fallback por turno, e o modelo principal ainda não saiu do rate limit.
• Para resolver de vez, é preciso tratar a origem do erro — modelo principal, gateway ou pool — e não apenas observar a mensagem de troca.

Quer uma análise precisa? Basta abrir o config.yaml que eu mostro exatamente qual modelo principal está falhando, para onde o fallback sg-* está apontando e por que ele insiste em voltar ao principal a cada turno.