The 19 Routing Strategies for Configuring Model Combos in OmniRoute: Complete Reference

OmniRoute provides 19 distinct routing strategies—including Priority, Weighted, Fusion, and Pipeline—that determine how requests are distributed across multiple LLM providers in a single combo configuration.

OmniRoute's combo routing system enables a single API request to be dispatched across multiple provider models according to selectable routing logic. The framework defines these 19 public strategies in [src/shared/validation/schemas/combo.ts](https://github.com/diegosouzapw/OmniRoute/blob/release/v3.8.50/src/shared/validation/schemas/combo.ts) and documents them in [docs/routing/AUTO-COMBO.md](https://github.com/diegosouzapw/OmniRoute/blob/release/v3.8.50/docs/routing/AUTO-COMBO.md). These strategies govern everything from simple failover to complex multi-model orchestration, allowing precise control over cost, latency, and reliability.

Complete List of Routing Strategies

The dispatcher in [open-sse/services/combo.ts](https://github.com/diegosouzapw/OmniRoute/blob/release/v3.8.50/open-sse/services/combo.ts) implements all 19 strategies, which can be grouped into five functional categories.

Failover and Sequential Strategies

• priority: Targets are ordered by explicit priority; the first healthy target is used. This is the default strategy when comboStrategy is omitted (set at line 325 of combo.ts). Ideal for simple fallback chains where a preferred provider is tried first.

• fill-first: Fills one target to its token or response limit before moving to the next target. Maximizes utilization of a single model when quota is abundant.

Load Balancing and Distribution

• weighted: Each target receives a numeric weight; traffic is split proportionally. Use this to distribute load across providers while giving more capacity to cheaper or faster models.

• round-robin: Cycles through targets in order, sending one request to each before repeating. Provides even distribution across a pool of identical models.

• random: Chooses a target uniformly at random. Suitable when no specific performance metric is available and simple distribution is required.

• p2c (power-of-two-choices): Randomly picks two targets and selects the one with lower load. Reduces contention while maintaining load-balancing benefits.

• least-used: Selects the target with the smallest cumulative usage count. Favors under-utilized providers to avoid hot-spots.

Cost and Performance Optimization

• cost-optimized: Ranks targets by cost-per-token and prefers the cheapest option. Minimizes monetary spend while meeting latency constraints.

• headroom: Chooses targets with the most remaining token headroom. Prevents early exhaustion of token limits on any single provider.

• lkgp (least-known-good-performance): Picks the target with the best historic performance for the specific requested model. Leverages historical latency and throughput data.

• context-optimized: Prioritizes targets that have sufficient context-window size for the request. Essential for large-prompt or multi-turn conversations.

• cache-optimized: Prefers targets that maintain a warm cache for the model or recent similar requests. Reduces latency by hitting cached inference.

Resilience and Rate Limit Handling

• reset-aware: Avoids targets that have recently hit a reset window (e.g., rate-limit reset). Preserves stability after throttling events.

• reset-window: Groups targets by shared reset windows and prefers those with the longest remaining window. Provides fine-grained control when multiple accounts share a common reset schedule.

• strict-random: Random selection that excludes any target currently in cooldown or error state. Guarantees that only healthy targets receive traffic.

Advanced Multi-Model Orchestration

• fusion: Fans out the request to a panel of models in parallel, then a designated judge model synthesizes a final answer. Implementation lives in [open-sse/services/fusion.ts](https://github.com/diegosouzapw/OmniRoute/blob/release/v3.8.50/open-sse/services/fusion.ts). Use this for ensemble-style responses that blend multiple model opinions.

• pipeline: Chains multiple models sequentially, where the output of one model becomes the input of the next. Processed in [open-sse/services/pipeline.ts](https://github.com/diegosouzapw/OmniRoute/blob/release/v3.8.50/open-sse/services/pipeline.ts). Build complex workflows like "generate → summarize → translate" within a single API call.

• context-relay: Sends the request to a single primary provider but forwards the conversation history to a secondary "relay" model for augmentation. Combines a fast generative model with enrichment from a secondary source.

• auto: Dynamically selects the best strategy based on current telemetry including latency, cost, and error rates. Provides adaptive routing that self-optimizes over time.

Configuring Routing Strategies in Practice

Set the strategy field in your combo definition JSON when calling the Create Combo endpoint (POST /v1/combos) or via the admin UI. Below are implementations for the four most requested strategies.

Priority Strategy (Failover)

const priorityCombo = {
  name: "priority-openai-anthropic",
  strategy: "priority",
  models: ["openai/gpt-4o", "anthropic/claude-3.5-sonnet"],
};

Weighted Strategy (Proportional Load)

const weightedCombo = {
  name: "weighted-openai-gemini",
  strategy: "weighted",
  models: [
    { id: "openai/gpt-4o", weight: 70 },
    { id: "google/gemini-1.5-flash", weight: 30 },
  ],
};

Fusion Strategy (Panel with Judge)

const fusionCombo = {
  name: "fusion-panel",
  strategy: "fusion",
  models: [
    "openai/gpt-4o",
    "anthropic/claude-3.5-sonnet",
    "google/gemini-1.5-flash",
  ],
  config: { judgeModel: "openai/gpt-4o" }, // Optional; defaults to first panelist
};

Pipeline Strategy (Sequential Chaining)

const pipelineCombo = {
  name: "pipeline-gen-summ-trans",
  strategy: "pipeline",
  models: [
    "openai/gpt-4o",           // Step 1: Generate
    "openai/gpt-4o-mini",      // Step 2: Summarize
    "google/gemini-1.5-flash", // Step 3: Translate
  ],
  config: {
    steps: [
      { maxTokens: 1024 },
      { temperature: 0.2 },
      { targetLanguage: "es" },
    ],
  },
};

Implementation Architecture

The routing logic resides in three core service files. The combo.ts dispatcher maps incoming requests to the selected strategy implementation. For fusion and pipeline, dedicated service modules in fusion.ts and pipeline.ts handle the complex multi-model orchestration beyond simple load-balancing.

All strategies interact with OmniRoute's resilience layers, including provider circuit-breakers, connection cooldowns, and model lockouts. Targets in cooldown are automatically excluded from strategies requiring healthy targets (such as strict-random). The validation schema in src/shared/validation/schemas/combo.ts enforces strategy names and defaults to priority when the field is omitted.

Summary

• 19 routing strategies are available for configuring model combos in OmniRoute, ranging from simple failover to complex multi-model orchestration.
• Priority is the default strategy, defined at line 325 of src/shared/validation/schemas/combo.ts, and requires no explicit configuration for basic fallback behavior.
• Fusion and Pipeline are the only strategies with dedicated service modules (fusion.ts and pipeline.ts) providing parallel panel judging and sequential chaining respectively.
• Weighted and Round-robin strategies distribute traffic across providers, while Cost-optimized and LKGP strategies make intelligent selections based on price and historical performance.
• All strategies respect the resilience layer, automatically excluding unhealthy targets from selection pools.

Frequently Asked Questions

What is the default routing strategy if none is specified?

Priority is the default strategy. According to the source code in src/shared/validation/schemas/combo.ts at line 325, when comboStrategy is omitted from the combo definition, the system automatically applies the priority strategy, which attempts targets in the order listed and uses the first healthy provider.

How does the Fusion strategy differ from the Pipeline strategy?

Fusion sends requests to multiple models simultaneously and uses a judge model to synthesize a final answer, effectively creating an ensemble. Pipeline processes models sequentially, passing the output of one model as input to the next. Fusion is implemented in open-sse/services/fusion.ts while Pipeline logic resides in open-sse/services/pipeline.ts.

When should I use Weighted instead of Round-robin?

Use Weighted when you need proportional traffic distribution based on model capabilities, pricing tiers, or quota limits. Use Round-robin when all targets are identical in capacity and cost, and you require perfectly even request distribution without complex configuration.

What makes the Auto strategy adaptive?

The Auto strategy continuously evaluates current telemetry—including latency percentiles, error rates, and token costs—to dynamically select the optimal routing strategy for each request. Unlike static strategies, it self-optimizes over time without manual tuning of weights or priorities.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}