Monitoring usage with OpenTelemetry

Claude Code can export its own telemetry to your observability stack over OpenTelemetry (OTel). You get three signals: metrics as time series (sessions, tokens, cost, lines changed), events through the logs protocol (each prompt, API call, tool run and permission decision), and, in beta, traces that tie a prompt to every API call and tool it triggered. Everything goes to the collector you configure, not to Anthropic.

I set this up for every client team larger than about ten people. It answers "who is using it, what does it cost, and what did it run?" in tools they already have, and it works on every provider, including Bedrock and Vertex where the Anthropic dashboards cannot see.

Five-minute start

Run a local collector (or use your vendor's OTLP endpoint), then:

# Turn telemetry on
export CLAUDE_CODE_ENABLE_TELEMETRY=1

# Pick signals: otlp, prometheus (metrics only), console or none
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp

# Where to send it. There is no default protocol, so always set one
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_ENDPOINT=https://otel.acme-health.internal:4318
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer otel_ingest_9f31"

# While testing, flush faster than the 60 s metrics default
export OTEL_METRIC_EXPORT_INTERVAL=10000

claude

How to tell it worked:

• Metrics: look for claude_code.session.count, which is emitted when a session starts.
• Logs only: send a prompt and look for a claude_code.user_prompt event.
• Nothing arriving: start claude --debug-file /tmp/otel-debug.txt. Failures from your exporters are logged as [3P telemetry] errors. Lines tagged [Anthropic telemetry] are Anthropic's separate operational telemetry (see Data usage) and are not your problem.

Remember to put the export interval back to the default before rolling out.

Rolling it out to everyone

Put the variables in the env block of a managed settings file so every machine reports to the same place:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://otel-gw.platform.svc:4317",
    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer otel_ingest_9f31",
    "OTEL_RESOURCE_ATTRIBUTES": "department=engineering,cost_centre=ENG-204"
  }
}

Points that trip people up:

• Desktop. Code tab sessions in Claude Desktop read managed settings from the sources that reach Desktop sessions (see Desktop). The OpenTelemetry form under Monitoring in the claude.ai admin console's Data and privacy settings configures Cowork only; neither the CLI nor the Code tab uses it.
• Repositories cannot turn telemetry on. Exporter variables in .claude/settings.json and .claude/settings.local.json are ignored, so a cloned repo cannot enable telemetry, redirect it or capture content. A repo can still switch a signal off by setting its selector (such as OTEL_LOGS_EXPORTER) to none, unless managed settings, a --settings file or the launch environment sets that variable.
• Child processes do not inherit OTEL_*. Bash commands, hooks, MCP servers and language servers started by Claude Code do not see the exporter configuration. If an instrumented app you run through Bash should export its own telemetry, set its variables in the command.

How managed settings pin the destination

When an OTEL_EXPORTER_OTLP_* variable is set in managed settings, Claude Code strips conflicting developer-set variables at startup (with a debug log warning) so telemetry cannot be diverted:

Exporter selectors (OTEL_METRICS_EXPORTER, OTEL_LOGS_EXPORTER, OTEL_TRACES_EXPORTER) are not stripped. They follow normal precedence, so a developer can still turn a signal off or send it to the console; set the selectors in managed settings too if you need them locked. Across admin sources, OTEL_LOGS_EXPORTER follows the telemetry unit while the other two merge per key (v2.1.223+).

Per-signal variables you set in managed settings yourself are kept, which is how you send one signal elsewhere (the SIEM example does this). A per-signal credential in managed settings removes the developer-set endpoint for that signal. None of this changes what is collected, only where it goes. Before v2.1.217 each variable followed precedence independently, so a user-level per-signal endpoint could redirect a signal.

From v2.1.251 the same pinning applies when Claude Desktop or a self-hosted environment runner launches Claude Code with an OTLP endpoint in the environment it provides: the launcher's variables win over developer-set ones.

Configuration reference

Core variables

Per-signal endpoint and protocol variables replace the generic one for that signal. Per-signal headers are merged with the generic headers.

Over http/protobuf and http/json, export requests carry a Content-Length header. (Versions v2.1.191 to v2.1.211 used chunked encoding, which Azure Monitor and similar endpoints rejected with 411 or 400.)

Content gates

By default no prompt text, response text, tool arguments or file contents leave the machine. Each of these opts in to more:

