OpenTelemetry tracing for Claude: see every model call and tool use in your own observability tools
In brief
On October 14, 2026 Anthropic added OpenTelemetry export (public beta) for the Messages API, Claude Managed Agents, and the Claude SDKs. What gets traced, where the traces can go, and what to look at first.
Contents
On October 14, 2026, Anthropic added OpenTelemetry export in public beta. Requests to the Messages API and sessions of Claude Managed Agents can now send traces to the observability tool your team already uses. OpenTelemetry is an open standard for sending timing and event data (called traces) from software to a monitoring tool. A trace is made of spans: one span per step, such as a model call.
What gets traced
Per Anthropic's announcement, traces cover agent turns, model calls, tool use, and MCP server calls. Each trace carries latency, token counts, and IDs. Spans follow the OpenTelemetry GenAI semantic conventions, so Claude data lines up with data from other model providers in the same dashboards.
How to turn it on
- Messages API and Managed Agents: add an OpenTelemetry destination in the Claude Console.
- Claude SDKs: the SDK emits spans in Python, TypeScript, C#, Go, Java, PHP, and Ruby, and traces export automatically.
Anything that accepts a standard OTLP endpoint works. Anthropic names Grafana Cloud, Honeycomb, Sentry, Splunk, Arize AI, Braintrust, Datadog, Langfuse, LangSmith, New Relic, PostHog, and Databricks Unity Gateway. The setup reference is in the Claude Platform docs under Manage Claude, OpenTelemetry.
What to look at first
- Slow sessions. Sort agent sessions by total latency, open the slowest, and see whether the time went to model calls or to a tool or MCP server. A slow tool is a fix on your side, and a slow model call points at prompt size or effort settings.
- Token counts per step. A single turn with a large input usually means a tool returned more than the model needed. Minimising token usage covers the fixes.
- Retries and errors on MCP calls. A tool that fails twice before succeeding adds both time and cost to every session.
Where it fits with what you already have
Traces tell you what happened in one request. They do not tell you whether the answer was good. Pair them with evals for quality and with budgets and guardrails for spend. If you already export Claude Code or Cowork telemetry, this adds the API and agent side of the same picture. For app-level monitoring, see monitoring your Claude app.
Before you send traces anywhere
Traces include IDs and may include content depending on your configuration. Confirm with your security team what your observability vendor is allowed to receive, the same way you would for application logs.