A primeira vez que você instala o Hermes, ele pergunta se você quer habilitar as shared metrics locais. A maioria responde não por reflexo e nunca mais pensa no assunto. Então um dia você quer saber o que ele teria enviado, abre a documentação e cai num paredão de nomes de métrica e de linguagem de janela de consentimento. Aí você fecha a aba.

Aqui está tudo de uma vez. A versão curta: tudo fica desligado por padrão; coleta e transmissão são dois opt-ins separados; o que é registrado são contadores limitados, nunca prompts, conteúdo de arquivos, caminhos, valores de configuração ou texto de erro. E uma mudança mesclada em 6 de outubro torna esses contadores genuinamente úteis para você pela primeira vez.

Dois switches, não um checkbox

A configuração fica sob telemetry.shared_metrics no config.yaml:

telemetry:
  shared_metrics:
    enabled: false   # coleta localmente — desligado por padrão
    send: false      # transmite para a Nous — desligado por padrão
    endpoint: "https://telemetry.nousresearch.com/v1/telemetry"

Três coisas que vale saber:

• enabled coleta, send transmite. São opt-ins independentes. Com apenas enabled ligado, tudo fica na sua máquina e nunca sai dela.
• send exige enabled e nunca o implica. Defina send: true com enabled: false e o Hermes registra um erro em vez de ligar a coleta discretamente para você — uma flag de transmissão não deveria ser capaz de começar a coletar.
• Só são enviados pacotes cujo período inteiro cai dentro de uma janela de consentimento registrada. Se você optar hoje, nada de antes de hoje é enviado retroativamente.

O endpoint deliberadamente não é sobrescrevível por variável de ambiente, e um endereço não-HTTPS é recusado, a menos que aponte para localhost.

O que realmente é registrado

A lista oficial é longa, mas tudo se reduz a um princípio: contadores limitados, conjuntos de valores fechados. Alguns exemplos representativos:

Métrica	O que registra
hermes.process.exit	Como um processo CLI / TUI / gateway / cron terminou: limpo, crash (apenas família de exceção), morto, watchdog
hermes.tool_overhead.count	Contagem em faixas de ferramentas habilitadas e os tokens que suas definições adicionam a cada requisição
hermes.tool_enabled_unused.count	Quais toolsets padrão você habilitou e nunca usou
hermes.feature_disabled.count	Quais toolsets, skills, plugins ou configurações você desligou
hermes.provider_setup.count	Onde a configuração de provider quebrou, e em qual classe de falha
hermes.desktop.onboarding	Em qual etapa do primeiro uso as pessoas param

Nomes aparecem literalmente só quando são distribuídos pelo Hermes — um toolset, skill ou plugin customizado é registrado como custom. Configurações registram o caminho da chave, nunca o valor. O resumo da própria documentação é preciso: nunca prompts, arquivos, caminhos, valores de configuração ou texto de erro.

Novo: agora as falhas dizem por quê

Antes do PR #133809, a telemetria sabia que uma execução tinha falhado e em qual etapa ela morreu — mas não por quê. Três números deixavam o ponto cego óbvio: 22–27% das instalações via CLI que tentaram uma atualização naquele dia bateram numa falha (14–18% no desktop); cerca de 35% dos eventos de instalação de skill falham e cerca de 33% das instalações de plugin; e 12% das atualizações git que falharam liam failed_stage=other, significando que todas as marcas de etapa passaram e a execução ainda assim falhou.

A nova failure_class é um conjunto fechado, derivado em cada raise site ou a partir do tipo de exceção — o texto da mensagem nunca é lido. Exemplos:

• Skills: ambiguous, auth_rejected, fetch_failed, invalid_bundle, not_found, rate_limited, scan_blocked, stale_index;
• Plugins: clone_failed, deps_declined, git_missing, incompatible, manifest_invalid, removed_from_catalog;
• MCP: auth_required, config_invalid, connect_failed, missing_credentials, server_start_failed;
• Toda categoria: none, exception, filesystem_error, network, other, permission.

O rótulo errado de other também foi corrigido: um update parcial — a verificação pós-restart encontrou um gateway ou backend de desktop que não voltou para o código novo, sem motivo de parada — agora lê failed_stage=verify com um motivo real. Instalações de skill e plugin também carregam um campo registry, que finalmente separa “o índice oficial serviu uma entrada quebrada” de “a URL que você digitou está morta”. Esses dois costumavam parecer idênticos.

Por que uma instalação nova deixa um recibo local por 7 dias

Um install.sh / install.ps1 novinho em folha não reportava nada, porque a pergunta de consentimento vem depois da instalação. Agora o instalador grava um arquivinho sob $HERMES_HOME/telemetry/shared_metrics/pending_installs/ quando termina — ou quando uma etapa falha. Ele contém apenas tokens de conjunto fechado e dois timestamps.

O ciclo de vida dele responde às duas preocupações óbvias:

• O instalador nunca envia nada. Ele deixa uma nota local. O reporte acontece depois, num start do Hermes, e só enquanto a coleta está ligada naquele momento.
• A nota vive no máximo 7 dias. Um recibo que nenhum start contou dentro de 7 dias é apagado sem ser reportado, então uma instalação antiga nunca é contada sob uma versão posterior do Hermes. Qualquer resposta de opt-out apaga recibos não reportados imediatamente.
• Uma chamada única de --stage não grava nada, e uma instalação interrompida com Ctrl-C ou SIGTERM é registrada como interrupted.

Então, se você respondeu não durante a instalação, a nota é apagada; se você nunca iniciou o Hermes de novo, ela expira sozinha.

Ligando ou desligando

• Guiado: hermes setup telemetry faz as duas perguntas separadamente.
• Depois: hermes tools, ou o toggle nas Settings do Desktop.
• Manual: edite o bloco do config.yaml acima.

Desligar a coleta retira o consentimento de envio junto — a transmissão não pode sobreviver à coleta. A documentação é explícita de que desabilitar as shared metrics interrompe a nova coleta mas não apaga em silêncio dados locais coletados anteriormente; limpar esse diretório é decisão sua.

O que isso significa para você

Se você estava lendo isto como “mais um switch de privacidade”, o ponto é: desligado por padrão, consentimento em dois estágios, conteúdo limitado a conjuntos de valores fechados, e até os motivos de falha são registrados como categorias fixas em vez de texto de erro. Se você estava lendo como “o que isso faz por mim”, a nova failure_class é a resposta — as suas falhas de instalação e de plugin agora caem numa categoria nomeada, e um dashboard não consegue mais confundir “um registry está retornando 404 em massa” com “você digitou errado numa URL”.

A versão curta

Desligado por padrão, coleta e transmissão separadas, e o que é registrado são categorias e contagens em vez do seu conteúdo. Ligue o send se quiser contribuir com esses contadores para a Nous; não mude nada se não quiser, e a nota que o instalador deixou vai desaparecer discretamente dentro de uma semana.

Para ver como o Hermes lida com os seus dados localmente primeiro, leia criptografia de segredos e armazenamento no Keychain; para começar, veja o guia de instalação.