Não espere o Hermes travar: configuração de fallback em 3 camadas para manter tarefas rodando

Quando as pessoas começam a usar o Hermes, geralmente perguntam: qual modelo é forte o suficiente? Depois de usá-lo por um tempo, uma pergunta diferente se torna mais irritante: o modelo consegue levar uma tarefa até o final de forma confiável?

Imagine o seguinte: você dá ao Hermes uma tarefa de longa duração — organizar documentos, acompanhar uma página web, executar uma tarefa Cron, escrever um script ou analisar um lote de arquivos. Os primeiros 20 minutos correm bem. Então, perto do final, você vê:

HTTP 429
rate limit exceeded
quota exhausted
usage limit reached
provider overloaded

Este é o pior momento. A tarefa já está pela metade, o contexto se acumulou, as chamadas de ferramentas foram executadas e, de repente, a cota do modelo acabou, a API está limitada ou o provedor está com problemas. Trocar de modelo manualmente neste ponto geralmente significa reexplicar todo o contexto.

O Hermes não pode rodar de forma confiável com um único modelo, uma única chave e um único endpoint. Uma abordagem mais robusta é preparar três camadas de fallback com antecedência:

  1. Várias chaves para o mesmo provedor
  2. Fallback automático para um modelo de reserva quando o principal falhar
  3. Fallback separado para tarefas auxiliares como imagens, extração web e compressão

Vamos percorrer cada camada.

1. Por que tarefas longas são as mais vulneráveis a falhas no meio do caminho

Em conversas curtas, uma falha do modelo não é grande coisa. Você pergunta, ele falha, tenta novamente com outro modelo.

Tarefas longas são diferentes. O Hermes pode ter lido arquivos, aberto páginas web, executado comandos, gerado resultados intermediários e pode estar rodando sem supervisão dentro de um job Cron. Se ele parar pela metade, você perde não apenas a resposta, mas também o tempo, os tokens e o esforço de construção de contexto já investidos.

Os cinco pontos de falha mais comuns são:

Status Significado
429 Limite de taxa: muitas requisições em curto espaço de tempo
402 Problema de faturamento, saldo ou cota
500 / 502 / 503 Erro no servidor do provedor
401 / 403 Chave inválida ou permissões incorretas
404 / invalid response Nome de modelo, endpoint ou formato de resposta incorreto

Esses problemas não são resolvidos “usando um modelo mais inteligente”. O que você precisa fazer é preparar rotas alternativas para o Hermes com antecedência.

Pense no modelo principal como uma estrada principal. Geralmente é a mais rápida, mas quando ela fica congestionada, você não deve ficar parado. Você precisa de estradas secundárias, veículos de reserva e motoristas de reserva. As três camadas de fallback do Hermes são exatamente isso.

2. Camada 1: Mantenha várias chaves para o mesmo provedor

A primeira camada é a mais simples e a mais negligenciada: Credential Pools.

Ela resolve problemas dentro do mesmo provedor: uma chave acaba, é limitada ou se torna inválida. Por exemplo, se seu modelo principal é deepseek-v4-pro e você tem apenas uma chave de API da DeepSeek, o Hermes não tem escolha a não ser dar erro quando essa chave esgotar ou for limitada.

Se você adicionar várias chaves no mesmo provedor, o Hermes pode trocar para uma chave saudável e continuar.

Verifique as credenciais atuais:

hermes auth list

Adicione uma segunda chave da DeepSeek:

hermes auth add deepseek --api-key sk-your-second-deepseek-key

Se você também usa OpenRouter, adicione uma segunda chave lá também:

hermes auth add openrouter --api-key sk-or-v1-your-second-key

O valor aqui é prático:

  • Mesmo modelo principal
  • Mesmo provedor
  • Mesmo estilo de modelo
  • Apenas a chave muda no mesmo provedor

Recomendação: quem executa tarefas longas regularmente deve manter pelo menos duas chaves para o provedor principal. Isso vale especialmente se você usa o Hermes Cron para relatórios diários, monitoramento ou organização de documentos.

3. Como rotacionar chaves para que uma não seja esgotada

Depois de adicionar várias chaves, você precisa decidir como usá-las. O Hermes suporta estratégias de rotação por provedor. Em resumo: você usa a primeira chave até ela falhar, ou rotaciona entre as chaves?

Exemplo de configuração:

credential_pool_strategies:
  deepseek: round_robin
  openrouter: least_used

Estratégias comuns:

Estratégia Comportamento
fill_first Usa a primeira chave até falhar, depois troca
round_robin Rotaciona entre as chaves uma a uma
least_used Prefere a chave com menor uso até o momento
random Escolhe uma chave aleatoriamente
  • Se você tem apenas duas chaves de reserva e quer uso equilibrado, use round_robin.
  • Se você tem várias chaves com cotas diferentes e quer evitar esgotar uma cedo demais, experimente least_used.

