Claude Code Telemetry: OpenTelemetry, DSGVO, Betriebsrat

TL;DR

Claude Code Telemetry bleibt aus, bis Sie CLAUDE_CODE_ENABLE_TELEMETRY=1 und einen OpenTelemetry-Exporter setzen. Dann liefert Claude Code 8 Metriken (Sitzungen, Tokens, Kosten, Zeilen, Commits, PRs, Edit-Entscheidungen, Aktivzeit) an Ihren Collector. Prompts bleiben standardmäßig geschwärzt. Auf Bedrock und Vertex ist OpenTelemetry die einzige Nutzungsansicht. Werten Sie pro Team aus, nicht pro Person.

Was exportiert Claude Code Telemetry genau?

Claude Code Telemetry sind OpenTelemetry-Daten, die Claude Code an einen Collector Ihrer Wahl schickt: Metriken als Zeitreihen, Events über das Logs-Protokoll, Traces optional als Beta. Ohne Ihr Zutun fließt nichts. Pflicht ist CLAUDE_CODE_ENABLE_TELEMETRY=1, dazu je Signal ein Exporter wie otlp, prometheus oder console.

Die Monitoring-Dokumentation nennt acht Metriken. Metriken gehen standardmäßig alle 60.000 ms raus, Logs alle 5.000 ms. Der Meter heißt com.anthropic.claude_code. Als service.name meldet das Terminal claude-code, der Code-Tab der Desktop-App claude-code-desktop. Wer im Dashboard nur auf den ersten Wert filtert, verliert die Desktop-Nutzung.

Metrik	Was gezählt wird	Nützliche Attribute
`claude_code.session.count`	Gestartete Sitzungen	`start_type` (fresh, resume, continue)
`claude_code.token.usage`	Tokens	`type` (input, output, cacheRead, cacheCreation), `model`
`claude_code.cost.usage`	Geschätzte Kosten in USD	`model`, `query_source`, `effort`
`claude_code.lines_of_code.count`	Hinzugefügte und entfernte Zeilen	`type`, `model`
`claude_code.commit.count`	Erstellte Git-Commits	Standardattribute
`claude_code.pull_request.count`	Erstellte PRs oder MRs	Standardattribute
`claude_code.code_edit_tool.decision`	Angenommene oder abgelehnte Edits	`decision`, `language`
`claude_code.active_time.total`	Aktive Zeit in Sekunden	`type` (user, cli)

Events sind die Detailebene: claude_code.user_prompt, claude_code.api_request mit cost_usd, duration_ms und Tokenzahlen pro Aufruf, claude_code.tool_result, claude_code.tool_decision, claude_code.api_error und gut zwanzig weitere. Über prompt.id lässt sich jeder API-Aufruf einem einzelnen Prompt zuordnen. Für ein Kosten-Dashboard brauchen Sie die Metriken. Events sind Material für Security-Audit und SIEM, und genau deshalb heikel.

Wie erzwingen Sie Telemetrie für das ganze Unternehmen?

Über die Managed-Settings-Datei auf jedem Entwicklerrechner. Managed Settings schlagen Nutzereinstellungen, und Claude Code ignoriert OpenTelemetry-Exporter-Variablen in der .claude/settings.json eines Repositorys. Ein Repo kann Telemetrie also weder einschalten noch umleiten noch Prompt-Erfassung aktivieren. Abschalten kann ein Entwickler ein Signal weiterhin, solange Sie den Exporter nicht ebenfalls zentral setzen.

Die Datei liegt laut Managed-Settings-Doku unter /Library/Application Support/ClaudeCode/managed-settings.json (macOS), /etc/claude-code/managed-settings.json (Linux und WSL) und C:\Program Files\ClaudeCode\managed-settings.json (Windows). Gehört die Hauptdatei einem anderen Team, legen Sie eine eigene 10-telemetry.json in das Verzeichnis managed-settings.d/ daneben. Claude Code liest zuerst die Hauptdatei, dann alle *.json dort in alphabetischer Reihenfolge.

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "none",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "https://otel.example.internal:4317",
    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer REPLACE_ME",
    "OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE": "cumulative",
    "OTEL_METRICS_INCLUDE_ACCOUNT_UUID": "false",
    "OTEL_METRICS_INCLUDE_SESSION_ID": "false",
    "OTEL_RESOURCE_ATTRIBUTES": "department=engineering,team.id=plattform,cost_center=kst-4711"
  }
}

