Traces & Cost Attribution
Your provider bills you per API key. On a shared pool, the question you actually need answered is per agent. SpiderGate traces every request through the gateway and attributes it to the agent that caused it.
Every request has a trace you can open
One row per request: the agent that sent it, the model it asked for, the model that actually answered, latency, tokens and cost. Click any row and the request comes apart into its spans, so a slow request tells you where it was slow rather than just that it was.
Span waterfall
Auth, routing, the model call and tracking as proportional bars. A failed span shows in red at the point of failure.
Requested vs served
When an alias falls through its chain, the trace records the model that actually answered — so a quiet drop in quality has somewhere to be looked up.
Spend belongs to the agent that caused it
Provider billing is per key, and on a shared pool that is one line for everything. Filter the trace list to a single agent token and you have that agent's whole history: its requests, its latency, its spend. Agencies get the per-client split; platform teams get the runaway agent.
Filter by agent
Narrow to one token, or jump straight there from that agent's card in Keys.
Brand isolation
Traces are keyed to your client_id, the same identity the API authenticates you with. A brand only ever sees its own.
Tie a request in your code to its row here
Every gateway response carries an x-trace-id header. Log it and you can find that exact request later. Add include_route_trace to get the per-attempt dispatch detail inline, without a second call.
// every response carries the correlation id
const res = await fetch("https://spideriq.ai/api/gate/v1/chat/completions", { method: "POST", headers, body });
const traceId = res.headers.get("x-trace-id");
// → 441c7118-77b3-4e33-a369-d9edcff2123d
// paste it into the Traces search box
const body = await res.json();
body.model; // the model that ACTUALLY served
Two stores, so the view degrades instead of going dark
Request metadata is written to SpiderGate's own database on every call. Full message bodies and span timings live in a separate tracing service. Two systems fail independently, so if the body store is unreachable the list and the summary stats still load without it.
Metadata, always
Model, tokens, cost, latency, status and the trace id. No message bodies, deliberately.
Bodies, when available
Prompts and completions are held in the tracing backend with a retention window. Keep your own copy if you need a permanent record.