Uma pequena ressalva: trocar de chave pode invalidar o cache de prompt. Quando o Hermes troca para uma nova chave, essa chave pode não ter o cache de contexto anterior, então a próxima requisição pode precisar reler o contexto completo. Isso custa tokens de entrada extras.

Então, os pools de credenciais não se tratam realmente de economizar dinheiro. Tratam-se de manter a tarefa viva. Para tarefas longas, é melhor pagar um pouco mais do que perder toda a execução.

4. Camada 2: Fallback automático para um modelo de reserva

A camada 1 resolve problemas de nível de chave dentro de um provedor. A camada 2 resolve o problema maior: todo o provedor ou o modelo principal fica instável.

Suponha que seu modelo principal seja deepseek-v4-pro. Se o endpoint da DeepSeek estiver congestionado ou a cota da sua conta estiver esgotada, trocar para outra chave da DeepSeek pode não ajudar, porque o problema está do lado do serviço ou no nível da conta.

É aí que entram os provedores de fallback.

Use a configuração interativa:

hermes fallback

Ou edite ~/.hermes/config.yaml diretamente. Aqui está um exemplo prático:

model:
  provider: deepseek
  default: deepseek-v4-pro

fallback_providers:
  - provider: zai
    model: glm-5.2
  - provider: kimi-coding
    model: kimi-k2.7-code

O que isso significa:

  1. Normalmente use deepseek-v4-pro
  2. Se a DeepSeek falhar, mude para GLM 5.2
  3. Se o GLM 5.2 também falhar, mude para Kimi K2.7

Os nomes dos modelos devem corresponder aos IDs mostrados no console real do provedor, em hermes model ou na lista de modelos. A nomenclatura varia por provedor, então sempre verifique o ID exato.

Essa configuração é ideal para tarefas longas: organizar um lote de materiais, rodar um job em segundo plano de 30 minutos ou analisar uma base de código. Quando o modelo principal falha, o Hermes continua sem que você precise intervir no meio do caminho.

5. Camada 3: Dê às tarefas auxiliares seu próprio fallback também

Muitas pessoas configuram fallback apenas para o modelo de chat principal. Mas o Hermes também depende de muitas tarefas auxiliares:

  • Análise de imagens
  • Extração web
  • Compressão de contexto
  • Geração de título de sessão
  • Busca de skills
  • Ações auxiliares de MCP
  • Julgamento de aprovação de comandos

Essas tarefas também podem chamar modelos. Se não tiverem fallback, podem arrastar toda a execução para baixo.

Por exemplo, quando você pede ao Hermes para ler uma página web, ele pode primeiro realizar uma extração web; quando o contexto fica muito longo, ele pode comprimi-lo; quando você envia uma captura de tela, ele pode chamar um modelo de visão.

Você pode configurar fallback separadamente para essas tarefas:

auxiliary:
  compression:
    provider: zai
    model: glm-5.2
    fallback_chain:
      - provider: kimi-coding
        model: kimi-k2.7-code
      - provider: deepseek
        model: deepseek-v4-pro

  web_extract:
    provider: kimi-coding
    model: kimi-k2.7-code
    fallback_chain:
      - provider: zai
        model: glm-5.2

Isso significa:

  • A compressão de contexto começa com GLM 5.2, faz fallback para Kimi K2.7 e finalmente para DeepSeek
  • A extração web começa com Kimi K2.7 e depois faz fallback para GLM 5.2

Tarefas auxiliares valoram estabilidade, baixo custo e velocidade adequada. Você pode reservar o modelo mais forte para a tarefa principal e usar modelos mais baratos e rápidos para extração, compressão e geração de títulos. Mas se a tarefa é crítica — revisão de contratos, organização de base de código com contexto longo ou resumos de materiais de clientes — dar às tarefas auxiliares seu próprio fallback vale a pena.

6. Reduza as tentativas de repetição para trocar para o reserva mais rápido

O Hermes repete algumas vezes por padrão antes de acionar o fallback. Isso é sensato porque alguns erros 429 ou de rede são apenas breves falhas. Esperar alguns segundos pode evitar o custo e a mudança de estilo de trocar de modelo.

Mas se um provedor é frequentemente instável por longos períodos, você pode fazer o Hermes trocar mais rápido:

agent:
  api_max_retries: 1

Ou ainda mais agressivamente:

agent:
  api_max_retries: 0

Configurações sugeridas:

  • Conversa casual: mantenha o padrão
  • Tarefas longas: considere 1
  • Jobs Cron sem supervisão: considere 0 ou 1
  • Tarefas sensíveis a custos: evite ser muito agressivo

