Beim ersten Mal fragt Hermes bei der Installation, ob du lokale Shared Metrics aktivieren willst. Die meisten antworten reflexartig mit Nein und denken nie wieder darüber nach. Dann kommt der Tag, an dem du wissen willst, was es gesendet hätte, du öffnest die Doku und landest in einer Wand aus Metrik-Namen und Consent-Window-Sprache. Also schließt du den Tab.

Hier kommt das Ganze in einem Durchgang. Die Kurzfassung: Alles ist standardmäßig aus; Sammlung und Übertragung sind zwei getrennte Opt-ins; aufgezeichnet werden begrenzte Zähler, niemals Prompts, Dateiinhalte, Pfade, Einstellungswerte oder Fehlertexte. Und eine am 6. Oktober gemergte Änderung macht diese Zähler zum ersten Mal wirklich nützlich für dich.

Zwei Schalter, kein Kontrollkästchen

Die Config liegt unter telemetry.shared_metrics in der config.yaml:

telemetry:
  shared_metrics:
    enabled: false   # lokal sammeln — standardmäßig aus
    send: false      # an Nous übertragen — standardmäßig aus
    endpoint: "https://telemetry.nousresearch.com/v1/telemetry"

Drei Dinge, die man wissen sollte:

• enabled sammelt, send überträgt. Sie sind unabhängige Opt-ins. Ist nur enabled an, bleibt alles auf deiner Maschine und verlässt sie nie.
• send setzt enabled voraus und impliziert es nie. Setzt du send: true bei enabled: false, loggt Hermes einen Fehler, statt dir still die Sammlung einzuschalten – ein Übertragungs-Flag sollte die Sammlung nicht starten können.
• Nur Pakete, deren gesamter Zeitraum in ein aufgezeichnetes Consent-Window fällt, werden gesendet. Stimmst du heute zu, wird nichts von vor heute nachträglich hochgeladen.

Der endpoint ist bewusst nicht durch eine Environment-Variable überschreibbar, und eine Nicht-HTTPS-Adresse wird abgelehnt, es sei denn, sie zeigt auf localhost.

Was tatsächlich aufgezeichnet wird

Die offizielle Liste ist lang, aber alles läuft auf ein Prinzip hinaus: begrenzte Zähler, geschlossene Wertemengen. Ein paar repräsentative Beispiele:

Metrik	Was sie aufzeichnet
hermes.process.exit	Wie ein CLI-/TUI-/gateway-/cron-Prozess endete: sauber, Crash (nur Exception-Familie), gekillt, Watchdog
hermes.tool_overhead.count	Gebucketer Zähler aktivierter Tools und der Tokens, die ihre Definitionen zu jeder Anfrage hinzufügen
hermes.tool_enabled_unused.count	Welche Standard-Toolsets du aktiviert und nie benutzt hast
hermes.feature_disabled.count	Welche Toolsets, Skills, Plugins oder Einstellungen du abgeschaltet hast
hermes.provider_setup.count	Wo das Provider-Setup scheiterte und in welcher Failure-Klasse
hermes.desktop.onboarding	Bei welchem Erststart-Schritt die Leute stehen bleiben

Namen erscheinen nur dann wörtlich, wenn sie von Hermes mitgeliefert sind – ein eigenes Toolset, Skill oder Plugin wird als custom aufgezeichnet. Einstellungen zeichnen den Key-Pfad auf, nie den Wert. Die Zusammenfassung der Doku selbst ist präzise: niemals Prompts, Dateien, Pfade, Einstellungswerte oder Fehlertexte.

Neu: Fehler sagen jetzt warum

Vor PR #133809 wusste die Telemetrie, dass ein Lauf fehlgeschlagen war und in welcher Stage er starb – aber nicht warum. Drei Zahlen machten den blinden Fleck offensichtlich: 22–27% der CLI-Installationen, die ein Update versuchten, trafen an jenem Tag auf einen Fehler (14–18% auf dem Desktop); etwa 35% der Skill-Install-Events scheitern und etwa 33% der Plugin-Installationen; und 12% der fehlgeschlagenen git-Updates lasen failed_stage=other, was bedeutet, dass jede Stage-Marke bestanden wurde und der Lauf trotzdem fehlschlug.

