Vale a pena deixar o Hermes Agent sempre ligado ou chamar só quando precisa?

Fala aí, beleza? Antes de subir VPS, container e bot no Telegram, tem uma decisão que pesa mais que toda essa infra junta: você quer o agente sentado esperando ou quer chamar ele só quando precisa?

O Hermes Agent é um agente de IA open source da Nous Research, licença MIT, com o lema "The agent that grows with you" logo no README

A versão atual publicada é a v0.20.0 (tag v2026.8.3, a "The Herald Release", de 03/08/2026)

E aqui vai o ponto do post: escolher entre sob demanda e sempre no ar não é preferência estética, isso MUDA o que o agente consegue fazer

O que muda entre os dois modos na prática

Antes de comparar, bora deixar os dois modos concretos, porque eles são comandos diferentes, não configuração escondida

Sob demanda: você chama, ele responde, acabou

O caminho de chamada única é esse:

hermes -z "resuma os commits de hoje"

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

O -z devolve só o texto da resposta final, e isso é feito pensando em script e CI: a saída é limpa, dá pra jogar num pipe sem ficar catando ruído

Tem também a variação de chat:

hermes chat -q "resuma os commits de hoje"

O chat -q roda consulta única igual, porém inclui a saída de ferramentas no transcript

Qual usar? Se é máquina lendo, -z. Se você quer ver o que o agente fez pra chegar ali, chat -q

Sempre no ar: o gateway é o processo que fica de pé

hermes gateway        # roda em primeiro plano
hermes gateway start  # roda como serviço instalado

O gateway concentra Telegram, Discord, Slack, WhatsApp, Signal e a própria CLI em um único processo

É ele que transforma o agente em algo que outras pessoas (e o relógio) conseguem acionar sem você abrir terminal nenhum

A base é a mesma nos dois

Instalação é por script oficial (curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash, que já cuida de uv, Python, Node.js, ripgrep e ffmpeg) ou por git clone do repositório

Depois disso, hermes setup ou hermes model pra configurar o provedor de modelo, e hermes doctor pra diagnosticar a instalação

A base é idêntica nos dois modos, o que muda mesmo é ter ou não um processo vivo

Sob demanda x sempre no ar: custo, risco e capacidade

Repara que a linha mais dura da tabela é a primeira: ela não é "melhor/pior", é uma capacidade que simplesmente não existe do outro lado

Qual tipo de tarefa pede cada modo

É aqui que a decisão se resolve. Não é o seu perfil que escolhe o modo, é o TIPO de tarefa

1. Vigilância recorrente e relatório de manhã: gateway ligado

Se você quer algo tipo "toda manhã olhe X e me mande o resumo", precisa do gateway no ar, ponto

A tarefa se cria por /cron add dentro do chat ou por hermes cron create na CLI, informando o agendamento (expressão cron, intervalo ou linguagem natural) e um prompt autocontido

E tome cuidado com uma pegadinha boa aqui: sessões em segundo plano recebem só o prompt fornecido, sem conhecimento do histórico da sessão atual

Ou seja, aquele "faz igual eu te pedi ontem" não existe pro cron. O prompt tem que se bastar sozinho

2. Checagem repetida que não precisa de raciocínio

Tem tarefa que é só olhar se mudou. Pra essas, existe o cron sem LLM

Criando o job com no_agent=True, o scheduler roda o script e entrega o stdout, sem loop de agente e sem gasto de tokens

Isso é bem massa porque mata o argumento de "agente ligado queima dinheiro à toa" numa classe inteira de tarefa: se não precisa pensar, não pensa

3. Uso pontual dentro de script ou pipeline

Aqui o -z brilha, principalmente somado ao relatório de custo:

hermes -z "gere o changelog do último release" --usage-file ./report.json

O arquivo sai com estimated_cost_usd, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, reasoning_tokens, total_tokens, api_calls, model, provider, session_id, service_tier e as flags de completed/failed

Se você já usa outro agente no editor, vale entender Hermes ao lado do Claude Code antes de duplicar tarefa nos dois

4. Atendimento por mensageria pra você mesmo

Querer mandar mensagem no Telegram e o agente responder? Gateway obrigatório, não tem meio termo

E nada impede misturar: o mesmo usuário pode ter o gateway de pé pros crons e continuar chamando hermes -z dentro dos scripts. Os dois modos convivem no mesmo ambiente 🙂

O custo do modo sempre no ar (e como não pagar por ele à toa)

O custo do agente ligado vive em duas camadas, e elas se comportam de jeitos bem diferentes

Camada 1: a máquina

O README indica que o Hermes roda em VPS de US$ 5, em cluster de GPU ou em infra serverless (Daytona, Modal) que hiberna quando fica ociosa e custa quase nada entre sessões

Essa é a parte previsível da conta, e é a menor briga

Camada 2: o modelo

Aqui mora a variável de verdade, e o Hermes te dá volante: o provedor é trocável por hermes model entre Nous Portal, OpenRouter, OpenAI, Anthropic, Google Gemini ou endpoint próprio, sem alteração de código

E tem o caminho radical: dá pra rodar o Hermes inteiramente na sua máquina com Ollama e modelos open-weight, sem chave de API e sem assinatura

