Você passa meia hora reescrevendo o SOUL.md. Adiciona duas regras novas a uma skill. Reinicia o gateway, volta para a session que está rodando desde ontem e pede que ela refaça a tarefa que acabou de fazer. A resposta vem com a voz antiga, segue os passos antigos e insiste naquelas coisas que você acabou de mandar parar de fazer. Você abre o arquivo de configuração três vezes para conferir se a edição realmente foi salva. No fim, faz a única coisa que sobrou: /new — e assiste quarenta turnos de contexto desaparecerem.

A configuração estava certa. O Hermes estava ignorando de propósito, para economizar o seu dinheiro. Agora existe um comando que atualiza as instruções sem mexer na conversa.

Por que uma session em execução não enxerga a sua edição

Os providers de modelo têm um truque para economizar: quando o começo de cada requisição é idêntico byte a byte, o provider reaproveita o cálculo que já está em cache em vez de recalculá-lo. Esse prefixo é o system prompt — o bloco que carrega a persona do seu SOUL.md, o índice de skills, as regras de projeto do AGENTS.md, a memory e o USER.md.

Para manter esse prefixo estável, o Hermes monta o system prompt de uma session uma única vez, guarda o resultado e repete exatamente aqueles bytes em todo turno seguinte. Depois de um restart do gateway, ele restaura a cópia guardada a partir da linha da session; um agent mantido aquecido na memória nunca relê os arquivos.

Ou seja: só uma session novíssima lê os arquivos. As conversas antigas continuam repetindo o prompt com que nasceram — que é exatamente o que você estava vendo.

O comando: hermes sessions refresh-prompts

# toda session deste profile
hermes sessions refresh-prompts

# apenas uma session (id ou prefixo único)
hermes sessions refresh-prompts --session a1b2c3

# outro profile
hermes sessions refresh-prompts -p work

# legível por máquina, útil dentro de um script de atualização
hermes sessions refresh-prompts --json

O que ele faz é propositalmente pequeno: registra um pedido de refresh no state.db do profile e imprime quantas sessions têm um prompt guardado. O trabalho de verdade acontece no início do próximo turno de cada session.

A saída é mais ou menos assim:

Requested a system prompt refresh for every session in this profile (12 session(s) with a stored prompt).
Each rebuilds its prompt from the current SOUL.md, skills and context files on its next turn (one prompt-cache miss per session); conversation history is kept.

Com --session existe um caso de borda já resolvido para você: uma conversa compactada continua a partir da sua ponta, então o pedido fica vinculado a essa continuação e não à raiz encerrada de onde ela foi comprimida.

O que de fato é reconstruído

• Reconstruído: o system prompt inteiro passa pelo builder normal, então o novo SOUL.md, as skills adicionadas ou removidas, o AGENTS.md e os context files passam a valer naquele turno. Os blocos de memory e USER.md também são relidos do disco.
• Intocado: o histórico da conversa, o id da session e a lista de tools fixada da session. O hook on_session_start não dispara, então nenhum dos efeitos colaterais dele roda de novo.
• Custo: um prefix-cache miss por session atualizada, no turno que faz a reconstrução. Os turnos seguintes voltam a usar cache.
• Persistência: o novo prompt e o carimbo de versão dele são gravados de volta no state.db, e todo turno posterior os repete literalmente. É uma reconstrução única, não um custo por turno.

Não é preciso reiniciar o gateway, e um restart não cancela o pedido: ele fica no banco, então um agent que volta depois de um restart ainda o lê. Um script de atualização pode chamar o comando antes ou depois de trocar o gateway.

Como ele sabe que um refresh está pendente

O Hermes mantém um epoch incremental no state_meta do profile — pense nele como um número de revisão das suas instruções. Cada session registra, no seu model_config, qual revisão o prompt guardado já atende. No começo do turno o agent faz uma leitura pontual: se o epoch guardado estiver mais velho, ele reconstrói uma vez; caso contrário, não faz nada.

Sem nenhum pedido registrado, o único trabalho extra é essa leitura. Nada vigia arquivos em background e nada troca as instruções no meio de um turno.

Quando usar — e quando não usar

O que você acabou de mudar	Rodar refresh-prompts?
SOUL.md, skills, AGENTS.md, USER.md	Sim — é para esse caso que o comando existe
Só o modelo ou as configurações de sampling	Não precisa
Definições de tools ou permissões de tools	Sessions novas já pegam; o pin de tools de uma session existente continua como estava
Você quer começar do zero em um assunto novo	Use /new; este comando não limpa o histórico
A própria linha da session está corrompida	Use hermes sessions repair-prompts, que é outro comando

Duas ressalvas. Primeiro, atualizar não repete o histórico nem conserta uma conversa quebrada — só substitui o prefixo de instruções. Segundo, se você roda muitas sessions longas e paga por token, prefira --session: cada session atualizada paga o próprio cache miss, e em dezenas de conversas isso soma.

Se a sua dúvida é outra — por que as instruções ficam desatualizadas depois da compactação — esse é um mecanismo separado: o Hermes reconstrói o system prompt durante a compactação. Os detalhes estão em como a compactação reconstrói o prompt. Se você acabou de mover skills para o repositório, leia primeiro skills locais do projeto e o gate de confiança — o refresh é só o jeito como uma session viva alcança essas skills. E a mecânica de compartilhar um prefix cache entre sessions está em compartilhamento de prompt cache entre profiles. A referência completa de flags fica na página do comando hermes sessions.

Status da release

O comando entrou na main em 29 de outubro de 2026 (PR #143581). A release atual, v0.22.5 (23 de outubro de 2026), ainda não o inclui — se hermes sessions --help não lista refresh-prompts, você está em um build mais antigo. Instale a partir da main para usar agora, ou espere a próxima release.

Edite os arquivos, rode um comando, e o turno seguinte já está com as instruções novas — sem trocar uma conversa por isso.