
What’s in a trace
Every completion that flows through the OpenTracy engine is persisted with this shape:
Where they live: a ClickHouse column-store, designed so that billion-row
aggregations (cost per model per day, latency p99 per alias) stay fast.
How they’re created: you don’t call a separate
log_trace() API. Any
request that hits /v1/chat/completions on the engine — whether from the
Python SDK, the OpenAI SDK pointed at the engine URL, or a raw curl — is
traced automatically.
How traces are created (three paths)
Path A — Python SDK
Path B — OpenAI SDK (drop-in)
Path C — Raw HTTP
Inspecting traces
The REST API exposes a search interface:model, provider, routing_alias, status, tenant_id, since,
until, and full-text search on input_text / output_text.
In the UI, traces live under Traces → Browse with filters, a cost/latency
chart on top, and a detail drawer that shows the full prompt + response
and lets you “add to dataset”.
Attaching metadata
You control metadata — use it to link traces back to your app’s world:ticket_classifier feature where the
user gave positive feedback”.
Privacy and PII
Traces store full prompt and response text by default — that’s what makes distillation possible. Two knobs for environments that can’t do that:- Set
OPENTRACY_TRACE_REDACT=trueto strip matched patterns (emails, phone numbers, credit cards) before persist. - Set
OPENTRACY_TRACE_CONTENT=falseto store only metadata + token counts + cost, dropping the text entirely. You lose distillation ability but keep cost analytics.
trace header:

