Workflows, Sessions and Traces
The three ways the dashboard groups your calls — a named agent loop, one conversation, and one run — and what each detail view shows.
Three tabs slice the same traffic at three different sizes. Getting them right depends entirely on what your app tags each call with; see Sessions and traces.
| Tab | One row is | Comes from |
|---|---|---|
| Workflows | A named agent loop in your app, like support-chat. | The workflow name you wrap your agent code with. |
| Sessions | One conversation. | The session_id your app sets. |
| Traces | One agent run — one user message and the whole agent loop it triggered. | The run id the SDK carries through a request. |
A turn is one trace. Turns that share a session id collapse into one session. Runs with no name roll up under (unnamed).
Workflows
Ranked by spend, one page of 50, sortable by Cost / Runs / Tokens / Calls / Recent / Drift.
| Column | Shows |
|---|---|
| Workflow | The name, with how many models it used. |
| Runs | Executions in the range. |
| Total cost, Avg cost / run | Spend, and the per-run figure that drift is measured against. |
| Avg calls / tokens / tools / duration per run | The shape of a typical run. |
| Errors | Failure rate. |
| Signals | Badges: a cost-drift percentage (only at +30% or more), a tool error rate, and Loop when loop rules fired. |
| Last run | Recency. |
The detail view adds cost over time, a cost-driver attribution panel explaining why per-run cost moved against the 30-day baseline (including model-mix shifts), tool timing and reliability, token and prompt-composition breakdowns, and the firewall actions that hit this workflow. Drift gauges need 20 runs of history before they render anything.
Sessions
Six KPI tiles — sessions, model calls, total cost, total tokens, firewall actions, dry-run catches — then a table of Session · Turns · Model calls · Tokens · Cost · Duration · User · Last active, searchable by session id and sortable by recency, cost, tokens, turns or duration.
Open one and you get its turns as an accordion, a per-turn chart (cost, tokens or duration), usage split by modality, and — once there are 20 comparable sessions — a gauge placing this session against a typical one.
Traces
A rail of runs beside a detail pane, filterable by Loop / Reroute / Blocked / Error and
shareable by URL. Cost cells carry a prefix when the number is incomplete: ≥ means some call had
no price, ~ means it was approximated.
The detail view is the deepest screen in the product: a waterfall of every span, per-span prompt and response composition, a cost breakdown table with the unit, quantity and rate behind each dollar, reroute annotations, and — when a loop rule fired — the loop fingerprint sequence, one chip per call the detector evaluated with the repeating cycle outlined.
What to look for
- Every session has exactly one turn —
session_idisn't threaded across turns, so the grouping is doing nothing. Threaded properly, one conversation is one row with many turns. - All runs under (unnamed) — nothing wraps your agent code with a workflow name, so per- workflow drift can't be attributed.
- A run with far more calls than its siblings — a loop candidate. Check its fingerprint.
- A
≥prefix on many rows — real spend is higher than shown; see Unpriced calls. - Loop chips on a workflow with no loop rule armed — the detectors are watching but only alerting.