Vier Entscheidungen stecken in dieser Datei:

OTEL_LOGS_EXPORTER steht auf none. Kosten- und Adoptionsfragen beantworten die Metriken. Events tragen Identität pro Prompt und gehören, wenn überhaupt, in eine getrennte Pipeline mit engem Zugriffskreis.
Ein zentral gesetzter OTEL_EXPORTER_OTLP_ENDPOINT sperrt das Ziel. Seit v2.1.217 entfernt Claude Code beim Start alle vom Entwickler gesetzten signalspezifischen Endpunkte.
cumulative setzen wir für eine Prometheus-Pipeline. Standard ist delta, die Doku empfiehlt den Wechsel, wenn Ihr Backend kumulative Werte erwartet.
OTEL_RESOURCE_ATTRIBUTES hängt Team und Kostenstelle an jeden Datenpunkt. Leerzeichen sind verboten: org.name=Team_Plattform, nicht Team Plattform. Anführungszeichen helfen nicht, sie landen im Wert.

Zur Kontrolle starten Sie eine Sitzung und suchen claude_code.session.count im Backend. Kommt nichts an, starten Sie claude --debug-file /tmp/cc.log und suchen nach [3P telemetry]. Zeilen mit [Anthropic telemetry] betreffen Anthropics eigene Betriebstelemetrie, nicht Ihr Setup.

Welcher Collector hält die Daten auf Teamebene?

Ein OpenTelemetry Collector, der OTLP empfängt, die Identitätsattribute löscht und erst danach an Prometheus oder Ihr Observability-Backend exportiert. Claude Code hängt user.id immer an, user.email bei Anmeldung mit Claude-Konto, Konto-UUIDs, solange Sie sie nicht abschalten. Diese Felder müssen weg, bevor sie in einem Speicher landen, den eine Führungskraft abfragen kann.

Der Attributes Processor arbeitet auf Traces, Metriken und Logs, Stabilität Beta, und kennt delete und hash. Gehasht wird mit SHA1. Das ergibt einen stabilen Schlüssel pro Person, also Pseudonymisierung nach Art. 4 Nr. 5 DSGVO, keine Anonymisierung. Eine gehashte E-Mail bleibt ein personenbezogenes Datum. Für ein Team-Dashboard löschen wir. Memory Limiter und Batch folgen der Collector-Konfigurationsreferenz.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  memory_limiter:
    check_interval: 5s
    limit_mib: 512
  attributes/strip_identity:
    actions:
      - { key: user.email, action: delete }
      - { key: user.id, action: delete }
      - { key: user.account_uuid, action: delete }
      - { key: user.account_id, action: delete }
      - { key: session.id, action: delete }
      - { key: enduser.id, action: delete }
  resource/strip_identity:
    attributes:
      - { key: user.email, action: delete }
      - { key: enduser.id, action: delete }
  batch: {}

exporters:
  prometheus:
    endpoint: 0.0.0.0:8889

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, attributes/strip_identity, resource/strip_identity, batch]
      exporters: [prometheus]

Übrig bleiben team.id, department, cost_center, model, type, organization.id und die Betriebssystem-Attribute. Das reicht für jede Kennzahl unten. Zusätzlich würden wir Filter sperren, die auf weniger als fünf Personen zeigen. Ein Team aus zwei Leuten ist ein Einzelreport mit Umweg. Die Fünf ist unsere redaktionelle Schwelle, keine gesetzliche Zahl.

Ohne Collector kann Claude Code mit OTEL_METRICS_EXPORTER=prometheus selbst einen Scrape-Endpunkt unter http://localhost:9464/metrics öffnen. Für einen Rechner taugt das. Für ein Team hieße es, Laptops zu scrapen. Davon raten wir ab.

Welche Dashboard-Kennzahlen beantworten Kosten und Adoption?

Fünf Kennzahlen decken ab, was Budgetverantwortliche und Engineering-Leads fragen: Sitzungen pro Team, Tokens nach Typ und Modell, geschätzte Kosten pro Kostenstelle, angenommene gegenüber abgelehnten Edits und geänderte Zeilen. Gruppieren Sie nach team.id oder cost_center, über Wochen statt Tage. Die Kostenzahl gleichen Sie mit der Rechnung ab, denn die Telemetrie schätzt nur.

