Claude API OpenTelemetry tracing: what the beta exports and how to turn it on

Anthropic launched OpenTelemetry export for the Claude API in beta on 14 October 2026, so Messages API requests, tool uses and Claude Managed Agents sessions can be traced into an observability platform you already run. There are two halves, and they need different things from you: SDK tracing is a code change with no special permission, while API tracing is a destination added in the Claude Console by an admin and covers any client. The default content mode carries no prompts or responses, so turning it on costs you nothing in exposure until you deliberately switch it.

#What did Anthropic actually launch?

The release notes entry dated 14 October 2026 says Anthropic "launched OpenTelemetry export in beta, so you can trace Messages API requests and Claude Managed Agents sessions in your observability backend", that "the Claude SDK emits spans in Python, TypeScript, C#, Go, Java, PHP, and Ruby", and that "to get spans from the API, add an OpenTelemetry destination in the Claude Console". The documentation widens the list to "Messages API requests, tool uses, and Managed Agents sessions", and states the terms plainly: "OpenTelemetry export is in beta. It's provided under your agreement with Anthropic, including the Beta Services section of the Service Specific Terms."

The stated uses are debugging failed or slow requests, tracking token spend and latency, and building evals from real traffic. Spans carry "attributes from the GenAI semantic conventions", which is what lets a platform recognise them without per-vendor mapping.

	SDK tracing	API tracing
Set up through	Code	Console
Required permission	None	Admin
Coverage	Clients using the SDK	Any client
Messages API requests	yes	yes
Each model run within a request	no	yes
Token usage	yes	yes
Server tools, run by the API	no	yes
Client tools, run by the tool runner	yes	no
Other API requests, such as uploading files	yes	no

That table is the practical reason to run both: server tools and MCP connector tools the API executes show up only on the API side, while the client tools your own tool runner executes show up only on the SDK side. If you have been trying to work out where an MCP connector call spent its time, that is the row to read twice.

#What do the spans contain, and what do they leave out?

Content is a setting, not a default. Anthropic documents two content modes per destination and per SDK client. Metadata only, metadata_only in the SDK, is the default and includes "identifiers, timing, status, token counts, and text that you choose, such as the names and descriptions of your agents and tools and the names of your MCP servers". Full content, content in the SDK, is the one that adds the payload: "Spans include model prompts and responses, and everything in Metadata only."

Full content is also capped. Each span holds up to 0.75 MB of content by default, which Anthropic says "fits a 200k-token context window of English text and stays below the 1 MB request limit of many observability platforms and proxies". Over the limit, the SDK or the API shortens the content and sets anthropic.content.truncated to true; request spans "drop the system prompt and the earliest messages first", and tool spans "drop blocks from the end of the result". Images and documents appear only as their type. A full 1M-token context window needs about 4 MB, so the cap bites well before the context window does. traces.max_content_bytes changes it in the SDK, and Advanced settings changes it in the Console.

Two constraints are worth knowing before anyone proposes Full content in a regulated environment. If your organisation has a HIPAA, FERPA or K-12 data-handling restriction with Anthropic, "destinations export only metadata regardless of their content mode", and Anthropic notes that SDK spans are not affected by that override, which means the SDK half is where content could still leave. Under zero data retention you can still use Full content, and for Messages API requests "the API holds the exported content only in memory until it delivers it to the destination", but Claude Managed Agents "isn't eligible for zero data retention". Whatever arrives at your platform then lives under that platform's own access and retention settings, which Anthropic tells you to check yourself.

#How do the traces join up with your own?

By default the API spans for a request or a session sit in their own traces. The API reads each request's trace context from the W3C traceparent header, so calling the SDK from inside one of your own spans nests everything into one trace. One detail will bite anyone who samples aggressively: "if the sampled flag in the header is off, the API doesn't emit the request's span or the spans under it." Claude Platform on AWS "doesn't support this header yet", and its spans always start their own traces even when the sampled flag is off.

To confirm delivery, Anthropic says to send a request and then check that the Delivery column on the Console's OpenTelemetry settings page reads Healthy, which "can take about a minute", and to filter on service.name = claude-platform in your platform. A Failing column exposes the last error on hover.

#What changed in Claude Code on the same day?

Claude Code's own telemetry moved in the same direction on 14 October 2026. Version 2.1.300 "added cache_creation_5m_tokens and cache_creation_1h_tokens to the OpenTelemetry api_request event, splitting cache writes by lifetime", and "added OpenTelemetry GenAI semantic-convention attributes to trace spans, such as gen_ai.provider.name, gen_ai.conversation.id, gen_ai.tool.name and error.type".

These are two separate systems that now speak a more similar dialect, not one feature. The Claude API documentation is explicit that Claude Code, the Agent SDK and Cowork have their own monitoring pages and are not covered by the API export. The practical gain is that cache writes at the five-minute and one-hour lifetimes are now separable in Claude Code's telemetry, which matters because those two carry different prices. Our cost optimization guide covers why that split is the number to watch.

The same release notes entry also records that Claude Managed Agents scheduled deployments "are now available on Claude Platform on AWS".

#What should you do about it today?

• If you already run an OTLP platform: start with SDK tracing, since it needs no admin and no Console change, and read a few real traces before deciding whether API tracing adds anything you cannot already see.
• If you want server tool and connector timings: you need API tracing, and therefore an admin. Nothing on the SDK side will show you a tool the API ran.
• Before anyone enables Full content: treat it as a data export decision, not an observability one. Check your platform's access and retention settings, and note that the HIPAA, FERPA and K-12 override applies to destinations and not to SDK spans.
• If you sample traces: check what your sampler does to the traceparent header, because an unsampled flag means the API emits nothing at all for that request rather than emitting a span you can find later.
• If you track spend in Claude Code: the five-minute and one-hour cache write counters are new in 2.1.300, so a dashboard built before 14 October 2026 is still summing them as one number.

This is a beta on both sides, and the Claude platform documentation says so in its own first line. Everything above was checked against Anthropic's pages on 15 October 2026.