# Inspecting request routing

Source: https://platform.lyrouter.com/ai_gateway/docs/route-log/en
Last updated: 2026-10-19

Which model and which provider finally answered a call, whether the gateway switched channels along the way and why, are all recorded in the route trace of the log detail. The current Account Owner and workspace Admins see it by opening a log in **Log analysis**. After adjusting [Smart routing](https://platform.lyrouter.com/ai_gateway/docs/routing/en), [virtual models](https://platform.lyrouter.com/ai_gateway/docs/presets/en) or [BYOK](https://platform.lyrouter.com/ai_gateway/docs/byok/en), use it to confirm the settings work as expected.

## Start with the basic information

The basic information at the top of the log detail is visible to every member who can see the log, and answers "who finally answered":

| Field | What it tells you |
| --- | --- |
| Model (request) | The model written in the request, such as `deepseek/deepseek-v4-flash`, `@vmodel/<name>` or `lyrouter/auto` |
| Model (actual) | The model that actually answered. When it differs from the requested model, usually a virtual model or `lyrouter/auto` chose a specific model, or every channel of the requested model failed and the workspace's Default Model took over |
| Provider | The provider actually called. In the log list, the Provider column carries a "BYOK" tag when a BYOK credential was used |

## Parts of the route trace

In the Overview tab of the log detail, Route trace lists the following parts in time order:

| Part | Content | Notes |
| --- | --- | --- |
| Request received | Log time, API path and the requested model | Confirms this is the request you are looking for |
| Route selected | Routing strategy, Virtual model when called through a virtual model, and "BYOK：<name>" when a BYOK credential was used | For the values of Routing strategy, see [Channels and routing](https://platform.lyrouter.com/ai_gateway/docs/routing/en#multi-channel-routing-strategy) |
| Hit upstream | Provider · model, plus a source tag: Platform is a channel from the platform catalog, User is a custom provider or model mapping of the workspace | Shows "No routing candidates" when no candidate was recorded |
| All candidates · N | Candidates sorted by the routing strategy, with the chosen one tagged Selected; appears only when there are more candidates than the hit, and must be expanded | Only the candidate order; Upstream call attempts records the actual calls |
| Upstream call attempts | Every actual attempt: "Attempt N", provider, status code (or "Timeout", "Connection failed", "Network error" and so on when there is no status code), duration, and the reason for moving to the next candidate or for stopping | Appears only when a request made two or more attempts |
| Final result | The status code returned to the client, and the finish reason (such as `stop`) or the failure reason code (such as `upstream_timeout`) | Matches Status in the log list |

Common entries in Upstream call attempts:

- "Continued to attempt 2 after HTTP 503": attempt 1 returned 503, and the gateway moved to the next candidate. Attempts whose connection failed or whose wait timed out have no status code and show "Connection failed", "Timeout" and so on.
- "Stopped: Call succeeded": this attempt succeeded, and the request ended.
- "Stopped: Status is outside the fallback policy": this failure is one of the cases that never switch channels, such as insufficient balance or a guardrail block, and the gateway returned it directly.
- No "Continued to attempt N" after the last attempt: the candidates ran out, and Final result is what the client received.
- "X/Y recorded" next to the title is the number of recorded attempts and the number of actual attempts. When the two differ, the trace shows "Only part of the attempt chain was recorded (X/Y); details may be incomplete."; when it shows "Attempt records are temporarily unavailable. The main request log is unaffected.", reopen the detail later.

(Screenshot: The top of the log detail holds the basic information; Route trace in Overview shows the request received, route selected and final result.)

## Latency breakdown and per-attempt packets

- **Latency breakdown**: when ④ 上游调用 (upstream call) shows "· N attempts, longest X", the request retried the upstream; the time shown is the sum of all attempts, and "longest" is the slowest single attempt. Use it to tell whether time was spent on failed attempts.
- **Raw packets**: when there were several attempts, ② Upstream request and ③ Upstream response are grouped per attempt, titled "<provider> upstream request · Attempt N". To avoid duplicate storage, earlier attempts keep only the request's Target, Method, Content-Type, Body size (bytes) and Body SHA-256, and the complete upstream request is shown only for the last attempt. ③ Upstream response lists every attempt, and overly long content is marked "Recorded content was truncated at its size limit."

## Mapping back to routing settings

| What you see in the log | The corresponding setting |
| --- | --- |
| Routing strategy and the candidate order | For direct model ID calls, the workspace's multi-channel routing strategy in Smart routing; for calls through a virtual model, that virtual model's Channel sort strategy. See [Channels and routing](https://platform.lyrouter.com/ai_gateway/docs/routing/en) and [Virtual models](https://platform.lyrouter.com/ai_gateway/docs/presets/en) |
| One channel always comes first, or only BYOK credentials appear | Prefer this Channel or Only use this BYOK in the BYOK usage settings; see [Channels and routing](https://platform.lyrouter.com/ai_gateway/docs/routing/en#byok-channel-rules) |
| Upstream call attempts switched channels or models | The fallback rules after failure; see [Retries and fallback](https://platform.lyrouter.com/ai_gateway/docs/fallback/en) |
| Model (actual) is the workspace's Default Model | The Default Model fallback in Smart routing |

## FAQ

### All candidates lists several providers. Were they all called?

**Answer:** No. All candidates is only the sorted candidate list; the gateway tries them in order and stops at the first success. Upstream call attempts shows which candidates were actually called; when that part is missing, only the one under Hit upstream was called.

### Why do some logs have no Upstream call attempts?

**Answer:** Requests that called the upstream only once do not show this part. In addition, once a log passes its retention period, its candidate and attempt records are no longer shown, just like its content; see [Retention, exports and deletion](https://platform.lyrouter.com/ai_gateway/docs/retention/en).

### How do I confirm the call used my BYOK credential?

**Answer:** Check whether Route selected contains "BYOK：<name>"; the Provider column in the log list also carries a "BYOK" tag. If the credential was not used, check the BYOK's caller scope and model mappings; see [BYOK](https://platform.lyrouter.com/ai_gateway/docs/byok/en).

### Can I tell from the HTTP status code alone whether an error came from the gateway or the upstream?

**Answer:** That is not recommended. A 503 can mean the gateway found no usable channel, or that the upstream provider returned it. Check Status explanation in the log list: source Gateway means the gateway rejected the request or failed to connect to the upstream, and source Upstream means the provider returned an error; see [Troubleshooting with logs](https://platform.lyrouter.com/ai_gateway/docs/logs/en).

### How can Account Members check routing?

**Answer:** The log detail of an Account Member does not show Route trace, but it does show Model (actual), Provider and Raw packets. To have the routing checked, send the Request ID at the top of the log detail, the call time and the model to the current Account Owner or a workspace Admin.