Você digita hermes update, o terminal rola a tela e a última linha avisa que a atualização deu certo. Mas o que exatamente foi instalado — um commit que entrou ontem ou uma release fechada há três dias? Em uma máquina que roda 24 horas por dia, essa pergunta importa: você não quer ficar para trás de uma correção, e também não quer acordar acompanhando a main em um estado em que ninguém pisou ainda.

A v0.21.7 trata exatamente disso. Não é um monte de funcionalidades; é uma mudança de política. Uma instalação via código-fonte agora se atualiza para a última release publicada, em vez de para cada commit da main. Este post cobre as duas partes práticas: em qual canal a sua instalação está e como comprovar o que está rodando.

O que realmente mudou é de onde vêm as suas atualizações

Uma instalação do Hermes via git costumava significar que hermes update puxava a árvore de trabalho até a ponta da main. As correções chegavam rápido, e você pisava em um chão que se movia: a main muda todos os dias, estados meio mesclados podem viver por horas, e a sua máquina podia se atualizar bem no meio de um deles.

A partir da v0.21.7, o padrão é: avançar apenas para a última release vX.Y.Z. Vale a pena ler as regras uma por uma, porque elas moldam a sua intuição sobre estar ou não atrasado:

• Mais antigo que a última tag → você sobe até essa tag.
• Já à frente da última tag (digamos que você acompanhava a main antes) → nada se move. Sua instalação fica onde está e espera a próxima release. Nada nunca é movido para trás.
• Forks e mirrors → continuam acompanhando a main, sem alteração.
• Microsoft Store, MSIX e o app desktop empacotado → o empacotamento não muda; eles se movem com os seus próprios builds.

Essa segunda regra é a que as pessoas leem errado como “as atualizações quebraram”. É de propósito: arrastar uma instalação que acompanha a main de volta para uma tag transformaria uma atualização de rotina em um downgrade, e o Hermes não faz isso.

Canal A: releases estáveis (o novo padrão)

Nada para configurar — uma instalação via código-fonte começa aqui. Você recebe a tag publicada mais recente, que agora é a v0.21.7.

Para quem serve: para quem prefere que outra pessoa pise no chão primeiro. Uma release é um ponto estável destilado de uma janela e não vira outra coisa da noite para o dia.

Canal B: cada commit (opt-in explícito)

Para continuar acompanhando cada commit da main, um comando:

hermes update --set-channel main

Depois de definido, o comportamento antigo volta. Voltar atrás é o mesmo tipo de comando:

hermes update --set-channel stable

Se o seu build é anterior a essas flags, rode um hermes update simples primeiro para pegar uma versão que entende de canais e só então troque.

O canal é um estado persistente, não uma flag de uso único para uma atualização. Defina uma vez e toda atualização posterior obedece — então não saia espalhando isso em um script que você vai esquecer.

Onde fica o switch no desktop

No app desktop, é em Settings ▸ About ▸ Updates, que tem um switch Update channel (Stable releases / Every commit). Ele só significa algo para uma instalação via código-fonte: instalações Store, MSIX e empacotadas não são afetadas pela sua escolha.

O diálogo de atualização também informa em qual canal você está agora, então você não precisa mais se apoiar no “acho que configurei isso uma vez”.

Duas interrupções do dia a dia corrigidas na mesma release

Mais dois itens no corpo da release caem na categoria “você só se importa quando acontece com você”:

O raciocínio sobrevive ao resume. Com modelos de raciocínio do Anthropic ou do Bedrock Converse, o thinking assinado é reproduzido corretamente depois de hermes chat --resume e no próximo turno do gateway, e os modelos de raciocínio do Bedrock Converse não são mais rejeitados em sessões retomadas. O mecanismo merece a sua própria explicação — quais rotas leem quais campos e o que acontece quando uma rota rejeita um campo — e escrevemos isso à parte: veja o guia de replay de raciocínio.

As atualizações não falham mais atrás de alguns firewalls. Instalações na main costumavam buscar um registro de release que firewalls regionais podiam responder com 403, o que fazia a atualização falhar de vez. A checagem agora usa o seu token do GitHub quando existe um (GITHUB_TOKEN, ou gh auth login) e reporta um rate limit do GitHub como rate limit, em vez de uma falha opaca.

Quanto entrou nesta janela

Os números de escala vêm do corpo oficial da release, medidos no commit 1fd18277267152893a8a24792b79213e7ca3f899:

Métrica	Valor
Commits não-merge	740
Arquivos alterados	4.156 (+86.775 / −26.980)
PRs mesclados	204
Issues fechadas	69

Assim como na v0.21.6, as notas curadas completas chegam com a v0.22.0, que vai documentar tudo a partir da v0.21.0, incluindo destaques, áreas de funcionalidade e créditos completos de contribuidores. O corpo da v0.21.7 também lista um lote de coisas deliberadamente deixadas fora do catálogo aqui: plugins rodando ações nativas do app, o pet bubble do SDK de plugins, skills instaladas no meio da sessão chegando ao modelo sem reconstruir o prompt, o Krea 2 Medium Turbo como a pista de imagens para assinantes pagos com fallback para a FAL, atualizações de desktop mais rápidas, instalações pinadas que fazem checkout só do pin, marcas de compactação emitidas para o Relay e novos plugins da comunidade. Estamos cobrindo isso um por um — a peça sobre ações de plugins já está no ar: ações de plugins do desktop e o pet bubble.

Comprovando qual versão você tem

Três comandos, escolha o que combina com a sua instalação:

# versão (uma instalação git também imprime a distância até a tag e o commit curto)
hermes version

# canal atual e origem da atualização (instalações via código-fonte)
hermes update --help

# instalações via desktop / instalador
hermes doctor

Se você suspeita que uma atualização reportou sucesso mas não mudou nada, verifique se a tag se moveu no hermes version e então leia hermes update --verbose. Para o contexto dos canais, veja o nosso guia do canal estável; para o pipeline de release que gerou esta tag, veja o post da release v0.21.6.

Atualização

# CLI
hermes update

# Desktop: se atualiza sozinho. Microsoft Store: atualiza pelo Store.

# Docker / Hermes Cloud
docker pull nousresearch/hermes-agent:stable

Uma autoverificação rápida após atualizar, para que o canal e a versão sejam o que você espera:

hermes version
hermes config get agent.max_turns      # também confirma que a atualização não mexeu na sua config

Em uma linha: a v0.21.7 transforma a atualização de algo que você vigia na main em algo que você pode deixar sozinho — ao preço de saber em qual canal você está. Configure uma vez e deixe a próxima tag fazer o resto.