Die neue failure_class ist eine geschlossene Menge, abgeleitet an jeder Raise-Stelle oder aus dem Exception-Typ – der Nachrichtentext wird nie gelesen. Beispiele:

• 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;
• Jede Art: none, exception, filesystem_error, network, other, permission.

Auch die Fehletikettierung other ist behoben: Ein partielles Update – die Verifikation nach dem Neustart fand ein gateway- oder desktop-Backend nicht wieder auf dem neuen Code, ohne Stop-Grund – liest jetzt failed_stage=verify mit einem echten Grund. Skill- und Plugin-Installationen tragen außerdem ein registry-Feld, das endlich „der offizielle Index hat einen defekten Eintrag ausgeliefert“ von „die von dir eingegebene URL ist tot“ trennt. Diese beiden sahen früher identisch aus.

Warum eine frische Installation 7 Tage lang einen lokalen Beleg hinterlässt

Ein brandneues install.sh / install.ps1 meldete früher überhaupt nichts, weil die Consent-Frage erst nach der Installation kommt. Jetzt schreibt der Installer eine kleine Datei unter $HERMES_HOME/telemetry/shared_metrics/pending_installs/, wenn er fertig ist – oder wenn eine Stage fehlschlägt. Sie enthält nur Tokens aus geschlossenen Mengen und zwei Zeitstempel.

Sein Lebenszyklus beantwortet die zwei naheliegenden Sorgen:

• Der Installer sendet nie etwas. Er hinterlässt eine lokale Notiz. Die Meldung erfolgt später, bei einem Hermes-Start, und nur, wenn die Sammlung in diesem Moment an ist.
• Die Notiz lebt höchstens 7 Tage. Ein Beleg, den kein Start innerhalb von 7 Tagen gezählt hat, wird ungemeldet gelöscht, sodass eine alte Installation nie unter einer späteren Hermes-Version gezählt wird. Jede Opt-out-Antwort löscht ungemeldete Belege sofort.
• Ein einzelner --stage-Aufruf schreibt nichts, und eine mit Ctrl-C oder SIGTERM unterbrochene Installation wird als interrupted aufgezeichnet.

Wenn du also während der Installation mit Nein geantwortet hast, wird die Notiz gelöscht; wenn du Hermes nie wieder gestartet hast, verfällt sie von selbst.

Ein- oder Ausschalten

• Geführt: hermes setup telemetry stellt die beiden Fragen separat.
• Später: hermes tools oder der Toggle in den Einstellungen des Desktop.
• Manuell: bearbeite den config.yaml-Block oben.

Das Ausschalten der Sammlung entzieht auch die Sende-Zustimmung – Übertragung kann die Sammlung nicht überleben. Die Doku stellt ausdrücklich klar, dass das Deaktivieren von Shared Metrics die neue Sammlung stoppt, aber zuvor gesammelte lokale Daten nicht still löscht; das Löschen dieses Verzeichnisses liegt bei dir.

Was das für dich bedeutet

Wenn du das als „noch ein Privacy-Schalter“ gelesen hast, ist der Punkt: standardmäßig aus, zweistufiger Consent, Inhalte auf geschlossene Wertemengen beschränkt, und selbst Fehlergründe werden als feste Kategorien statt als Fehlertext aufgezeichnet. Wenn du es als „was bringt mir das“ gelesen hast, ist die neue failure_class die Antwort – deine Installations- und Plugin-Fehler landen jetzt in einem benannten Bucket, und ein Dashboard kann nicht mehr „eine Registry liefert massenhaft 404er“ mit „du hast einen Tippfehler in einer URL“ verwechseln.

Die Kurzfassung

Standardmäßig aus, Sammlung und Übertragung getrennt, und aufgezeichnet werden Kategorien und Zähler statt deiner Inhalte. Schalte send an, wenn du diese Zähler an Nous beitragen willst; wenn nicht, ändere nichts – und die vom Installer hinterlassene Notiz verschwindet still innerhalb einer Woche.

Um zuerst zu sehen, wie Hermes deine Daten lokal behandelt, lies Secret-Verschlüsselung und Keychain-Speicherung; für den Einstieg siehe den Installationsleitfaden.