Understand routing decisions

In Routed sessions, compare the requested and routed models for captured decisions. Routed is the recorded request target, also called the forwarded model. Inspect recommendations and application state separately in Shadow router.

Inspect a decision

Use an administrator account in the intended organization. Keep the request time, original model, and client path available. After enabling observation, confirm Shadow router contains a matching record for your test request.

1. For an applied decision, open Routed sessions and select Traces. The default Turns view groups sessions; Traces shows individual decisions.
2. For shadow-monitoring records, open Shadow router. Compare its recommendation with the recorded routed model and application state. Check its application state before treating a recommendation as an applied change.
3. Select Filters and narrow the time window, provider, model or decision status. Find the record using the test time and available client context.
4. In Traces, compare Requested and RoutedRequested is the original client model. Routed is the recorded request target. The response-reported model comes only from a captured response. Reference. Use Search decisions and Filters to find the captured prompt and client context. Recommended belongs to the separate Shadow router view; a complexity tier by itself is not a model ID.
5. Review savings, confidence and routing latency on the trace. In Shadow router, inspect the recorded status, application state and routing reason. An unapplied recommendation does not prove that the request was rewritten.
6. Open the linked exchange only when the record supplies one. Compare its response-reported model separately. Without captured response evidence, leave that value unknown.

Turns groups sessions. Traces opens individual applied decision records. Shadow router includes recommendations that were not applied. Check model availability in your organization before sending a request.

Review routed sessions

• Observed shows available captured prompt text. It does not establish the session goal or an observed outcome.
• Context identifies the member and client. Decisions and Savings summarize available routing records for the session.
• Read pricing coverage alongside savings. Missing prices do not mean zero cost.
• Select Traces to inspect requested and routed models for an individual applied decision. Inspect recommendations in Shadow router. A response-reported model requires a captured exchange; keep it unknown without that evidence.

Check the result

• In Traces, read the requested and routed values. In Shadow router, also read the recommendation and application state.
• If a recommendation was not applied, preserve that distinction even when it appears cheaper.
• Routing decision latency measures routing work, not provider generation time.
• no change means the priced comparison has no positive savings. not priced means prices or usage data are missing; it does not mean zero cost.
• Use a captured response to identify its reported model only when that evidence is available.
• Do not use a selected tier, recommended model or savings estimate as proof of forwarding.
• See Smart Router for the distinction between requested, selected, forwarded and response-reported models.

Troubleshooting

Routing reference

• Provider selection explains organization-managed mapping and credentials; the native request example preserves the supported request shape.

• Provider and model fallbacks distinguishes preserving the original request from application-owned retries.

• Performance preferences and caching separates routing-decision caching from provider prompt caching.

• Policy constraints explains replacement-target limits and refusing disallowed models.