La primera vez que instalas Hermes te pregunta si quieres activar las métricas compartidas locales. La mayoría responde que no por reflejo y no vuelve a pensarlo. Luego, un día quieres saber qué habría enviado, abres los docs y aterrizas en un muro de nombres de métricas y lenguaje de ventanas de consentimiento. Así que cierras la pestaña.

Aquí está todo de una pasada. La versión corta: todo está desactivado por defecto; la recopilación y la transmisión son dos opt-ins separados; lo que se registra son contadores acotados, nunca prompts, contenido de archivos, rutas, valores de ajustes ni texto de errores. Y un cambio fusionado el 6 de octubre hace que esos contadores sean útiles para ti de verdad por primera vez.

Dos interruptores, no una casilla

La config vive bajo telemetry.shared_metrics en config.yaml:

telemetry:
  shared_metrics:
    enabled: false   # recopila en local — desactivado por defecto
    send: false      # transmite a Nous — desactivado por defecto
    endpoint: "https://telemetry.nousresearch.com/v1/telemetry"

Tres cosas que conviene saber:

• enabled recopila, send transmite. Son opt-ins independientes. Con solo enabled activado, todo se queda en tu máquina y nunca sale de ella.
• send requiere enabled y nunca lo implica. Pon send: true con enabled: false y Hermes registra un error en vez de activar la recopilación por ti en silencio — un flag de transmisión no debería poder empezar a recopilar.
• Solo se envían los paquetes cuyo periodo completo cae dentro de una ventana de consentimiento registrada. Si aceptas hoy, nada de antes de hoy se sube de forma retroactiva.

El endpoint es a propósito no sobrescribible por una variable de entorno, y una dirección que no sea HTTPS se rechaza salvo que apunte a localhost.

Qué se registra de verdad

La lista oficial es larga, pero toda se reduce a un principio: contadores acotados, conjuntos de valores cerrados. Unos ejemplos representativos:

Métrica	Qué registra
hermes.process.exit	Cómo terminó un proceso de CLI / TUI / gateway / cron: limpio, crash (solo familia de excepciones), killed, watchdog
hermes.tool_overhead.count	Recuento por rangos de las herramientas activadas y los tokens que sus definiciones añaden a cada petición
hermes.tool_enabled_unused.count	Qué toolsets por defecto activaste y nunca usaste
hermes.feature_disabled.count	Qué toolsets, skills, plugins o ajustes desactivaste
hermes.provider_setup.count	Dónde se rompió la configuración del provider, y en qué clase de fallo
hermes.desktop.onboarding	En qué paso de la primera ejecución se queda la gente

Los nombres aparecen tal cual solo cuando los envía Hermes — un toolset, skill o plugin personalizado se registra como custom. Los ajustes registran la ruta de la clave, nunca el valor. El resumen que dan los propios docs es preciso: nunca prompts, archivos, rutas, valores de ajustes ni texto de errores.

Nuevo: los fallos ahora dicen por qué

Antes del PR #133809, la telemetría sabía que una ejecución había fallado y en qué etapa murió, pero no por qué. Tres números dejaban clara la zona ciega: el 22–27% de las instalaciones de CLI que intentaron una actualización chocaron con un fallo ese día (14–18% en desktop); alrededor del 35% de los eventos de instalación de skills fallan y cerca del 33% de las de plugins; y el 12% de las actualizaciones de git fallidas leían failed_stage=other, es decir, todas las marcas de etapa pasaron y la ejecución igualmente falló.

El nuevo failure_class es un conjunto cerrado, derivado en cada punto de lanzamiento o del tipo de excepción — el texto del mensaje nunca se lee. Ejemplos:

• 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;
• Todos los tipos: none, exception, filesystem_error, network, other, permission.

También se arregla la mala etiqueta other: una actualización parcial — la verificación posterior al reinicio encontró un backend de gateway o desktop que no volvió al código nuevo, sin motivo de parada — ahora lee failed_stage=verify con un motivo real. Las instalaciones de skills y plugins también llevan un campo registry, que por fin separa “el índice oficial sirvió una entrada rota” de “la URL que escribiste está muerta”. Esas dos antes se veían idénticas.

Por qué una instalación nueva deja un recibo local durante 7 días

Un install.sh / install.ps1 recién salido del horno antes no reportaba absolutamente nada, porque la pregunta de consentimiento llega después de la instalación. Ahora el instalador escribe un pequeño archivo bajo $HERMES_HOME/telemetry/shared_metrics/pending_installs/ cuando termina — o cuando falla una etapa. Contiene solo tokens de conjunto cerrado y dos timestamps.

Su ciclo de vida responde a las dos preocupaciones obvias:

• El instalador nunca envía nada. Deja una nota local. El reporte ocurre más tarde, en un arranque de Hermes, y solo mientras la recopilación esté activada en ese momento.
• La nota vive como máximo 7 días. Un recibo que ningún arranque contó en 7 días se borra sin reportar, así que una instalación antigua nunca se cuenta bajo una versión de Hermes posterior. Cualquier respuesta de opt-out borra al instante los recibos no reportados.
• Una sola llamada con --stage no escribe nada, y una instalación interrumpida con Ctrl-C o SIGTERM se registra como interrupted.

Así que si respondiste que no durante la instalación, la nota se borra; si nunca volviste a arrancar Hermes, caduca sola.

Activarla o desactivarla

• Guiado: hermes setup telemetry hace las dos preguntas por separado.
• Más tarde: hermes tools, o el toggle en los Settings del Desktop.
• Manual: edita el bloque de config.yaml de arriba.

Desactivar la recopilación retira con ella el consentimiento de envío — la transmisión no puede sobrevivir a la recopilación. Los docs son explícitos en que desactivar las métricas compartidas detiene la nueva recopilación pero no borra en silencio los datos locales recopilados antes; vaciar ese directorio es cosa tuya.

Qué significa esto para ti

Si lo leías como “otro interruptor de privacidad más”, el punto es: desactivado por defecto, consentimiento en dos fases, contenido limitado a conjuntos de valores cerrados, y hasta los motivos de fallo se registran como categorías fijas en vez de texto de errores. Si lo leías como “¿qué me aporta a mí?”, la respuesta es el nuevo failure_class: tus fallos de instalación y de plugins ahora caen en un bucket con nombre, y un dashboard ya no puede confundir “un registry devuelve 404s en masa” con “te equivocaste al escribir una URL”.

La versión corta

Desactivado por defecto, recopilación y transmisión separadas, y lo que se registra son categorías y recuentos en vez de tu contenido. Activa send si quieres aportar esos contadores a Nous; no cambies nada si no quieres, y la nota que dejó el instalador desaparecerá sola en una semana.

Para ver cómo maneja Hermes tus datos en local primero, lee cifrado de secretos y almacenamiento en Keychain; para empezar, mira la guía de instalación.