O script de deploy terminou, mas você não pode sair dali — será que o CI vai ficar vermelho? Será que a fila vai acumular? Quando o serviço vai estar realmente no ar? Então você atualiza a página a cada cinco minutos, como um sentinela dedicado.

O novo comando /loop do Hermes existe justamente para tirar esse turno de sentinela das suas mãos: re-executar um prompt em cadência recorrente dentro da sua sessão, acordando a cada tick para trabalhar com o estado atual. É a versão do Hermes do /loop do Claude Code (o alias /proactive também funciona aqui), recém-integrado ao main. Este post explica tudo direito: o que o separa fundamentalmente do /goal e do cron, e como usá-lo de verdade.

Três comandos, três drivers

Comando	Driver	Ciclo de vida	Uso típico
/goal	Judge-driven — após cada turno, um modelo julgador verifica “já terminou?”, e o Hermes continua trabalhando se não	Sessão única, ao longo dos turnos	“Corrigir todos os erros de lint em src/ e verificar que a verificação passa”
/loop	Timer-driven — acorda na cadência, faz o trabalho, até algo mandar parar	Sessão única, ao longo dos turnos e das retomadas	“Verificar o deploy a cada 5 minutos e me avisar quando estiver no ar”
cron	Schedule-driven — horário fixo, sem sessão envolvida	Fora de todas as sessões, sem supervisão	“Publicar um digest diário no canal às 9h”

/goal significa “continuar trabalhando até o objetivo ser alcançado”, /loop significa “continuar verificando até algo mandar parar”, cron significa “rodar em horário agendado, sem relação com a conversa”. Três ferramentas que não se sobrepõem.

Dois modos de cadência: você define o relógio, ou ela se autorregula

Intervalo fixo — o seu relógio

/loop 5m verifique o status do deploy e me diga se já está no ar

A cada 5 minutos (enquanto a sessão está ociosa), o Hermes injeta um turno real de agente contra o estado atual — o último resultado do CI, a profundidade mais recente da fila, o arquivo como ele está agora.

Self-paced — fica mais esperto quanto mais espera

Omita o intervalo e o Hermes se autocadencia:

/loop fique de olho na migração e resuma o progresso

O mecanismo é engenhoso: começa no piso de 60s e, enquanto as respostas do agente param de mudar, ele faz backoff exponencial (2m → 4m → 8m … até o teto de 15 minutos). No momento em que uma resposta difere, a cadência volta na hora para o piso. A detecção de mudança é uma comparação local de digest, insensível a timestamps — custo extra zero de LLM. Quanto mais calmo o cenário, menos ele te incomoda; no primeiro sinal de progresso, ele se aproxima.

Regra prática: intervalo fixo quando um relógio externo conduz o trabalho; self-paced quando o trabalho conduz o ritmo.

Condições de parada: cinco saídas

Condição	Como
O agente decide que terminou	Respostas de wakeup terminando com LOOP_COMPLETE em sua própria linha
Um limite de execuções	--times N (ex.: --times 30)
Uma condição baseada em evidências	--until <condição> — avaliada pelo mesmo aux judge que alimenta o /goal (fail-open: um judge quebrado nunca trava o loop)
Você	/loop stop (ou /loop pause para mantê-lo por perto)
O orçamento de segurança (backstop)	loops.max_ticks (padrão 100; 0 = ilimitado) para que uma sessão sem supervisão não queime tokens para sempre

/loop 2m consulte o CI --times 30
/loop 5m observe a fila --until "a profundidade da fila chegar a zero"

Controle e composição

• /loop status mostra a cadência, os ticks disparados e o tempo até o próximo wakeup; /loop pause / resume / stop cobrem todo o ciclo de vida (Ctrl+C durante um wakeup pausa o loop, recuperável via /loop resume).
• Faça loop de um comando de barra com a mesma facilidade: /loop 10m /recap.
• Trabalhando com /goal: um goal ativo e não estacionado é dono do limite de ociosidade — os ticks do loop esperam até o goal terminar, pausar ou estacionar (um wait barrier). Um goal estacionado combinado com um heartbeat de loop se compõe naturalmente. Entrada real do usuário sempre precede ambos — no momento em que você digita, os dois saem do caminho.

Por que ele não quebra: a arquitetura

Esta é a parte que vale a pena entender de verdade — /loop não é um loop while true:

1. Injeção comum de turno com papel de usuário (user-role turn): cada wakeup é uma mensagem normal de user-role. Nenhuma mutação do system prompt, nenhuma troca de toolset, o prompt cache permanece intacto — fazer loop não destrói seu cache nem desperdiça tokens.
2. Estado persistido: o estado do loop vive em SessionDB.state_meta sob loop:<session_id>, então /resume traz o loop de volta, e ele migra pela compressão de contexto (mesmo mecanismo do /goal, com o problema conhecido corrigido preventivamente).
3. Todas as superfícies: CLI, TUI, dashboard, app desktop e todas as plataformas de mensageria via gateway — um loop_wakeup_watcher supervisionado varre os loops persistidos e injeta wakeups vencidos em conversas ociosas mesmo enquanto você está ausente. Isso é algo que o Claude Code não consegue fazer (o loop dele morre junto com a sessão do CLI).
4. O caso do Slack: o Slack tem um limite de 50 comandos de barra, então o Hermes moveu /version para /hermes version para liberar um slot nativo para o /loop.

Comparado com o /loop do Claude Code

	Claude Code	Hermes
Superfícies	Apenas sessão do CLI	CLI, TUI, dashboard, desktop, todas as plataformas de mensageria
Persistência	Morre com a sessão	Sobrevive ao /resume e à compressão de contexto
Ritmo self-paced	Decidido pelo modelo	Backoff local por digest (grátis, determinístico)
Condições de parada	Embutidas no prompt	LOOP_COMPLETE + --times + --until julgado + backstop de orçamento
Interação com /goal	Recursos separados	Precedência explícita: o goal ativo é dono do limite de ociosidade

Qual deles eu quero?

• Observar estado externo (deploy, CI, fila, taxas de erro) → /loop (fixo ou self-paced)
• Um objetivo bem executado (corrigir todos os lints, deixar o CI verde) → /goal (veja Heartbeats, Refinamento e Goal Gates)
• Tarefas agendadas sem supervisão (digests diários, execuções noturnas) → cron (guia completo: O Guia Completo de Automação com Cron do Hermes)

Status do lançamento e como obtê-lo

/loop foi integrado ao main em 14 de agosto de 2026 (PR #72333, com 77 novos testes + 367 testes de regressão + 22 testes de desktop, todos passando). Ele ainda não está em nenhum lançamento oficial (o mais recente continua sendo o v0.20.1). Para experimentar:

• Espere o próximo lançamento e execute hermes update;
• Ou instale a partir do main agora: hermes update --branch main (volte assim que o lançamento sair).

Chaves de configuração opcionais: loops.min_interval_seconds, loops.max_ticks, loops.self_paced_floor_seconds, loops.self_paced_ceiling_seconds.

Para encerrar

/loop tira o “ficar de olho” das suas mãos de atualização manual: intervalos fixos para relógios externos, cadência self-paced que fica mais esperta quanto mais espera (backoff quando está estável, se aproxima quando algo muda — a custo zero de LLM), persistência e cobertura de todas as plataformas que superam o original do Claude Code, e cooperação explícita com o /goal. No próximo deploy, entregue o turno de sentinela a ele.