What does setting TRACELOOP_TRACE_CONTENT=false change in OpenLLMetry spans?

## The default is to record everything This is the single most important fact about OpenLLMetry's content behaviour: prompt and completion text is captured by default. The library's purpose is debugging LLM applications, and the payload is what you actually want to see when an answer is wrong. So an unconfigured install of the SDK, dropped into a service that processes customer messages, medical notes or payment disputes, ships that text to your tracing backend. Nobody has to opt in for it to happen. ## What the toggle does Setting the environment variable `TRACELOOP_TRACE_CONTENT` to `false` disables recording of the message payload. Concretely: **Still recorded:** provider, operation, request and response model, sampling parameters such as temperature and max tokens, `gen_ai.usage.input_tokens` and `gen_ai.usage.output_tokens`, span name, start and end time, parent/child structure, exception and status information, plus your own workflow and task span names. **No longer recorded:** the prompt messages and the completion messages — the content attributes that carry the role and text of each turn. That split is the answer to the question an interviewer usually asks next: what do you lose? You keep every quantitative view — cost by model, p95 latency, error rate, throughput — and you lose qualitative debugging. "This request cost 4,100 input tokens and took 9 seconds" survives; "and here is the 4,100-token prompt that caused it" does not. ## Its granularity, and why that matters The toggle is environment configuration, so it applies to the whole process for its lifetime. There is no per-request switch: you cannot record content for internal users and suppress it for customers within a single process. The practical consequence is architectural — if only some traffic may be captured, you separate it into different deployments with different configuration, rather than trying to branch inside one service. Being configuration rather than code also means it is easy to get wrong in the direction that hurts. A missing environment variable in one environment fails **open**: content is captured. Compare that with a secret, where a missing value fails closed and you find out immediately. So the toggle belongs in the same tier of review as any other security-relevant default: asserted in deployment manifests, not left to a developer's shell. ## Not retroactive Turning it off stops future spans from carrying content. Spans already exported are in the backend, subject to that backend's retention and access controls. An incident response after accidental capture therefore has two parts: change the configuration, and then deal with the data already stored — deleting the affected traces, or waiting out retention if deletion is not supported, and recording the exposure. Saying this out loud in an interview is a strong signal, because it is the part teams forget. ## When plain on/off is not enough Common middle grounds: - **Redact in a span processor.** Attach a custom OpenTelemetry span processor that rewrites or drops the content attributes before export — for example replacing detected identifiers, or storing only a hash so you can tell whether two requests carried the same prompt without holding the text. - **Store content elsewhere.** Keep an application-side reference (a record id) on the span and put the payload in a system that already has the right access controls, retention and deletion workflow. The trace then links to evidence instead of being the evidence. - **Separate deployments by data class.** Content on for the internal or synthetic-data tier, off for regulated traffic. - **Turn it on temporarily.** Capture content in a staging environment reproducing the bug, rather than in production. ## What content capture costs even when it is allowed Even with no privacy constraint, payloads dominate span size. A RAG prompt with several retrieved chunks can be tens of kilobytes; multiply by request volume and content is usually the majority of your LLM tracing bill, and the reason spans get truncated or rejected by ingestion limits. So the toggle is a cost lever as well as a privacy lever, and "we turned content off in the highest-volume service and kept it on in the low-volume ones" is a perfectly respectable production answer. ## The interview shape Expect the question as a scenario: "you added LLM tracing to a service handling personal data — what did you check first?". The complete answer is: capture is on by default, `TRACELOOP_TRACE_CONTENT=false` turns it off, metadata survives so your dashboards do not, the setting is process-wide and fails open when unset, it does not clean up what was already sent, and redaction in a span processor is the option when you need something between all and nothing.