Kennzahl	Quelle	Aggregation	Aussage
Adoption	`claude_code.session.count`	Sitzungen pro Team und Woche, ohne `start_type="agents_view"`	Wird der Rollout genutzt?
Token-Mix	`claude_code.token.usage`	Summe nach `type` und `model`	Cache-Anteil, Opus- gegen Sonnet-Anteil
Kosten pro Team	`claude_code.cost.usage`	Summe nach `cost_center` pro Monat	Budgetverbrauch vor der Rechnung
Edit-Annahme	`claude_code.code_edit_tool.decision`	accept / (accept + reject) nach `language`	Wo Vorschläge scheitern
Output	`claude_code.lines_of_code.count`, `claude_code.commit.count`	Summe pro Team und Sprint	Trend, keine Leistungsnote

Als Basis für Alarme taugt Anthropics Kostenleitfaden: Über Enterprise-Deployments hinweg liegen die Kosten bei rund 13 USD pro Entwickler und aktivem Tag und 150 bis 250 USD pro Entwickler und Monat, 90 % der Nutzer bleiben unter 30 USD pro aktivem Tag. Wir würden alarmieren, wenn die Tageskosten eines Teams die Zahl aktiver Köpfe mal 30 USD übersteigen. Das fängt eine Endlosschleife ab, ohne jemanden zu benennen.

Die Monitoring-Seite sagt klar, dass Kostenmetriken Näherungen sind und die verbindliche Abrechnung vom Anbieter kommt: Claude Console, Amazon Bedrock oder Google Cloud. Telemetrie dient der Zuordnung und Frühwarnung, die Cloud-Rechnung der Buchhaltung. Wie die Rechnungsseite bei Seats gegenüber API-Tokens aussieht, steht in unserem Artikel zu Claude Code Kosten für Teams.

Zwei Versionssprünge verzerren Trendlinien. Vor v2.1.214 blähten Gateways, die Usage über mehrere Frames streamen, cost.usage und token.usage um etwa einen Request pro zusätzlichem Frame auf. Vor v2.1.222 hing mcp_server.name an jedem Request nach einem MCP-Aufruf, MCP-Anteile fallen nach dem Update also sichtbar ab. Markieren Sie beide Versionen in den Charts.

Was ändert sich auf Bedrock und Vertex?

Auf Amazon Bedrock und Google Cloud ist OpenTelemetry die einzige Nutzungsansicht pro Team. Anthropics Analytics-Dashboards und die Claude Code Analytics API erfassen diese Nutzung nicht. In der Sitzung existiert kein Claude-Konto, user.email taucht nie auf. Server-managed Settings erreichen diese Sitzungen ebenfalls nicht, die Telemetrie-Konfiguration muss per Managed-Settings-Datei oder MDM kommen.

Laut Datennutzungsseite sind Anthropics eigene Betriebsmetriken, Fehlerberichte und /feedback-Uploads standardmäßig aus, sobald CLAUDE_CODE_USE_BEDROCK oder CLAUDE_CODE_USE_VERTEX gesetzt ist. Qualitätsumfragen und der WebFetch-Domain-Check laufen weiter. Auf einem Cloud-Anbieter verlassen also nur die Nutzungsdaten den Laptop, die Sie selbst per OpenTelemetry konfigurieren. Google Clouds Angebot heißt in der aktuellen Claude-Code-Doku “Agent Platform”.

	Claude Team / Enterprise	Bedrock oder Vertex
Eingebautes Dashboard	claude.ai/analytics/claude-code (Admins, Owner)	Keines von Anthropic
Identität in der Telemetrie	`user.email`, Konto-IDs	Nur `user.id` und `session.id`
Verteilung der Konfiguration	Server-managed oder Datei	Nur Datei oder MDM
Verbindliche Kosten	Claude-Rechnung oder Spend-Report	AWS- oder Google-Cloud-Rechnung

Weil die Identität fehlt, schlägt die Doku vor, sie per OTEL_RESOURCE_ATTRIBUTES pro Nutzer selbst anzuhängen. Für ein Team-Dashboard würden wir das nicht tun: team.id und cost_center pro Geräte-Image setzen, die Person weglassen.

