[FEATURE] granular OTEL_LOG_ASSISTANT_RESPONSES flag for opt-in logging of assistant response text

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Summary

Add an opt-in telemetry flag — e.g. OTEL_LOG_ASSISTANT_RESPONSES=1 — that attaches Claude's response text to the existing claude_code.api_request event (or a dedicated lightweight event),
mirroring how OTEL_LOG_USER_PROMPTS=1 attaches user prompt content today.

Motivation

We run a self-hosted analytics backend on Claude Code OTLP telemetry, including an LLM-judge that scores prompt efficiency. We hit a structural blind spot: many follow-up prompts are
confirmations or selections of something Claude proposed in its previous turn — e.g. "yes, go ahead", "I prefer the second", "commit this fix". Judged in isolation these look contentless, but
in context they're efficient, high-quality communication.

Because telemetry captures the user prompt but never the assistant turn in between, any downstream consumer is blind to what is being approved. We can correctly score confirmations whose
referent appears in the prior user prompt, but not those that approve a proposal made in Claude's reply — that information simply isn't in the telemetry stream.

Why the existing option is insufficient

OTEL_LOG_RAW_API_BODIES=1 does expose response content via api_response_body, but it's all-or-nothing: it emits the full raw Messages API payload — entire conversation history, system prompt,
all prior turns — capped at ~60 KB inline or spilled to disk. For consumers that only need the latest assistant turn text, this is a large payload, storage, and PII-exposure cost to carry for a
small slice of data.

Proposed Solution

• New env var OTEL_LOG_ASSISTANT_RESPONSES (default off), parallel to OTEL_LOG_USER_PROMPTS.
• When enabled, attach the assistant's response text for that turn only (concatenated text content blocks — not the full conversation history) to claude_code.api_request, or emit a dedicated

claude_code.assistant_response event.

• Off by default; redacted unless explicitly enabled — same privacy posture as user-prompt logging.

Alternative Solutions

_No response_

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

Prompt-quality scoring (our case), conversational audit trails, turn-level cost/output correlation, and any LLM-judge pipeline that needs to evaluate a follow-up against what preceded it —
without the overhead of full raw-body logging.

Additional Context

_No response_