Tracing
Tracing captures the full prompt, completion, and any tool calls for every request made with a tracing-enabled key — automatically, with no SDK and no code changes. Turn it on per key from the Tracing settings page, then browse what it captured there.
What it is
When tracing is enabled for a key, every request through that key — streaming or not, through /v1/chat/completions or /v1/messages— is captured in full: the complete request (system prompt, message history, tool definitions) and the complete response (the assistant's reply, including any tool calls it made), alongside the usual model, provider, tokens, cost, and latency. There is nothing to install and nothing to change in your application code — it's a per-key setting, not a per-request one.
Enabling it
Tracing is off by default and configured per key, not per request. Enable it from the Tracing settings page. Once enabled, every eligible request made with that key is captured automatically.
Grouping calls into one trace
By default, every call is its own trace. If your app makes several related calls — an agent's multi-step run, a multi-turn conversation — you can group them together with three optional request headers. None are required; a call with none of them is still captured in full, just as a standalone single-call trace.
| Header | What it does |
|---|---|
| x-mizan-trace-id | Any string you choose. Calls sharing the same value are grouped into one trace, ordered by time. |
| x-mizan-session-id | Groups multiple traces together — e.g. every trace in one multi-turn chat. |
| x-mizan-trace-name | A human-readable label shown in the traces list. Falls back to the model name when omitted. |
What's captured — and what isn't
Mizan is a gateway: it only ever sees the calls that actually pass through it. A tracing-enabled key captures every prompt, completion, and tool call the model made or received in full — that data genuinely flows through every request, so nothing is missed there. What it cannot see is anything that happens outsidethe gateway: the actual execution of a tool your code runs, a retrieval or database call, or any other business logic between two calls. If you need visibility into that, it has to happen in your own code — Mizan's trace is the LLM half of the picture, not the whole agent.
Very large request or response bodies (long multi-turn histories, large multimodal payloads) are captured up to a size cap; content past that cap is stored as a truncation marker instead of being dropped — the call's cost, tokens, and metadata are always captured either way.
Visibility
Captured traces — including full request/response content — are visible to anyone with dashboard access to the workspace or organization the key belongs to, not just the person who created the key. Turning tracing on for a key means its real prompts and completions become visible in the dashboard to the rest of your team.
Best-fit use cases
- Debugging what an agent actually sent and received on a specific run.
- Auditing exactly what prompts and completions a key produced, end to end.
- Tracking spend down to the individual call — every token, every dollar, tied to the exact prompt that produced it.