There is one built-in exception: for Claude Desktop's own in-process MCP servers, in sessions Desktop owns, mcp_server_name and mcp_tool_name appear on tool_decision and tool_result even without OTEL_LOG_TOOL_DETAILS (v2.1.214+), because the host defines those names.

mTLS

The same configuration covers metrics, logs and traces.

Controlling metric cardinality

Every attribute on a metric is a label, and labels cost storage. These switches decide which ones are attached:

Dynamic headers

If your collector needs short-lived tokens, point otelHeadersHelper in settings at a script that prints a JSON object of string headers. It only applies to the HTTP protocols; with grpc, only the static header variables are used.

{ "otelHeadersHelper": "/opt/acme/bin/otel-headers" }

#!/usr/bin/env bash
token=$(vault read -field=token secret/otel/claude-code)
printf '{"Authorization":"Bearer %s","X-Tenant":"acme-health"}\n' "$token"

The value can be an executable path (spaces allowed) or a command line with arguments; on Windows it always runs through the shell, so quote paths with spaces. It runs at startup and then every 29 minutes unless you change CLAUDE_CODE_OTEL_HEADERS_HELPER_DEBOUNCE_MS.

If the helper fails or prints invalid output, nothing is exported until it recovers. You will see otelHeadersHelper failed; telemetry is not being exported once per interactive session, a note in /status, details in the debug log (--debug or /debug), and a message on stderr in -p sessions.

Team and cost-centre attributes

OTEL_RESOURCE_ATTRIBUTES adds your own keys to every metric datapoint and event, as well as the OTLP resource block, so you can group by them directly in most backends:

export OTEL_RESOURCE_ATTRIBUTES="department=engineering,team.id=payments,cost_centre=ENG-204"

Custom keys never override built-in attributes such as user.id or session.id (except the vcs.* keys, below). To keep them in the resource block only, set OTEL_METRICS_INCLUDE_RESOURCE_ATTRIBUTES=false.

Warning: The format is strict: comma-separated key=value, no spaces, and only US-ASCII without control characters, whitespace, double quotes, commas, semicolons or backslashes. Use underscores or camelCase (org.name=Acme_Health) or percent-encode (org.name=Acme%20Health). Quotes do not escape anything: org.name="Acme Health" gives a value containing the quote marks.

Traces (beta)

Tracing links each prompt to its API calls, tool runs and hooks as one trace. Enable it with CLAUDE_CODE_ENABLE_TELEMETRY=1 and CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1 (ENABLE_ENHANCED_TELEMETRY_BETA also works), then choose a traces exporter. Traces reuse the common endpoint, protocol, header and mTLS settings.

Spans redact prompt text, tool details and tool content unless the matching content gates are on.

Context propagation.

• Bash and PowerShell subprocesses receive a TRACEPARENT variable for the active tool execution span, so scripts can parent their own spans under Claude's trace.
• Direct to the Anthropic API, each model request carries a W3C traceparent from the claude_code.llm_request span, and the API's traceresponse is recorded as a span link. HTTP MCP requests carry traceparent too. Nothing is sent to third-party providers.
• Behind a custom ANTHROPIC_BASE_URL, traceparent (and the subprocess TRACEPARENT) is off by default because some proxies reject unknown headers. Set CLAUDE_CODE_PROPAGATE_TRACEPARENT=1 to turn it on.
• In Agent SDK and -p sessions, an inbound TRACEPARENT/TRACESTATE in Claude Code's own environment makes its interaction spans children of your trace. Interactive sessions ignore inbound values so they do not inherit stray CI context.
• With an inbound TRACEPARENT in those sessions, events also carry trace_id and span_id, even without a traces exporter. A record emitted during an interaction carries the interaction span's IDs; one emitted with no active interaction carries the inbound IDs.

Span tree.

claude_code.interaction                 one per prompt
├── claude_code.llm_request
├── claude_code.hook                    detailed beta tracing only
└── claude_code.tool
    ├── claude_code.tool.blocked_on_user
    ├── claude_code.tool.execution
    └── subagent llm_request / tool spans (when the Agent tool spawns one)

If a PreToolUse hook defers a tool call, the deferred call's spans rejoin the original turn's trace when the session resumes. llm_request, tool.execution and hook spans set status ERROR on failure; others end UNSET. Every span carries the standard attributes plus span.type.

Key span attributes.