AWS veröffentlicht eine Monitoring-Guidance für Claude Code auf Bedrock mit zwei Modi. Der zentrale Modus betreibt einen ADOT-Collector auf ECS Fargate mit 0,25 vCPU und 0,5 GB hinter einem Load Balancer, für rund 30 bis 50 USD im Monat, mit Export nach CloudWatch. Der Sidecar-Modus sendet direkt vom Rechner an den CloudWatch-OTLP-Endpunkt, ohne Infrastrukturkosten. Achtung: Die mitgelieferten Dashboards zeigen Top-Nutzer und Kosten pro Nutzer über user.email, und PromQL-Abfragen in CloudWatch sind auf 7 Tage begrenzt. Deployen Sie in einer EU-Region und schalten Sie die Personen-Panels ab, wenn Ihre Betriebsvereinbarung nur Teamebene erlaubt. Die Einrichtung von Claude Code selbst beschreibt unser Leitfaden Claude Code auf Bedrock EU einrichten.

Ist Claude Code Telemetry Leistungskontrolle nach DSGVO und BetrVG?

Ja, sobald sich Daten einer Person zuordnen lassen. user.email, Konto-IDs und selbst die zufällige user.id sind in der Hand des Arbeitgebers personenbezogen, und Sitzungen oder angenommene Edits pro Kopf beschreiben Arbeitsverhalten. Damit brauchen Sie eine Rechtsgrundlage, einen engen Zweck (Kosten, Kapazität), kurze Speicherfristen und in Betrieben mit Betriebsrat dessen Zustimmung.

Der Betriebsrat hat nach § 87 Abs. 1 Nr. 6 BetrVG mitzubestimmen bei Einführung und Anwendung technischer Einrichtungen, die dazu bestimmt sind, das Verhalten oder die Leistung der Arbeitnehmer zu überwachen. Ein OTel-Collector mit Nutzer-E-Mails fällt aus unserer Sicht klar darunter, ein auf Teams aggregierter Export nach unserer Einschätzung deutlich schwerer. Das ist keine Rechtsberatung: Klären Sie die Einordnung vor dem Rollout mit Betriebsrat und Datenschutzbeauftragtem. Eine Betriebsvereinbarung kann nach § 26 Abs. 4 BDSG selbst Rechtsgrundlage für die Verarbeitung sein, muss dann aber Art. 88 Abs. 2 DSGVO beachten. Hinein gehören die Strip-Liste des Collectors, die erlaubten Aggregationsebenen, die Speicherdauer und wer das Dashboard sieht.

Die Defaults helfen. Prompt-Text wird nicht erfasst, nur prompt_length. Antworten werden durch <REDACTED> ersetzt. Tool-Argumente, Bash-Befehle und Dateipfade bleiben draußen, solange niemand OTEL_LOG_TOOL_DETAILS=1 setzt. Dateiinhalte stehen nie in Metriken oder Events. Die Daten gehen nur an Ihren Endpunkt, nicht an Anthropic. Jede der Variablen OTEL_LOG_USER_PROMPTS, OTEL_LOG_ASSISTANT_RESPONSES, OTEL_LOG_TOOL_DETAILS und OTEL_LOG_RAW_API_BODIES erweitert die Erfassung stark. Rohe API-Bodies enthalten den kompletten Gesprächsverlauf. In der Kostenpipeline würden wir keine davon zulassen.

Heikler ist das Analytics-Dashboard für Team und Enterprise. Es hat eine Bestenliste der Top 10, einen CSV-Export aller Nutzer und ordnet mit der GitHub-App gemergte PR-Zeilen Claude-Code-Sitzungen zu, im Fenster von 21 Tagen vor bis 2 Tagen nach dem Merge. Das sind individuelle Leistungsdaten, absichtlich so gebaut. Legen Sie vor dem Einschalten fest, wer es öffnen darf.

Selbst betreiben oder auslagern?

Telemetrie selbst zu betreiben heißt, einen weiteren Produktionsdienst zu führen: einen Collector, den jeder Laptop erreicht, TLS-Zertifikate, Bearer-Token oder mTLS, einen Metrikspeicher und Dashboards, die brechen, wenn Claude Code Attribute ändert. Auslagern lohnt sich ohne eigenes Observability-Team. Wer Prometheus oder Grafana schon betreibt, behält es intern.

Wiederkehrende Arbeit bei diesem Thema, Aufwände sind unsere Schätzung:

Collector-Betrieb: Updates, Zertifikate, Token-Rotation, Kapazität. Im eingeschwungenen Zustand unter einem Tag pro Monat.
Dashboard-Pflege: Claude Code dokumentiert Attributänderungen pro Version. Jemand muss diese Notizen lesen und Panels anpassen. Etwa ein halber Tag pro Monat.
Datenschutz-Governance: Speicherfristen, Strip-Liste, Zugriffsreviews, Betriebsvereinbarung. Vor allem beim Start, danach quartalsweise.

