Routing

Routing controls which model path executes for a request. Olyx evaluates project policy, request shape, security signals, and registered models before recording the decision in traces and governance.

Routing Inputs

Routing decisions can use:

project settings
model registry entries
prompt complexity
PII and secret signals
injection indicators
tool and MCP metadata
configured fallbacks
shadow model settings

The result is recorded on the trace detail page as the selected model, tier, source, and decision rationale.

Tiers

Projects use named tiers to keep routing explainable. The dashboard currently exposes:

Tier	Typical use
`simple`	Low-complexity prompts and low-cost model paths
`medium`	General production requests
`complex`	Higher-reasoning or multi-step work
`secure`	Sensitive prompts, private models, or customer-managed boundaries

Tie each tier to a model identifier registered in the same project.

Guardrail Signals

Guardrails can influence routing before the request executes.

Signal	Routing behavior
PII detected	Route to a safer path, redact, alert, or block depending on policy
Secret detected	Apply the configured secret action
Injection attempt	Block or route to a hardened path depending on policy
Tool risk	Preserve tool-call evidence and select a compatible model path

Fallbacks

Fallbacks are ordered model identifiers used when the primary route is not available or when policy chooses a backup path.

routing_fallbacks:
  - fast-model
  - efficient-model

For private deployments, keep fallback behavior explicit. Do not assume cloud fallback is allowed unless the project boundary permits it.

Policy Simulation

The routing page can simulate a proposed policy against recent traces. Use this before saving a change that may block, reroute, or change model spend.

Simulation answers:

how many requests would be blocked
how many would be rerouted
which sample traces would change
whether a proposed model path is unexpectedly aggressive

Tool And MCP Ingress

Olyx accepts tool-enabled workloads through the same governed path. Tool descriptors are normalized before routing so the trace can show tool calls, tool results, fidelity signals, and model decisions.

{
  "model": "frontier-model",
  "messages": [
    { "role": "user", "content": "Look up invoice inv_123 and summarize it." }
  ],
  "tools": [
    {
      "name": "lookup_invoice",
      "description": "Find an invoice by ID.",
      "inputSchema": {
        "type": "object",
        "properties": {
          "invoice_id": { "type": "string" }
        },
        "required": ["invoice_id"]
      }
    }
  ]
}

Keep tool schemas descriptive and stable. Avoid placing secrets in tool names, descriptions, or metadata.

Operational Workflow

Register the models for the project.
Map each tier to a model identifier.
Add fallback identifiers.
Configure PII, injection, and secret handling.
Run a policy simulation.
Save the project settings.
Generate traces and inspect routing evidence.

Next Steps

Use Model Registry before setting tiers.
Use Traces and Replays to verify routing output.
Use Governance to review the decision chain.