Note that input_tokens excludes cache reads and writes, which are reported separately.

The tool.output span event. With OTEL_LOG_TOOL_CONTENT=1, successful Read and Bash calls (and, from v2.1.283, MCP tools, WebFetch and WebSearch) add a tool.output event to the tool span. Edit and Write need OTEL_LOG_TOOL_DETAILS=1 as well. Attributes are content (Read output, or what Write wrote), output (Bash's combined output, or the text an MCP tool or web tool returned, with images shown as placeholders), diff (Edit), plus file_path and bash_command with tool details. Nothing is recorded for errors, non-text Reads (images, PDFs, unchanged re-reads), other tools, or web calls moved to the background. Truncated attributes come with <attribute>_truncated and <attribute>_original_length.

Detailed beta tracing. The claude_code.hook span and a set of extra content attributes only appear with ENABLE_BETA_TRACING_DETAILED=1 and BETA_TRACING_ENDPOINT, which also redirects logs and traces to that endpoint. Both are ignored in project and local settings, and interactive CLI sessions need your organisation allowlisted (SDK and -p sessions do not). The extra attributes, which are not part of the stable schema:

With prompts logged, a claude_code.system_prompt event carries the complete system prompt the first time each distinct one is sent and again after compaction.

Example set-ups

Console output while debugging:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=console
export OTEL_METRIC_EXPORT_INTERVAL=2000

Prometheus scrape at http://localhost:9464/metrics:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=prometheus

With prometheus as the only metrics exporter, the USD, tokens and s units are dropped so the scrape stays valid Prometheus text (combinations like otlp,prometheus keep them). On a self-hosted environment runner, the session binds port 9464 only at capacity one; above that, the runner re-exposes session metrics on its own /metrics.

Metrics and events to different backends:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_METRICS_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=https://metrics.acme-health.internal:4318
export OTEL_EXPORTER_OTLP_LOGS_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=https://logs.acme-health.internal:4317

For metrics only, leave OTEL_LOGS_EXPORTER unset; for events only, leave OTEL_METRICS_EXPORTER unset. Several exporters can be combined, for example OTEL_METRICS_EXPORTER=console,otlp.

Cloud sessions and Claude Tag

Cloud sessions, including Claude Tag channel sessions, run in cloud environments, so laptop settings do not reach them. Configure their telemetry in one of two places:

• Server-managed settings env block. This reaches users' machines and cloud sessions, but not Claude Tag channel sessions.
• The cloud environment's variables. Applies only to sessions in that environment, and is the only route to Claude Tag sessions.

Anyone using an environment can read its variables, so do not put a collector token there, and a network secret will not help because Claude Code's own telemetry export never receives one. If the collector needs a credential, configure the whole export in server-managed settings, where setting a credential also strips endpoints set elsewhere.

Other constraints:

• Exports go through the session's network, so the collector's domain must be reachable at the environment's access level; add it to the environment allowlist if not. No server-managed setting can add domains.
• Claude Tag channels run in organisation-level environments, so change the shared environment set as default or pinned to the channel.
• Cowork does not receive server-managed settings and is configured separately.

Attribution. Cloud sessions carry session.id, ccr.session.id (the session's CLAUDE_CODE_REMOTE_SESSION_ID) and organization.id by default. Set OTEL_METRICS_INCLUDE_ENTRYPOINT=true and Claude Tag sessions show app.entrypoint of claude-in-slack. Set OTEL_RESOURCE_ATTRIBUTES alongside the other variables, not in the environment's setup script, whose exports end before Claude Code starts. In Claude Tag channel sessions Claude acts as the organisation's shared identity, so user.* does not tell you who tagged it.

Attributes on everything

Standard attributes

In sessions signed in to a Claude apps gateway with /login, user.id is the IdP subject, user.email the signed-in email, user.groups the comma-separated IdP groups, and every export carries identity.source: gateway-oidc. This identity is applied last, so user.* and identity.* keys in OTEL_RESOURCE_ATTRIBUTES are ignored. Claude apps gateway configuration covers Desktop and Cowork sessions through a gateway.

Events (never metrics, to avoid unbounded cardinality) also carry prompt.id, workspace.host_paths (Desktop workspace folders), and, for agents inside a workflow run, workflow.run_id (prefixed wf_) and workflow.name (user-authored names become custom without tool details; v2.1.202+).

Repository attributes

With OTEL_METRICS_INCLUDE_REPOSITORY=true (v2.1.269+), Claude Code derives repository identity once per session from the origin remote. HTTPS and SSH remotes on GitHub, GitLab and Bitbucket Cloud give identical results.

Values are lowercased and never include credentials, query strings or fragments. They are omitted with no origin, a non-URL remote, or when the only repository is your home directory. A vcs.* key in OTEL_RESOURCE_ATTRIBUTES overrides the derived value; declaring vcs.repository.url.full stops Claude Code reading the remote at all, which is the fix when a self-hosted server gives HTTPS and SSH clones different paths. For cloud sessions, set the variable on the cloud environment and allow your collector's domain. Anthropic's own telemetry drops all vcs.* keys.

Metrics

Cost and token attributes: model; query_source (main, subagent, auxiliary); speed (fast only when fast mode was used); effort (low, medium, high, xhigh, max, absent when none was sent); and attribution fields agent.name, skill.name, plugin.name, marketplace.name, mcp_server.name, mcp_tool.name.

Attribution redaction without OTEL_LOG_TOOL_DETAILS:

• agent.name: built-in and official-marketplace agents verbatim; other user-defined agents become custom.
• skill.name: built-in, bundled, user-defined and official-marketplace skills verbatim; third-party plugin skills become third-party.
• plugin.name: official-marketplace verbatim; third-party becomes third-party.
• marketplace.name: only ever emitted for official-marketplace plugins.
• mcp_server.name and mcp_tool.name: built-in, claude.ai-proxied and official-registry servers verbatim; user-configured become custom. Present only on requests that consumed an MCP tool result (before v2.1.222 they stuck to every later request, so expect a step down in dashboards after upgrading).

Before v2.1.273 these stayed redacted even with tool details on. The token input type excludes cache reads and writes.

Events

Events need OTEL_LOGS_EXPORTER set. Every event carries the standard attributes plus event.name, event.timestamp (ISO 8601) and event.sequence.

Correlation

Joining events to transcripts (message.uuid, request_id as requestId, tool_use_id) works, but the transcript format is internal and changes between versions, so treat any such join as version-specific.

Conversation and API events

In raw-body file mode, each successful response also appends a line to <dir>/index.jsonl with timestamp, session_id, query_source, model, request_id, message_id, message_uuid, request_file and response_file (v2.1.274+). Request files are <uuid>.request.json; response files are <request_id>.response.json.

For subagent cost, use the token and cost counters filtered to query_source of subagent rather than subagent_completed, whose total_tokens covers only the final request. That category also includes agent-based hooks, which emit no subagent event.

Tool and permission events

claude_code.tool_result: a tool finished (rejected calls do not produce one). Attributes: tool_name, tool_use_id (matches hook payloads), success, duration_ms, error_type, decision_type (always accept), decision_source (config, hook, user_permanent, user_temporary), tool_input_size_bytes, tool_result_size_bytes, mcp_server_scope. With tool details: error (full message), tool_parameters, tool_input (values over 512 characters truncated, about 4K characters in total), and for a successful git commit from Bash or PowerShell, vcs.ref.head.revision, vcs.ref.head.name and vcs.ref.head.type (v2.1.269+).

tool_parameters contents by tool:

• Bash: bash_command, full_command, timeout, description, dangerouslyDisableSandbox, plus git_commit_id and git_branch after a successful commit. The desktop workspace Bash tool reports only the first three.
• MCP tools: mcp_server_name, mcp_tool_name.
• Skill: skill_name.
• Agent (or legacy Task): subagent_type.

claude_code.tool_decision: a permission decision. Attributes: tool_name (user-configured MCP tools always show as mcp_tool), tool_use_id, decision (accept, reject), tool_source (builtin, mcp, sdk_host_builtin_mcp; v2.1.214+), source, and tool_parameters with tool details (same shape as above, minus commit fields; useful for seeing exactly what was rejected).

What source means:

claude_code.permission_mode_changed: from_mode, to_mode (default, plan, acceptEdits, auto, bypassPermissions), trigger (shift_tab, exit_plan_mode, auto_gate_denied, auto_opt_in; absent for SDK or bridge changes).

Session, auth and extension events

plugin_id_hash is a deterministic hash of plugin name and marketplace (for plugins synced from claude.ai, the marketplace name claude.ai reports, or synced), so you can count distinct third-party plugins without recording names. It and plugin.name go only to your exporter. safe_mode reflects --safe-mode (v2.1.169+), in which plugins report inventory but do not load.

Retention sweep event

claude_code.retention_sweep (v2.1.227+) is emitted once per run of the clean-up that deletes data older than cleanupPeriodDays. The sweep runs in the background at most once per session; if another session on the machine swept in the last 24 hours, this one waits at least 10 minutes, so short sessions emit nothing. claude -p --bare never sweeps.

A cleanupPeriodDays in managed settings lets the sweep run even when a lower-priority settings file is broken; a broken managed-settings.json still pauses it unless another managed source supplies the value. Counters are only present on complete results.

Managed settings resolved event

claude_code.managed_settings_resolved (v2.1.274+) records which managed policy a session ended up with: at startup, whenever the policy or its helper changes, and when a policy stops the session. It is how I find laptops on the wrong policy source or with a broken policy helper.

Redaction keeps names, booleans, numbers and fixed-choice strings (such as permissions.defaultMode), and replaces every other string, URL, command and env value with "[REDACTED]". Permission rules keep their tool name, as in Bash([REDACTED]), for built-in tools and mcp__ references. OTEL_LOG_MANAGED_SETTINGS cannot be enabled from project or local settings, and server-managed settings can set it without the approval dialog. In an untrusted folder, the refusal event is not exported.

Turning the data into answers

Usage and cost

Cost metrics are estimates; your provider's billing is authoritative. Each streaming response is counted exactly once, even when a gateway streams usage across several frames (before v2.1.214, multi-frame usage inflated cost and token counts).

model is available on the token, cost and lines-of-code metrics. Commits have no model, so approximate by joining to the token or cost metric on session.id, filtering that side to query_source of main so subagent and auxiliary calls do not skew the attribution.

Good alerts to start with: cost spikes, unusual token consumption, and unusually high session counts from a single user.

Spotting retry exhaustion

Claude Code retries internally and emits one api_error when it gives up, with attempt holding the total. CLAUDE_CODE_MAX_RETRIES defaults to 10 and caps at 15; CLAUDE_CODE_RETRY_WATCHDOG (v2.1.199+) raises the default and removes the cap. So an exhausted transient error shows attempt of 11 by default and at most 16 without the watchdog. Lower values mean a non-retryable error (such as a 400) or a cause with its own smaller budget, such as failing to load AWS or Google Cloud credentials (retried at most twice). To tell recovery from a stall, check for a later api_request in the same session.id.

Tool patterns and performance

From tool_result events: most-used tools, success rates, average duration, and error types per tool. From api_request and tool events: latency hot spots.

Mapping to GenAI semantic conventions

Claude Code does not set gen_ai.usage.*. Its input_tokens (span, event, and the metric's input type) excludes cache tokens, whereas the conventions' gen_ai.usage.input_tokens includes them. To compute the convention value, add input, cache read and cache creation. Cache reads map to gen_ai.usage.cache_read.input_tokens and cache creation to gen_ai.usage.cache_write.input_tokens (older conventions call it gen_ai.usage.cache_creation.input_tokens).

Security auditing

OTel events are Claude Code's audit trail. Send them via the logs exporter to any SIEM with an OTLP receiver, or through an OpenTelemetry Collector.

Who did it

Events carry user.email, user.account_uuid, user.account_id and organization.id when signed in with a Claude account (or in a cloud session with its own credentials), plus user.id and session.id. Claude Code does not act under a service account: in a developer's session, MCP calls, Bash commands and edits are attributed to that developer, or to their IdP identity in a Claude apps gateway session. Claude Tag channel sessions use the organisation's shared identity.

With a direct API key, Bedrock, Agent Platform or Foundry there is no Claude account, so only user.id and session.id are populated. Add identity yourself, per user, through managed settings or a launch wrapper:

export OTEL_RESOURCE_ATTRIBUTES="enduser.id=priya.shah@acme-health.co.uk,enduser.directory_id=EMP-10442"

MCP activity

Turn on the logs exporter and OTEL_LOG_TOOL_DETAILS=1 for full detail:

Without the flag, tool_name is the literal mcp_tool for user-configured servers, arguments are omitted, and connection events drop server_name and the error message but keep is_plugin, plugin_id_hash and a redacted plugin.name.

Detection cheat sheet

Claude Code emits raw events only. Baselining, anomaly detection, cross-session correlation and alerting are your SIEM's job.

Egress paths, controls and evidence

The settings reference documents each key. Caveats: allowedHttpHookUrls merges across settings files, so developers can add to an empty managed list (allowManagedHooksOnly decides what runs); hook events fire once per hook event, not per hook, and an HTTP hook's URL appears only in hook_definitions, which needs detailed tracing. For what Claude Code itself sends to Anthropic, see Data usage.

Warning: OTEL_LOG_TOOL_DETAILS=1 puts commands, server names and tool input in your telemetry, which can be as sensitive as the session itself. Only enable it where your collector is approved to hold that content.

Verifying retention

Set cleanupPeriodDays in managed settings, collect retention_sweep, and cast period_days and the counters from strings to numbers before comparing:

The sweep does not cover every path; The .claude directory lists what remains and how to clear it.

Shipping events to a SIEM

Events only, full tool detail, straight to an OTLP receiver:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_LOG_TOOL_DETAILS": "1",
    "OTEL_EXPORTER_OTLP_LOGS_PROTOCOL": "http/protobuf",
    "OTEL_EXPORTER_OTLP_LOGS_ENDPOINT": "https://siem-ingest.acme-health.co.uk:4318/v1/logs",
    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer siem_ingest_44a0"
  }
}

Send a prompt and look for claude_code.user_prompt in the SIEM; if nothing appears, check a --debug-file log for [3P telemetry] errors.

Choosing backends

• Metrics: time-series databases for rates and aggregates; columnar stores for complex queries and unique-user counts; full observability platforms for visualisation and alerting. If you need DAU, WAU or MAU, pick something good at distinct counts.
• Events: log aggregation for search; columnar stores for structured analysis; observability platforms to correlate with metrics.
• Traces: a distributed tracing system for waterfalls and latency, or a platform that links traces to metrics and logs.

Resource attributes

Every export carries:

• service.name: claude-code for terminal sessions, claude-code-desktop for Code tab sessions. If your pipelines filter on claude-code, add the Desktop name too.
• service.version: Claude Code version (or the Desktop version for Code tab sessions).
• os.type, os.version, host.arch, and wsl.version under WSL.
• Meter name com.anthropic.claude_code.

Anthropic publishes a Claude Code monitoring guide on GitHub (anthropics/claude-code-monitoring-guide) with Docker Compose, Prometheus and OpenTelemetry set-ups and report templates for measuring ROI. AWS publishes Bedrock-specific monitoring guidance in its "guidance for Claude Code with Amazon Bedrock" sample repository.

Privacy summary

• Export is opt-in and goes only to the endpoint you configure. Anthropic's own operational telemetry is separate; see Data usage.
• Metrics and events never contain raw file contents or code snippets. Trace spans are a separate path governed by OTEL_LOG_TOOL_CONTENT.
• With OAuth sign-in, user.email is included, sent only to your endpoint. Filter it in your backend if that matters to you.
• Prompts are recorded as length only unless OTEL_LOG_USER_PROMPTS=1. Then the prompt appears in both prompt and prompt_text on user_prompt events, so a collector rule that drops it must name both:

processors:
  attributes/strip-prompts:
    actions:
      - key: prompt
        action: delete
      - key: prompt_text
        action: delete

With tracing, the interaction span's user_prompt also carries it, and detailed tracing adds messages, tool results, system reminders, system prompt text and model output.

• Responses are length only unless OTEL_LOG_ASSISTANT_RESPONSES=1 (or it falls back to the prompts flag). Under detailed tracing, response.model_output follows the prompts flag regardless.
• Tool arguments need OTEL_LOG_TOOL_DETAILS=1. Then tool_parameters (untruncated full_command included) and tool_input appear, plus real command and attribution names. Arguments can contain secrets, so redact in the backend.
• Tool output in spans needs OTEL_LOG_TOOL_CONTENT=1, truncated per attribute at the content limit.
• Raw API bodies need OTEL_LOG_RAW_API_BODIES set in your shell, user settings or managed settings (never project or local). They contain the full conversation; extended thinking is always redacted. Use file:<dir> for untruncated files and ship that directory with a log collector rather than the telemetry stream.

Related

• Costs
• Analytics
• Managed settings
• Security
• Claude apps gateway