Anthropic ergänzt den Export von OpenTelemetry-Traces für die Claude Platform

Anthropic hat den Export von OpenTelemetry-Traces für die Claude Platform ergänzt. Am 14. Oktober 2026 gab das Unternehmen bekannt, dass Entwickler nun Traces aus Claude Managed Agents, der Messages API und Claude SDKs an jedes Observability-Tool senden können, das den Standard unterstützt. Die Funktion ist als öffentliche Betaversion verfügbar.

In der Ankündigung von Anthropic teilte das Unternehmen mit, dass durch das Hinzufügen eines Ziels in der Claude Console jeder Agenten-Durchlauf, jeder Modellaufruf und jede Tool-Nutzung als standardkonformer OpenTelemetry-Trace mit Latenz, Token-Anzahl und IDs an das Observability-Tool des Nutzers gesendet wird. Managed Agents und die Messages API erfordern ein solches Ziel in der Console, während Claude SDKs Traces automatisch exportieren. Entwickler, die bereits Traces aus Claude Code oder Cowork an ein Observability-Tool senden, können dort auch Agenten anzeigen lassen, die auf der Claude Platform erstellt wurden.

Anthropic erklärte, dass Claude-Traces den semantischen Konventionen für OpenTelemetry GenAI entsprechen. Dadurch lassen sich Daten von Claude und anderen Anbietern in denselben Tools und Dashboards nutzen. Die Traces funktionieren außerdem mit jedem OpenTelemetry-Tool, das einen standardkonformen OTLP-Endpunkt unterstützt.

Zwei Einrichtungswege und ein gemeinsames Trace-Modell

Die Dokumentation zur Claude Platform definiert einen Trace als vollständige Aufzeichnung einer Anfrage, die ein System durchläuft, und einen Span als einzelnen Schritt innerhalb eines Traces, etwa eine Modellanfrage oder eine Tool-Nutzung. Sie beschreibt zwei Einrichtungswege. Für das SDK-Tracing wird der SDK im Code installiert und ein Tracer-Provider registriert; besondere Berechtigungen sind dafür nicht erforderlich. Das API-Tracing wird eingerichtet, indem in der Claude Console ein Ziel hinzugefügt wird; dafür ist eine Administratorberechtigung erforderlich.

Der Umfang unterscheidet sich je nach Einrichtungsweg. Das API-Tracing erfasst jeden Modelllauf innerhalb einer Anfrage, Durchläufe von Managed Agents und serverseitige Tools, die von der API ausgeführt werden. Das SDK-Tracing erfasst zusätzlich Client-Tools, die vom Tool-Runner ausgeführt werden, Tools in einer selbst gehosteten Sandbox sowie weitere API-Anfragen wie Datei-Uploads. Werden beide Wege eingerichtet, erscheinen die SDK- und API-Spans einer Anfrage in einem einzigen Trace. Bei Anfragen an die Claude Platform auf AWS erscheinen die API-Spans stattdessen in eigenen Traces.

Bei Managed Agents erzeugt eine Sitzung für jede Anfrage an die Sessions API einen Span und für jeden Agenten-Durchlauf einen Turn-Span. Jeder Turn enthält Spans für jede Modellanfrage, jedes von der API ausgeführte Tool und jede Ergebnisauswertung. Die Dokumentation verweist Nutzer von Claude Code, Agent SDK und Cowork für diese Produkte auf separate Dokumentationen zu Monitoring und Observability.

Inhaltsmodi, Beschränkungen und Verhalten bei Compliance-Vorgaben

Für jedes Ziel und jeden SDK-Client gibt es einen Inhaltsmodus, der festlegt, ob Spans Modellprompts und -antworten enthalten. „Nur Metadaten“, die Standardeinstellung, erfasst Kennungen, Zeitangaben, Status, Token-Anzahlen und vom Nutzer ausgewählte Texte, etwa Namen und Beschreibungen von Agenten und Tools sowie die Namen von MCP-Servern. „Vollständiger Inhalt“ umfasst zusätzlich Modellprompts und -antworten.

Im Modus „Vollständiger Inhalt“ enthält jeder Span standardmäßig bis zu 0,75 MB an Inhalten. Laut Dokumentation reicht das für ein Kontextfenster mit 200.000 Tokens englischsprachigen Textes und bleibt unter dem Anfrage-Limit von 1 MB vieler Observability-Plattformen und Proxys. Für ein vollständiges Kontextfenster mit 1 Mio. Tokens werden etwa 4 MB benötigt. Überschreiten Inhalte das Limit, kürzt das SDK oder die API sie und setzt das Attribut anthropic.content.truncated auf „true“. Bei Anfrage-Spans werden zuerst der Systemprompt und die ältesten Nachrichten entfernt; Bilder und Dokumente erscheinen nur mit ihrer jeweiligen Typangabe.

