Smart Router
Choose a Defender or Egress connection path, then use a fixed model or Auto Router, a Smart Router mode.
Gateway routing decision example: compare the client request with the recorded recommendation, forwarded model and captured provider response.
Choose a connection path
- Defender Gateway: use the endpoint setup on a managed device, with qualified client/request paths and organization-managed routing.
- Egress Gateway: use the shared gateway without Defender on the client device. Verify forwarding, then confirm routing eligibility with your Cortex team.
Defender Gateway
- Set up Defender on the device sending the request.
- Ask your administrator for the supported client, request path, authentication mode and managed Smart Router configuration. Defender setup alone does not qualify a request for routing.
- Use a fixed model or Auto Router on that approved path. To keep an explicit model unchanged, managed routing must leave it unchanged, such as observe mode or apply disabled. An explicit model alone does not bypass Auto Router on a qualified apply path.
Then verify sync.
Choose a model selection mode
Fixed selection keeps an explicit model unchanged when routing is not applied. Auto Router is a Smart Router mode that maps task complexity to one compatible target; it does not fan out to all candidates.
Gateway forwarding and Smart Router
Gateway forwarding resolves the requested model through the organization pricing sheet and requires an enabled provider. It is separate from Auto Router. There is no built-in cortex/auto alias; a request routing object does not enable it.
Auto Router
Available through qualified Defender Gateway and Egress Gateway paths with managed configuration. Generic OpenAI Chat Completions and Anthropic SDK requests demonstrate forwarding, not activation.
Get started
- Agree a qualified client/request path with your Cortex team, such as Codex Responses.
- Have an administrator enable managed routing and configure compatible Easy, Medium and Hard targets.
- Send an explicit organization-enabled model. Check the mode and decision evidence before treating a recommendation as applied.
Example request
Keep the accepted Codex configuration, including wire_api = "responses" and the capture header. The native request retains its explicit model.
{
"model": "<organization-enabled-model>",
"input": "Summarize this support incident and propose the next action."
}The body alone does not activate Auto Router; managed settings and client/request eligibility determine it.
How Auto Router chooses
The classifier assesses complexity as Easy, Medium or Hard. Configuration maps that tier to one target, then compatibility and replacement restrictions determine whether it can apply. Managed settings supply compatible candidates; request-level candidate/provider/objective fields do not define the choice. Routing compatibility covers application-owned multi-request workflows.
Configure a route
Ask your Cortex admin to enable routing for the agreed client and choose compatible tier targets. Restrictions apply to replacements; an incompatible/disallowed replacement can preserve the original model. Use access rules to restrict original request admission.
Current routing behavior
In observe mode, the request keeps its original model. Inspect Shadow router for recommendations. Setting observe mode alone does not establish that a recommendation was recorded; find the matching test record.
In apply mode, Smart Router can replace the model on supported paths. If it cannot apply a compatible replacement, it forwards the original request. A recommendation can differ from the forwarded model. Neither mode retries a failure through another provider.
Sessions, continuity, and context
Usable turn/session identity can retain a prior target for repeated turns or small prefix additions. Classification remains independent; higher complexity can escalate the target. Large additions, compaction, expired state or incompatibility can change it. This is not universal session pinning or a context-fit guarantee.
Inspect decisions and evaluate
| Value | Meaning |
|---|---|
| Requested model | Explicit client model. |
| Selected model | Recommended target, when available; a tier alone does not establish it. |
| Forwarded model | Recorded target shown as Routed. |
| Response-reported model | Model ID in the captured provider response, when available. |
| Outcome and reason | Recorded application state and explanation. |
Read Shadow router recommendations separately from applied Traces in routing decisions. Check the provider response to verify its reported model, and Atlas delivery separately.
Compare with a fixed-model baseline for the same workload. Record sample/time window, quality measure, available cost, latency and failure policy before claiming improvement.