Esse detalhe muda TOTALMENTE a conversa de "deixar ligado o dia todo", porque muda a natureza do custo por token

E como saber quanto foi, de verdade

Não adianta achismo. O que transforma "acho que gastei" em número é a instrumentação que já vem junto:

• --usage-file no hermes -z, com custo estimado e tokens por chamada
• /usage dentro do chat, com detalhamento por categoria (tokens de entrada e de saída)
• dashboard web, que calcula uso e custo do histórico de sessões em 7, 30 ou 90 dias, com tokens totais, taxa de cache e quebra por modelo

Rode uma semana instrumentado antes de discutir se compensa. Número > opinião

O risco muda: agente ligado é uma porta aberta

Essa é a metade do assunto que o pessoal pula, e é justamente a que dói depois

O padrão do gateway é conservador na hora de decidir QUEM fala com o bot, e isso ajuda bastante: por padrão ele nega todos os usuários que não estão em allowlist ou pareados por DM, e o código de pareamento expira em 1 hora e tem limite de tentativas

A documentação é explícita num ponto: nunca defina GATEWAY_ALLOW_ALL_USERS=true em bot com acesso a terminal. O caminho é allowlist de usuário por plataforma (TELEGRAM_ALLOWED_USERS, DISCORD_ALLOWED_USERS) ou pareamento por DM

O texto que chega das plataformas de mensagem também é filtrado e enquadrado como entrada de terceiro não confiável, como defesa contra injeção de prompt

Onde está a fronteira real

E aqui vem a frase mais honesta da doc inteira, que eu acho ULTRA importante: a única fronteira de segurança contra um LLM adversarial é o sistema operacional

Nada dentro do processo do agente é contenção. Nem o portão de aprovação, nem redação de saída, nem scanner de padrão, nem allowlist de ferramenta

E repara que são duas allowlists diferentes, isso confunde muita gente: a allowlist de usuário do gateway decide quem consegue falar com o agente, é porteiro de entrada. Já a allowlist de ferramenta vive dentro do processo, e essa a doc não considera contenção contra o modelo

Traduzindo pro nosso caso: se você vai deixar ligado, a pergunta certa não é "o agente é bonzinho?", é "onde o shell dele roda?"

O Hermes tem 7 backends de terminal: local, Docker, SSH, Singularity/Apptainer, Modal, Daytona e Vercel Sandbox

O backend Docker roda os comandos em container com todas as capabilities removidas, sem escalação de privilégio e com limite de PIDs

Se esse assunto te deixou com a pulga atrás da orelha, vale avaliar a segurança do Hermes Agent antes de plugar suas contas nele

Vale a pena manter o Hermes Agent sempre ligado?

Não tenho rodada própria pra cravar aqui, então não vou fingir teste que não fiz

Mas a decisão se resolve com uma pergunta só, e ela é bem seca: quem dispara a tarefa?

Se quem dispara é o relógio ou outra pessoa numa mensagem, o gateway não é luxo, é requisito. Sem ele o cron não roda, e a conta de infra descrita no README é baixa perto do que isso destrava

Se quem dispara é sempre você, o modo sob demanda entrega exatamente o mesmo agente, com superfície menor e custo previsível por chamada

Minha leitura, e é leitura de projeto, não de bancada: comece sob demanda

Suba o gateway no dia em que aparecer a primeira tarefa que precisa disparar sozinha, e antes de abrir qualquer canal, isole o terminal em Docker ou sandbox

Tem um argumento a favor de manter o mesmo ambiente vivo, aliás: o Hermes tem laço de aprendizado embutido, ele cria skills a partir da experiência, melhora essas skills durante o uso, busca nas próprias conversas passadas e mantém contexto sobre você entre sessões

Ambiente estável tende a favorecer isso. Só não vou prometer resultado medido, porque medido eu não tenho…

Próximo passo

Caminho concreto pra você decidir com dado em vez de achismo:

1. Instale pelo script oficial ou por git clone do repositório. O erro comum deste passo é dispensar o instalador e depois travar por dependência faltando (uv, Python, Node.js, ripgrep, ffmpeg)
2. Rode hermes setup ou hermes model pra apontar o provedor de modelo. Vale lembrar que dá pra trocar de provedor depois sem mexer em código
3. Rode hermes doctor pra diagnosticar a instalação antes de sair usando
4. Pegue uma tarefa REAL sua e rode sob demanda por alguns dias, sempre com relatório:

hermes -z "sua tarefa aqui" --usage-file ./report.json

5. Olhe o dashboard web no período de 7 dias e veja tokens totais, taxa de cache e quebra por modelo. É esse número que responde "compensa?"
6. Se, e só se, aparecer tarefa recorrente, suba hermes gateway start com allowlist de usuário configurada e terminal isolado. O erro comum deste passo é criar o cron e ficar esperando ele rodar com o gateway desligado, porque sessão de chat na CLI não dispara job

Decide o modo primeiro, investe na infra depois. Nessa ordem a conta fecha bem melhor 😀

Abraço e até o próximo post!

Matheus Battisti, Hora de Codar