Routing Configuration UI

The Routing section of the MultiRoute dashboard lets you configure how requests to the /v1 API are distributed across models and providers, without changing your application code.

Conceptually, it is a human-friendly layer on top of the same configuration that the /v1/config API exposes.

Routing Profiles and Rules

Routing is typically organized into profiles or rulesets. Each profile describes how to handle a class of requests, such as:

• “Default chat completions”
• “High-accuracy reasoning”
• “Low-latency responses for UI”

Within each profile you can define:

• Target models: Which models are eligible to receive traffic.
• Weights or priorities: How traffic should be distributed across models.
• Fallback behavior: What to do when a provider or model is unavailable or failing.

Your application then references these profiles via configuration or by selecting the appropriate model or routing key when calling /v1 endpoints.

Managing Model Priorities

For each routing profile, the UI allows you to:

• Choose a primary model: The first-choice model for normal operation.
• Set secondary models: Ordered or weighted fallbacks that can receive traffic when needed.
• Adjust weights: For example, send 80% of traffic to one model and 20% to another for canarying or A/B testing.

Changes are applied at the configuration level, so you can:

• Shift traffic gradually between models.
• Test new models with a small percentage of traffic.
• Roll back to a known-good configuration if issues arise.

Timeouts, Retries, and Failover

The UI exposes high-level controls for reliability behavior, such as:

• Request timeouts: How long MultiRoute should wait for a provider before treating it as failed.
• Retry policies: Whether and how often to retry on specific error types (e.g. network errors vs. validation errors).
• Failover settings: When to send the request to an alternate model or provider.

The intent is to give you sensible defaults out of the box, while still allowing fine-grained tuning for latency-sensitive or mission-critical workloads.

Drafting and Reviewing Changes

Routing changes often affect production traffic, so the dashboard is designed to support a safe workflow:

• Edit in draft: Make changes to profiles and rules without immediately affecting live traffic.
• Preview impact: See which models and providers will receive traffic under the new configuration.
• Review and confirm: Optionally require a second approval before applying changes (in progress).
• Apply changes: Promote the draft to active configuration for the selected project or environment.

This workflow is especially helpful when multiple teams collaborate on routing policies.

Relationship to the /v1/config API

All routing configuration managed in the UI is stored in the same configuration layer that the /v1/config API reads and writes.

This means you can:

• Use the API for automation (CI/CD, infrastructure-as-code).
• Use the UI for inspection, quick edits, and debugging.

The recommended pattern is:

• Source-of-truth in version-controlled configuration via /v1/config for production-critical setups.
• Use the dashboard UI to visualize, verify, and occasionally adjust routing behavior, especially during incident response or experiments.