Traces

The Traces page lists recent traces for the project and lets you drill into any one.

​

Trace list

Each row shows the trace id (click to copy), name (root span), agent, an env pill (prod highlighted, dev muted), duration (amber over 3 s, red over 5 s), the run’s eval scores, and age. A colored right border flags each run’s status (red error, amber changed, green ok). Specific signals show as thin colored sticks right next to the eval ticks — red for an error / tool error / no output, amber for changed — each popping a label on hover.

​

Saved views, filter tokens & search

Tabs above the table are saved views with live counts — All, Errors, Changed, Slow >3s, Eval’d. Clicking one filters the list and drops a filter token (e.g. status:err, dur:>3s) with a × to clear. Alongside them, a free-text search matches over name, agent, and trace id, and a counter shows X of Y traces.

• Errors covers real failures — an errored span, a failed tool call, or a run that produced no final output (agent died / truncated mid-run). The trace detail names the likely cause (error, truncation, dangling tool call, or silent no-output), and when run baselines are on it’s also persisted as a run.health score.
• Changed flags a run whose system prompt or final output differs from the previous run of the same agent (matched by agent_name) — a prompt edit or behavioral shift.

​

Eval scores in the row

The evals column headlines the run’s run score — the mean of its sampled eval dimensions folded with the run’s health, colored by threshold (green ≥ 0.90, amber ≥ 0.80, red below) — followed by three ticks for faithfulness · trajectory · schema, each colored by its own value (muted when that dimension didn’t run). Hover for the breakdown (run score, whether health moved it, and each dimension). A healthy, unsampled run shows —; an unsampled run that had an issue still shows a run score, so problems surface even without evals. See run status & score.

​

Live & compare

The list is live: a pulsing Live dot in the header shows it is polling, and the table refreshes whenever a newer trace arrives — no reload needed. Tick the checkbox on two rows to Compare them side by side.

​

Trace detail

Opening a trace shows:

• Run status & score — a header line with the run’s status and run score. The status is the run’s health: OK when the agent returned a final response, or an issue — run errored, output truncated, ended on a tool call, no final output (task agent died mid-run), or no reply (a chat run that ended without answering the user’s last message). The run score (0–100) folds the run’s eval quality with that health: it starts from the mean of the applied eval dimensions (or a nominal 100 when nothing scored the run), then an errored run drops to 0, an incomplete run is heavily penalized, and a run whose output changed vs the previous run is docked slightly (so it doesn’t read as a settled 100). Hover the score for the issues that moved it.
• Auto Evals — a panel that asks Claude Sonnet to read a run — its output, the tools it called, the agent, whether the output is JSON, and its run health — and suggest online evals to add, each mapped to a real eval kind (LLM judge, structured-output checks, tool-call trajectory, run baselines, or an approval guard). Suggestions skip evals the project already has, and each one has an Add button that creates it on the Evals page in one click. It appears in two places: on a trace (analyzing that run) and on the Evals page (analyzing your most recent run).
• Tool call timeline — a single segmented bar aligned under the waterfall’s time axis (so its segments line up with where the spans ran), answering was the agent working or waiting? Wall-clock time is attributed to generation, tool (ok / error), retrieval, HTTP, other, and idle (the hatched gaps where nothing was running). It sweeps leaf spans, so nested spans aren’t double-counted the way a naive per-span sum would.
• Conversation — the run read as a chat thread (system, user, assistant, tool messages), shown at the bottom of the page. A model’s extended thinking / reasoning renders inline as a distinct ✳ thinking block ahead of the answer it produced, so you can see how the agent reasoned. A long system prompt (more than 10 lines) is collapsed to its first 10 lines with a Show more toggle. When the agent spawned subagents, each appears as a card you can click to slide into that subagent’s own conversation, with a breadcrumb to walk back up (the current subagent is deep-linkable, ?agentSpanId=). Agents that captured no conversation (e.g. non-chat / task agents) don’t render this block at all.
• Span waterfall — the spans laid out by time, so you can see planning, retrieval, tool calls and generations in sequence. Each span carries an icon and color for its kind (agent, LLM, tool, retrieval, embedding, guardrail, HTTP); errored spans and failed tool calls turn coral. Captured outbound calls (Probes) show as http with method + status; the header counts how many were http captured.
• Per-span detail — model, token breakdown (input / output / cache / thinking), cost, latency, status, and the input/output payloads. Reasoning captured on the span shows as a ✳ thinking block alongside the prompt and output.
• Outlier badges — when a run’s duration, cost, tokens, or TTFT lands in the project’s recent p90 / p95 / p99, an outlier: row flags it. Hover a badge for a quantile strip placing this run against the cohort (“N× median”).
• Baseline badges — when run baselines are enabled, a vs baseline row shows whether this run’s runtime, cost, and span count are normal for the agent (or baseline learning (n/5) during the learning phase).
• Session link — if the trace carries a session_id, a ↳ session link jumps to the full multi-turn session.
• Structured-output diff — when the run’s JSON output shape changed vs the same agent’s previous run, a panel lists the added / removed / retyped fields (see structured-output eval).
• Evals — a chip row showing which of the project’s evals are in scope for this trace, each marked ✓ when it produced a score or · pending when it applies but hasn’t scored yet — the quick “was evaluation running on this run?” signal.
• Scores — any eval or annotation scores attached to the trace, plus an Add score button to attach a manual score right here (see scoring from the UI).
• Export — download the trace as JSON (the raw spans + scores, full fidelity) or Markdown (a readable digest: metadata, system prompt / input / output, tool calls, a span table, and scores). Use the Export button in the trace header.

​

Scoring from the UI

You can attach a manual score to a run without an annotation queue. Click Add score in the trace’s Scores card (or Session scores on a session), pick a score name, and enter a value:

• Choosing a score config drives the input by its type — a numeric field (with the config’s min/max), a category dropdown, a pass/fail toggle, or a text box — and the value is validated against the schema before it’s written.
• Choose Custom to record an ad-hoc numeric score with no config.

Manual scores are written with source = ANNOTATION and attributed to you. Trace scores land on the trace; session scores are session-level (not tied to a single turn).

​

Spotting slow runs

The list color-codes duration (amber over 3 s, red over 5 s) and the Slow >3s saved view filters to them in one click. For cohort-relative outlier detection — duration, cost, tokens, or TTFT against the project’s recent p90 / p95 / p99 — open a trace: the detail page shows outlier: rows with a quantile strip, complementing the per-agent baselines.

​

Compare runs

Put two runs side by side to see exactly what changed — not just the text, but the shape of the run. The compare view stacks several diffs of run B vs A:

• Metric deltas — spans, errors, duration, tokens, and cost, each showing B’s value and the signed change (a cost/latency increase reads amber, a decrease green).
• Time composition — the working-vs-idle bar for each run, side by side, so a regression in where time went is obvious.
• Span tree — the two span trees aligned by structure, marking each span added, removed, changed, or unchanged, with per-span duration deltas. Unchanged spans are hidden by default (toggle show unchanged).
• Tool calls — the two runs’ tool calls in execution order, side by side. A badge flags whether the sequence is unchanged, order changed (same tools, different order), or calls changed (different tools); positions that differ are highlighted, and errored calls carry a red dot.
• System prompt & Output — two columns rendering markdown, with changed sections highlighted (removed on the left, added on the right), each tagged changed or unchanged.

​

Where traces come from

Anything that exports to the OTLP endpoint:

• Claude Agent SDK via trace()
• Vercel AI SDK via OpenTelemetry
• Claude Code sessions via /v1/logs