Use Smart Router through Defender or Egress Gateway

Smart Router can be used through Defender Gateway, the existing Cortex Defender connection on a managed endpoint, or through Egress Gateway. Choose the path that receives the request. Gateway forwarding and Smart Router model selection are separate: Egress Gateway can forward a client-selected model without a Smart Router decision.

Choose a connection path

Use through Defender

Use Defender Gateway when the request originates on a managed device that has Cortex Defender installed. This path uses the existing Defender connection, an organization-managed Router, and a qualified client and request path.

Use through Egress Gateway

Use Egress Gateway when an app or AI tool connects to your organization's shared gateway. Cortex Defender does not need to run on that client device. Connect an app or AI tool to Egress Gateway with the organization-issued URL, personal capture token, and a qualified client configuration.

Both paths require managed Router configuration and an eligible client and request path before Smart Router can apply a decision.

How routing works

For an eligible request, Cortex can send the routing prompt to its configured Router. A successful decision includes a label and confidence, with model probabilities when available. Cortex maps the decision to one complexity tier: Easy, Medium, or Hard. The compatible model target depends on the request surface and configuration.

The Router chooses one target for a request. It does not send the request to every candidate model. The target can come from an organization configuration or from the supported surface's compatible default.

Observe decisions before applying them

Routing can operate in observe mode. Cortex records the model it would select while leaving the request unchanged. Where the Router view is available, operators can inspect recommendations before enabling live application.

In apply mode, Cortex can replace the requested model on a supported request. Live routing is disabled by default and requires a configured Router plus an enabled apply setting. A visible Router decision does not by itself show that a request was changed.

Field	Meaning
Requested model	The model named by the client request.
Router selected	The Router's verdict model and complexity tier. This is the routing decision.
Forwarded model	The model Cortex placed in the forwarded request. Where the decision view labels this "Served by," it records the routing target, not proof that the provider returned an answer from that exact model.

A selected model can differ from the forwarded model. In observe mode, the original model is forwarded unchanged. In apply mode, a compatibility or safety check can also leave the original request in place.

Where live routing can apply

Live application is limited to supported request formats and paths. Use only a client and request path your organization has qualified for Smart Router. Generic SDK or curl forwarding, including a Chat Completions request through Egress Gateway, can establish gateway forwarding but does not establish Smart Router eligibility or an Apply outcome.

Coverage also depends on the client, provider, authentication mode, request path, and active configuration. Review AI tools supported by Defender for Defender capture surfaces and Connect an app or AI tool to Egress Gateway for the separate gateway setup.

When Cortex keeps the original request

Cortex fails open for routing. It forwards the original model instead of applying a route when it cannot safely produce a compatible replacement. This includes requests outside the supported paths, unavailable Router configuration, observe mode, an unknown decision tier, an allowlist rejection, an incompatible provider route, a context that exceeds the target model's known window, and an unavailable request-body capacity for the rewrite.

Cortex can reuse a decision within a turn and retain compatible session context while allowing a later request to move to a higher complexity tier. This preserves a consistent route for related requests without treating a prior decision as permanent.

Decision evidence and retention

Where available, the Router view separates selected, skipped, and failed decisions. Its detail view can show the request path, requested model, Router verdict, forwarded model, confidence, routing rule reason, and bounded probability data.

On a device, durable Router history retains selected and failed outcomes. It does not retain skipped deduplication entries, prompt bodies, prompt previews, headers, credentials, or raw Router errors. The local decision view is available only through the protected local status surface.

Gateway forwarding is separate from Smart Router

Egress Gateway has a configured-provider dispatch path. A client sends an explicit model, and Egress Gateway uses the organization's configured provider map to forward the request through an enabled provider configuration.

That dispatch does not evaluate prompt complexity or select a complexity tier. An unpriced model, an unroutable provider entry, or a provider without valid enabled configuration is rejected rather than guessed. A forwarded Egress Gateway request can use a client-selected model without Smart Router.

Related architecture

• Defender Gateway: use Smart Router through the existing Defender endpoint connection.
• Egress Gateway: understand the shared gateway connection path.
• Connect an app or AI tool to Egress Gateway: configure a personal capture token and organization-approved client.
• Defender request flow: how supported Defender traffic reaches the relay and provider.
• Context candidates: how permitted context differs from routing a model request.