When a routed LLM request misbehaves, the first question is always the same: what actually happened? nRouter answers that question on every response, before you ever open the dashboard.
Every response carries headers that say which route was taken and what it cost. x-nr-request-id is the unique id for the request — use it with support and in your logs. x-nr-model names the model that answered. x-nr-routing reads direct, or fallback with its 0-based position in the chain that answered. x-nr-attempts says how many provider calls were made. The cost headers give the charge in USD and whether it is exact. Token counts, funding source (allowance or credits), and latency in milliseconds round it out. A guardrail outcome header, x-nr-guardrails, rides along too.
Two headers are absent when no provider call was made: x-nr-routing and x-nr-attempts. That happens on a cache hit, or a refusal before the provider — the absence itself is information.
The dashboard Logs keep the same record on each request row: the request id, the model that served it, the cost, and a routing record with attempts, served_rank (0 is the primary), fallback_used, and source — which chain was in force, the organization policy or the per-request list.
This tracing sits on top of a routing design with four ways to choose a model: direct, direct with per-request fallbacks, a Smart Router alias you configure, and nrouter/auto. Fallbacks move the request to the next model in the chain on a rate limit, a 503/401/404, or a connection failure — never on a 500/502/504 or timeout, because the provider may already have done the work. One request holds credit once and settles once, at the price of the model that actually answered.
The full routing reference — strategies, fallback chains, automatic routing, and tracing — is published at https://nrouter.ai/product/routing. Start with the route you do not have, not the one you think you need.