Por que não configurar sempre como 0? Cada troca de provedor pode invalidar caches, e em tarefas de contexto longo os tokens de entrada podem aumentar consideravelmente. Então o parâmetro não é “quanto menor, melhor”. Uma abordagem equilibrada é reduzir as repetições para tarefas longas importantes, mantendo o padrão para tarefas comuns.

7. Uma configuração prática de fallback para tarefas de longa duração

Para um ambiente que executa tarefas longas do Hermes regularmente, aqui está um projeto possível:

  • Principal: deepseek-v4-pro para contexto longo e capacidade geral
  • Primeiro reserva: glm-5.2 para tarefas longas, código, raciocínio e fluxos de trabalho complexos
  • Segundo reserva: kimi-k2.7-code para continuação de código, compreensão de projeto e processamento de materiais longos

Exemplo de configuração:

model:
  provider: deepseek
  default: deepseek-v4-pro

fallback_providers:
  - provider: zai
    model: glm-5.2
  - provider: kimi-coding
    model: kimi-k2.7-code

credential_pool_strategies:
  deepseek: round_robin
  zai: fill_first
  kimi-coding: fill_first

agent:
  api_max_retries: 1

auxiliary:
  compression:
    provider: zai
    model: glm-5.2
    fallback_chain:
      - provider: kimi-coding
        model: kimi-k2.7-code
      - provider: deepseek
        model: deepseek-v4-pro

  web_extract:
    provider: kimi-coding
    model: kimi-k2.7-code
    fallback_chain:
      - provider: zai
        model: glm-5.2

  title_generation:
    provider: deepseek
    model: deepseek-v4-pro

Após salvar, reinicie o Gateway:

hermes gateway restart

Depois verifique a configuração:

hermes config check

Se preferir não escrever YAML manualmente, comece com os comandos interativos:

hermes model
hermes fallback
hermes auth list

Recomendação para iniciantes: não configure todos os modelos de uma vez. Faça em três passos:

  1. Adicione uma segunda chave para seu provedor principal
  2. Adicione um provedor de fallback
  3. Por fim, configure o fallback para compression e web_extract

Isso facilita a solução de problemas.

8. Quais tarefas mais se beneficiam dessa configuração de três camadas

Nem todas as tarefas precisam dessa complexidade. Se você está apenas fazendo algumas perguntas casuais, três camadas de fallback são exagero. Mas os seguintes cenários valem a pena ser configurados cedo:

  • Jobs agendados do Hermes Cron
  • Tarefas longas de organização de documentos
  • Tarefas de análise de base de código
  • Busca e extração de várias páginas
  • Tarefas que comprimem contextos longos com frequência
  • Tarefas de projetos de clientes
  • Fluxos de trabalho em segundo plano sem supervisão

Jobs Cron são o exemplo clássico. Você pode pedir ao Hermes para resumir notícias de IA todas as manhãs ou verificar um site a cada hora. Você não está no computador quando ele executa, e se a cota do modelo acabar, o job falha. Com pools de credenciais e fallback, a tarefa tem outro caminho a seguir.

A análise de base de código é outro caso importante. O Hermes lê muitos arquivos e constrói o contexto do projeto. Se o modelo falhar nesse ponto, recomeçar do zero desperdiça muito esforço. O fallback permite que ele continue a partir do contexto existente.

Pontos principais

Lembre-se desta frase: Para tarefas longas do Hermes, configure o fallback do modelo antes de as coisas quebrarem, não depois.

As três camadas mais práticas são:

  1. Credential Pools: mantenha várias chaves para o mesmo provedor e rotacione automaticamente em limites de taxa ou problemas de cota.
  2. Fallback Providers: troque automaticamente para um provedor e modelo de reserva quando o principal falhar.
  3. Auxiliary Fallback: dê a tarefas auxiliares como extração web, análise de imagens e compressão de contexto suas próprias rotas de reserva.

Uma combinação sólida de modelos poderia ser:

  • Principal: deepseek-v4-pro
  • Primeiro reserva: glm-5.2
  • Segundo reserva: kimi-k2.7-code

Comandos-chave para lembrar:

hermes auth list
hermes auth add deepseek --api-key sk-your-second-deepseek-key
hermes fallback
hermes config check
hermes gateway restart

Um lembrete final: fallback é sobre manter as tarefas rodando, não sobre perfeição. O custo pode ser invalidação de cache, maior uso de tokens e pequenas mudanças no estilo de resposta. Portanto, é mais adequado para tarefas longas importantes, tarefas agendadas e fluxos de trabalho sem supervisão. Para conversas comuns, mantenha as coisas simples. Quando você realmente precisar que o Hermes funcione, não dependa de um único modelo.