Traces

Every SpiderGate request is traced. The Traces view shows exactly what each agent sent, what came back, which model served it, how long each step took, and what it cost. When an agent misbehaves or a bill surprises you, this is where you look. Find it on the Traces tab at /dashboard/gate/traces.

The trace list

The list shows one row per request, newest first. Each row carries the timestamp, the agent (avatar + name), the requested model → the actual model that served it, a status badge, latency, token count, and cost. A summary bar across the top shows total traces, error rate, total cost, and average / p95 latency for the current filter.

Filter the list by:

• Agent — narrow to a single token. (The View Traces button on an agent card in Agent Keys opens the list pre-filtered to that agent.)

• Status — success, error, or all.

• Date range — last 24 hours, 7 days, or 30 days.

• Model, minimum latency, or minimum cost — to hunt down slow or expensive calls.

Trace detail

Click a row to open the full trace:

• Header — request id, status, latency, cost, agent, and model → provider.

• Span waterfall — proportional bars for each phase of the request: auth → route → the LLM call → tracking. Error spans show in red, so you can see where a failure happened.

• Input / output — the actual messages, role-colored (system, user, assistant, tool), each with a copy button.

• Tokens & cost — a combined bar split into prompt vs. completion, with per-segment cost.

• Metadata — provider, whether the response was cached or streamed, time-to-first-token, and any fallback or error detail.

This is where the routing signals from the API become visible after the fact: if a request fell back from its alias's first choice, the trace shows which model actually served it.

How tracing works

Identity is anchored on your client_id — the same ground truth the API uses. Two stores back the view:

• Request metadata is always logged to SpiderGate's database — model, tokens, cost, latency, status — with no message bodies, for efficiency.

• Full message content and span timings are captured in the tracing backend (LangFuse), keyed to your client_id so you only ever see your own brand's traces.

The detail view reads the rich backend when it's available and falls back to the metadata-only store if it isn't — so the list and summary stats are always there, even if message bodies aren't.

Note: SpiderGate stores message metadata for every request but only retains full message bodies in the tracing backend. If you need a permanent record of prompts and completions, capture them in your own application as well.

Next steps

1. Filter to a single agent from Agent Keys.

2. Reconcile totals on the Usage tab.

3. Understand the fallback signals in Chat Completions.