What is OpenTelemetry and how does Claude Code use it?
OpenTelemetry (OTel) is an open standard for observability, defining how metrics, events (logs) and traces are exported. The official monitoring docs say that with CLAUDE_CODE_ENABLE_TELEMETRY=1, Claude Code can emit claude_code.* events such as user_prompt, tool_decision, Compaction, hook_registered, hook_execution_complete, at_mention and api_retries_exhausted.
Why does it exist?
On your own machine you see what Claude Code does on screen, but a team or CI that needs to answer "who loaded which hooks", "did Compaction fail" or "which tools were rejected" needs structured records. OTel lets that data flow into the observability stack you already have instead of a vendor-specific format.
How do I turn it on?
The docs' minimal setup: CLAUDE_CODE_ENABLE_TELEMETRY=1 (required) and OTEL_LOGS_EXPORTER set to otlp, console or none; to send to a collector also set OTEL_EXPORTER_OTLP_PROTOCOL (no default, you must set it) and OTEL_EXPORTER_OTLP_ENDPOINT, with OTEL_LOGS_EXPORT_INTERVAL defaulting to 5000 ms. Seeing claude_code.user_prompt after you submit a prompt confirms it works. Tool parameters and similar detail are not recorded by default; set OTEL_LOG_TOOL_DETAILS=1.
So what does this mean for me?
If you manage a team's Claude Code use, turn on console output once to see what the events look like before choosing a backend. Note that events are not complete audit evidence and some fields need extra switches; I have not stood up a collector to test.
A publicly checkable example: the claude_code.compaction event carries trigger, pre_tokens, post_tokens and precompute_reuse (hit or miss_*), which can be used to count how often compaction happens and whether it reused a summary prepared in the background.
Pros: a standard format, flows into an existing observability stack, fine-grained events. Cons: you must run the collector and dashboards yourself, and events are a session-level record, not a full audit.