No verão passado eu abri cinco contas de provedores de LLM em um mês. OpenAI, Anthropic, OpenRouter, Fireworks, Together. Em outubro eu já não fazia ideia de qual cartão de crédito era cobrado por qual. Em dezembro, um deles mudou de preço silenciosamente, e eu notei três semanas depois quando a fatura chegou.
Essa é a verdade sem glamour de rodar qualquer coisa em cima de LLMs em 2026: o zoológico de provedores é uma condição permanente. Modelos novos saem toda semana. Preços mudam. Tiers gratuitos se reorganizam. Um modelo que era estado da arte em março é nota de rodapé em maio. Se o framework do seu agente escolhe um provedor pra você na hora da instalação, você está assinando um contrato de reconstruir seu setup a cada dois meses.
O Hermes Agent vem apostando na direção oposta desde o dia um. O provedor é um valor de configuração, não uma escolha que a arquitetura faz por você. Três funcionalidades se empilham pra isso funcionar de verdade.
O roteador central (v0.2.0)
A fundação é um único ponto de chamada. Lá na v0.2.0, o projeto introduziu um roteador centralizado de provedores — uma única função call_llm() / async_call_llm() por onde toda parte do agente passa. Visão, sumarização, compressão, salvamento de trajetória, o loop principal de chat. Tudo passa pelo mesmo caminho de código.
Isso parece detalhe de refatoração até você tentar trocar de provedor num agente que não tem. Na maioria dos frameworks, existem onze lugares que batem no LLM, e cada um lê credenciais de um jeito ligeiramente diferente. Você muda um, esquece outro, coisas quebram de formas difíceis de notar. O Hermes tornou isso impossível fazendo existir um único lugar.
A cadeia de fallback (v0.6.0)
Duas semanas depois, a v0.6.0 adicionou a próxima camada: cadeias ordenadas de fallback entre provedores. Você lista provedores no config.yaml, e quando o primário dá erro — um rate limit 429, um 500 transitório, um endpoint inalcançável — o Hermes tenta automaticamente o próximo da cadeia.
Crucialmente, é ordenado, não round-robin. Você define uma preferência e um backup. Um setup típico é OpenRouter como default barato, Anthropic direto como backup confiável, e o tier gratuito do Nous Portal como fallback de emergência de último recurso. Se o topo da cadeia está tendo um dia ruim, você nem nota. A v0.6.0 corrigiu um bug sutil ao mesmo tempo: trocar de provedor via hermes model agora limpa o api_mode obsoleto em vez de gravar chat_completions em código, então endpoints compatíveis com Anthropic param de retornar 404s crípticos após uma troca.
Pools de credenciais (v0.7.0)
A release de resiliência adicionou a terceira camada: pools de credenciais do mesmo provedor. A sacada aqui é que "meu provedor primário" e "a API key específica que tenho naquele provedor" são coisas diferentes. Você pode ter três keys da Anthropic — pessoal, de equipe e uma reserva numa segunda conta — e quer que o Hermes use a que estiver menos ocupada.
Você configura via o assistente de setup ou um bloco credential_pool, e o Hermes escolhe a key least_used por padrão. Se uma key retorna 401, o pool automaticamente rotaciona pra próxima e marca a morta pra uma janela de reset. A implementação thread-safe permite rodar o CLI, um gateway Telegram e um cron job contra o mesmo pool sem que um pise no outro. A v0.7.0 também garantiu que o estado do pool sobrevive a trocas de provedor por fallback, então um 429 no primário não apaga o conhecimento do pool sobre quais keys estão cansadas.
Por que o empilhamento importa
Cada uma dessas funcionalidades resolve um problema estreito, mas o motivo de parecerem poderosas é que se compõem sem sobreposição:
- •O roteador permite trocar qual provedor num único lugar.
- •A cadeia de fallback permite lidar com falhas no nível do provedor sem reiniciar.
- •O pool de credenciais permite lidar com falhas e carga no nível da key dentro de um provedor.
E pelo CLI, hermes model permite reconfigurar tudo isso sem editar arquivos na mão. O efeito final é que quando um modelo novo chega — qualquer que seja, de quem for, com qualquer preço — o custo de migrar pra ele é "editar uma linha de config." Não "reconstruir meu assistente." Pra um projeto que vai sobreviver a muitas gerações de modelos, provavelmente é a única decisão de arquitetura que realmente importa.