Claude OpenTelemetry Tracing: Separate Network from Model Latency

Blog / Developer tools

Claude OpenTelemetry Tracing: Separate Network from Model Latency

cdnping editors5 min read

Claude OpenTelemetry export is available now. On October 14, 2026, Anthropic announced that Claude Managed Agents, the Messages API, and the Claude SDK can export traces to any observability tool that accepts an OTLP endpoint. It is a public beta. Every agent turn, model call, and tool call becomes a standard trace with latency, token counts, and IDs. When you are asking "why is my agent slow," you can now look at the time spent in each span inside your own observability platform.

This article is current as of October 2026. Sources are the official announcement and the Claude Code changelog. For exact configuration options and field names, defer to the official docs.

What exactly did Anthropic release?

What the announcement states:

  • Sources: Claude Managed Agents, the Messages API, and the Claude SDK.
  • Content: agent turns, model calls, tool use, and MCP server calls, with latency, tokens, and IDs.
  • Format: standard OpenTelemetry traces that follow the OpenTelemetry GenAI semantic conventions.
  • Destinations: any tool that accepts a standard OTLP endpoint. The announcement names Grafana Cloud, Honeycomb, Sentry, and Splunk, plus Datadog, Langfuse, LangSmith, New Relic, Arize AI, Braintrust, PostHog, and others. Databricks Unity Gateway is listed as a way to track token usage by team.
  • Traces from Claude Code and Cowork can also be sent to the same observability tool.

What the announcement does not say: exact span and attribute names, export limits, pricing, and retention. Don't guess at these. Check the official OpenTelemetry docs (the manage-claude section on platform.claude.com).

How do you connect it?

The announcement describes two entry points:

ScenarioWhat to do
Managed Agents, Messages APIAdd a trace destination in the Claude Console
Claude SDKExports automatically

I'm not listing the exact Console menus and fields here; the official docs are the reference. The general approach is to first get an OTLP endpoint and an auth header from your tool (Grafana, Langfuse, Datadog, and so on), then enter them as the destination as the docs describe. Endpoints and keys are sensitive, so don't paste them into tickets or screenshots.

What changed in Claude Code?

Claude Code has had OTel events for a while. The last two releases added a few things:

  • 2.1.300: the api_request event gains cache_creation_5m_tokens and cache_creation_1h_tokens, which split cache writes by their two lifetimes (5 minutes and 1 hour). Trace spans gain OpenTelemetry GenAI semantic convention attributes such as gen_ai.provider.name, gen_ai.conversation.id, gen_ai.tool.name, and error.type.
  • 2.1.301: the tool_decision event gains classifier_verdict and permission_mode, so you can tell whether an allow or block came from the auto mode classifier or from a permission rule. With OTEL_LOG_TOOL_DETAILS=1 set, classifier_category is included as well.

The cache split helps when reconciling your bill; read it together with How to use Claude prompt caching to actually save money. The auto mode fields map to the "why was my command blocked" troubleshooting in Claude Code now defaults to auto mode.

How do you use traces to separate network latency from model generation time?

This is the most practical part of the feature. Below is a workflow you can follow as-is; set any numeric thresholds from your own baseline.

  1. Build a baseline first. In your observability tool, pull a set of model-call spans from a normal period and note the median latency and the high-percentile spread, grouped by model and request size.
  2. Look at what makes up the slow requests. Compare each slow span's output token count with its duration. Many output tokens and a long duration usually means the time is generation itself. Very few output tokens but a slow call is when it is worth suspecting the network or queueing on the server side.
  3. Look at the tool-call spans. When an agent turn gets slow, a single tool or MCP call often accounts for most of the time, not the model. Rule that out first.
  4. Cross-check against client-side network data. Traces record the time on the Anthropic side and the SDK side. The path from your machine to the API has to be measured separately. Open the live speed test on the cdnping home page and look at the browser-to-Claude-API "first connection" (including DNS and the TLS handshake) and "round trip" (the median of 3 requests after the connection is reused). If the round trip looks normal but calls in the trace are slow, the problem is more likely not your network.
  5. Cross-check against server-side status. Open /en/status/anthropic and look at the probes that Cloudflare edge nodes run against the official entry point every 5 minutes. If probes are abnormal in the same time window, the problem is on the service side. If probes are normal and it is only slow for you, go back and check your local path and the request itself.

A caveat on method: cdnping's probes and speed test only reflect entry-point reachability and handshake time. They are not a measure of model generation speed. See /en/methodology for how we measure.

How does this fit with existing troubleshooting articles?

Is it worth turning on now?

Public beta means behavior may change. A safer approach is to connect it first on a non-production project, confirm that the destination receives data and the fields look as expected, and then decide whether to roll it out to production. Also, traces can contain prompts, tool arguments, and similar content. Before enabling, check the access controls and retention policy of your observability platform. Claude Code has dedicated switches (such as OTEL_LOG_TOOL_DETAILS) that control tool details; whether to turn them on should follow your team's data policy.

Sources

Related articles

Keep reading