Wenn Sie auslagern, fordern Sie konkret: ein Backend in der EU mit benannter Region; einen AVV nach Art. 28 DSGVO, der Telemetriedaten samt E-Mail-Adressen ausdrücklich umfasst; die vollständige Liste der Unterauftragsverarbeiter; ein Zugriffsmodell, in dem Mitarbeiter des Dienstleisters keine Einzelreihen abfragen können; Speicherfristen unter Ihrer Kontrolle; ein SLA auf die Datenannahme, nicht nur auf die Oberfläche; und eine Exit-Klausel mit Übergabe der Collector-Konfiguration und Rohdaten im OTLP- oder Prometheus-Format. Besteht der Dienstleister auf ungefilterten Daten, betreiben Sie den Strip-Collector selbst und liefern ihm nur den aggregierten Strom.

FAQ

Ist Claude Code Telemetry standardmäßig aktiv?

Nein. Der Export an Ihr eigenes Backend ist Opt-in und braucht CLAUDE_CODE_ENABLE_TELEMETRY=1 plus Exporter. Davon getrennt ist Anthropics Betriebstelemetrie: mit der Claude API standardmäßig an, auf Bedrock, Vertex und Foundry standardmäßig aus. DISABLE_TELEMETRY=1 schaltet sie ab.

Was kostet der Betrieb von Claude Code Telemetry?

Die Daten selbst kosten nichts, Sie zahlen Collector und Speicher. Die AWS-Guidance schätzt rund 30 bis 50 USD im Monat für einen zentralen Collector auf ECS Fargate, im Sidecar-Modus 0 USD Infrastruktur, jeweils zuzüglich CloudWatch. Ein Prometheus auf vorhandenem Cluster fällt kaum ins Gewicht.

Speichert Claude Code Telemetry Prompts oder Quellcode?

Standardmäßig nicht. Events enthalten die Prompt-Länge, Antworttexte sind geschwärzt, Dateiinhalte fehlen in Metriken und Events immer. Prompts, Antworten, Tool-Argumente und rohe API-Bodies erscheinen nur, wenn ein Admin die passende OTEL_LOG_*-Variable setzt.

OpenTelemetry oder Claude Analytics-Dashboard: was nehmen?

Das Dashboard, wenn Sie auf Team oder Enterprise sind und Adoption plus PR-Zuordnung ohne Setup wollen. OpenTelemetry, wenn Claude Code über Bedrock oder Vertex läuft, Sie Kosten pro Team brauchen oder die Daten im eigenen EU-Backend halten wollen. Auf Cloud-Anbietern zeigt das Dashboard nichts.

Braucht Claude Code Telemetry eine Betriebsvereinbarung?

Sobald personenbeziehbare Nutzungsdaten anfallen, ist § 87 Abs. 1 Nr. 6 BetrVG einschlägig, wenn ein Betriebsrat existiert. Wir empfehlen eine Betriebsvereinbarung, die Teamaggregation, Strip-Liste und Speicherdauer festschreibt, auch wenn Sie die Daten anonymisieren wollen.

Kann ein Entwickler die Telemetrie abschalten?

Teilweise. Ein Repository kann Telemetrie weder einschalten noch umleiten, aber Repo oder Entwickler können einen Exporter auf none setzen. Setzen Sie OTEL_METRICS_EXPORTER und OTEL_LOGS_EXPORTER in den Managed Settings, ist auch das gesperrt. Zentrale Endpunkte und Credentials lassen sich nicht umbiegen.

Quellen

Claude Code Docs: Monitoring (OpenTelemetry) (1. Oktober 2026)
Claude Code Docs: Analytics-Dashboard (1. Oktober 2026)
Claude Code Docs: Datennutzung (1. Oktober 2026)
Claude Code Docs: Kosten steuern (1. Oktober 2026)
Claude Code Docs: Managed Settings verteilen (1. Oktober 2026)
Claude Code Docs: Modellkonfiguration (Surface Coverage) (1. Oktober 2026)
OpenTelemetry Collector: Konfiguration (1. Oktober 2026)
OpenTelemetry Collector Contrib: Attributes Processor (1. Oktober 2026)
AWS Solutions Library: Claude Code Monitoring auf Amazon Bedrock (1. Oktober 2026)
BetrVG § 87 Mitbestimmungsrechte (1. Oktober 2026)
BDSG § 26 Beschäftigtendatenschutz (1. Oktober 2026)