Bei Organisationen, für die im Umgang mit Anthropic-Daten Einschränkungen gemäß HIPAA, FERPA oder K-12 gelten, exportiert Anthropic unabhängig vom eingestellten Inhaltsmodus aus den Zielen nur Metadaten. SDK-Spans sind davon nicht betroffen. Bei aktivierter Null-Datenspeicherung kann der Modus „Vollständiger Inhalt“ weiterhin verwendet werden, da die API exportierte Inhalte nur so lange im Arbeitsspeicher hält, bis sie an das Ziel übermittelt werden. Claude Managed Agents ist nicht für die Null-Datenspeicherung geeignet; seine Aufbewahrungsbedingungen ändern sich durch die Verwendung von OpenTelemetry nicht.

Für die Token-Abrechnung weist die Dokumentation Nutzer an, jedes Token nur einmal zu zählen, indem sie pro Anfrage die Spans aus nur einer Quelle aufsummieren. Wenn eine Anfrage sowohl SDK- als auch API-Spans enthält, sollen die API-Spans verwendet werden. Außerdem weist sie darauf hin, dass Spans bei einem erneuten Zustellversuch mehr als einmal eintreffen können.

Genannte Integrationen und erste Kundenberichte

Die Ankündigung ordnet die unterstützten Observability-Plattformen nach Anwendungsfall. Für das Debugging von Agenten im Zusammenspiel mit dem übrigen Software-Stack nennt sie Grafana Cloud, Honeycomb, Sentry und Splunk. Dort stehen Agenten-Traces neben Logs und Metriken, sodass Entwickler erkennen können, von welchem Dienst ein langsamer oder fehlgeschlagener Schritt ausgeht. Für die Verbesserung von Agenten anhand von Produktionsdaten nennt sie Arize AI, Braintrust, Datadog, Langfuse, LangSmith by LangChain, New Relic und PostHog. Zu den beschriebenen Einsatzmöglichkeiten zählen, reale Traces in Evaluierungen umzuwandeln und Qualitätsprobleme aufzuspüren. Für die organisationsweite Erfassung der Nutzung nennt sie Databricks Unity Gateway, über das Plattform- und Sicherheitsteams die Token-Nutzung nach Team einsehen und ungewöhnliche Aktivitäten melden können.

Mehrere frühe Kunden beschrieben in der Ankündigung ihre Implementierungen. Roman Shtylman, Mitgründer und CTO von Foxglove, erklärte, dass das Unternehmen Agenten entwickelt, die Robotik-Teams beim Debuggen ihrer Roboter unterstützen. Der native OpenTelemetry-Export aus der Claude Platform ermögliche es Foxglove, die Interaktionen mit den Agenten in PostHog zusammen mit den Produktnutzungsdaten zu analysieren, um die Leistung der Agenten in der Praxis zu bewerten und Verbesserungen für Robotik-Teams zu priorisieren.

Der leitende Softwareentwickler von Ramp, David Traina, sagte, das Unternehmen habe Reflect entwickelt, ein agentisches System, das Langfuse-Traces bewertet, wiederkehrende Fehler aufspürt und Lösungen vorschlägt. „Bei einigen Agenten haben wir den Tokenverbrauch bereits um 10–20 % gesenkt und Sitzungen um 30 % beschleunigt“, sagte Traina. Der native OpenTelemetry-Export aus der Claude API könne die Instrumentierung ohne zusätzliche Schritte direkt in diese Verbesserungsschleife einspeisen, fügte er hinzu.

Der CTO von Sterling Labs, Hyon Lee, sagte, der native Export leite jeden Trace in Langfuse weiter – ohne dass für die Agenten des Unternehmens, die Live-Märkte analysieren, eine eigene Instrumentierung erforderlich sei. Ankush Sharma, Leiter der Infrastruktur bei FloQast, sagte, die Agenten des Buchhaltungssoftwareunternehmens liefen auf der Claude Platform und ihre Telemetriedaten würden in Grafana Cloud erfasst. Dadurch erscheine jeder Modellaufruf im selben Trace wie der Abstimmungs- oder Buchungssatz-Workflow, in dessen Rahmen er ausgeführt wurde. So könne das Unternehmen anhand einer einzigen Zeitachse Fragen von Wirtschaftsprüfern dazu beantworten, was ein Agent getan habe.