17 Routing Strategies in OmniRoute: Complete Guide to Model Selection and Fusion

OmniRoute defines 17 distinct routing strategies—from priority and round-robin to cost-optimized and lkgp—in src/shared/constants/routingStrategies.ts, while the fusion strategy uniquely orchestrates multiple models by fanning out requests to a parallel panel, extracting their answers, and synthesizing a final response through a designated judge model.

The open-source OmniRoute project (diegosouzapw/OmniRoute) provides a flexible routing layer for AI model endpoints. Understanding the 17 routing strategies in OmniRoute is essential for optimizing latency, cost, and output quality when building multi-model applications.

The Complete Catalogue of Routing Strategies

The canonical list of strategies lives in src/shared/constants/routingStrategies.ts, exported as the arrays ROUTING_STRATEGY_VALUES and ROUTING_STRATEGIES. These determine how a combo (a group of model endpoints) selects the concrete model that will handle a request.

While most strategies pick a single model per request, the catalogue includes specialized multi-model orchestrators. The complete list includes:

• Basic Selection: priority (fixed order), weighted (probabilistic), random, strict-random (random with health validation), and round-robin (cyclic).
• Load & Capacity: least-used (fewest calls), headroom (sufficient capacity), p2c (power-of-two-choices, selecting the less loaded of two random picks), and fill-first (quota-based pooling).
• Cost & Context: cost-optimized (cheapest valid model), context-relay (routes by context window size), and context-optimized (best fit for current context size).
• Temporal & Reset-Aware: reset-aware (considers model reset windows), reset-window (focuses on reset timeframe), and auto (runtime metric-based selection).
• Historical Quality: lkgp (least-known-good-probability, favoring models with historically good outcomes).
• Multi-Model Orchestration: fusion (parallel panel + judge synthesis) and pipeline (sequential chaining).

How the Fusion Strategy Works with Multiple Models

Unlike single-model selectors, the fusion strategy explicitly involves multiple models working together. Implemented in open-sse/services/fusion.ts, the fusion flow follows three distinct phases:

Phase 1: Parallel Panel Fan-Out

The strategy first fans out the prompt to every model in the panel in parallel. All panel calls are forced non-streaming (stream: false) and have tools stripped to ensure the judge receives full prose answers.

const panelBody: Body = { ...rest, stream: false };
const calls = panel.map(m => withTimeout(handleSingleModel(panelBody, m), cfg.panelHardTimeoutMs));
const settled = await collectPanel(calls, { ...cfg, minPanel });

The collectPanel helper implements quorum-grace logic: once minPanel successful responses arrive, a grace timer (stragglerGraceMs) starts. The combo proceeds when the timer expires or when all calls settle, bounded by panelHardTimeoutMs.

Phase 2: Answer Extraction and Aggregation

Each successful response is parsed and processed through extractPanelText to obtain plain text, supporting OpenAI, Claude, Gemini, and OpenAI Responses formats.

// Extracted snippets collected as:
const answers: Array<{model: string; text: string}> = /* ... */;

If no panel model answers, the combo returns an HTTP 503 error. If exactly one model answers, that answer is returned directly, bypassing the judge entirely.

Phase 3: Judge Synthesis

The judge model—either a user-specified judgeModel or the first panel model by default—receives a specialized request. The function appendUserTurn constructs a new conversation that appends the original messages with a user turn containing a judge prompt. This prompt presents the anonymized panel answers and instructs the judge to produce one authoritative synthesis.

const judgeRequest = appendUserTurn(originalMessages, judgePromptText);
const finalResponse = await handleSingleModel(judgeRequest, judgeModel);

The judge’s response is streamed back to the client unchanged (respecting the original stream flag), ensuring downstream tooling like function calling continues to work.

Configuring Fusion Combos

Fusion behavior is controlled through optional configuration fields defined in the combo schema (src/shared/validation/schemas/combo.ts).

Field	Description	Default
judgeModel	Model ID acting as the judge	First panel model
fusionTuning.minPanel	Minimum successful responses before grace timer	2
fusionTuning.stragglerGraceMs	Grace period after quorum (ms)	8000
fusionTuning.panelHardTimeoutMs	Hard timeout for panel fan-out (ms)	90000

These defaults are exported as FUSION_DEFAULTS in open-sse/services/fusion.ts.

Example fusion combo definition:

{
  "name": "my-fusion-combo",
  "strategy": "fusion",
  "config": {
    "judgeModel": "openai/gpt-4o-mini",
    "fusionTuning": {
      "minPanel": 3,
      "stragglerGraceMs": 5000,
      "panelHardTimeoutMs": 60000
    }
  },
  "models": ["openai/gpt-4o", "anthropic/claude-3.5-sonnet", "google/gemini-pro"]
}

API invocation:

curl -X POST https://router.example.com/api/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "my-fusion-combo",
    "messages": [{"role":"user","content":"Explain the difference between REST and GraphQL"}],
    "stream": false
  }'

The request is routed through open-sse/handlers/chatCore.ts, which invokes handleFusionChat to execute the three-phase logic.

Key Implementation Files

File	Purpose
src/shared/constants/routingStrategies.ts	Defines ROUTING_STRATEGY_VALUES and the complete strategy catalogue
open-sse/services/fusion.ts	Implements panel fan-out, collectPanel quorum logic, and judge synthesis
src/shared/validation/schemas/combo.ts	Zod schema validating judgeModel and fusionTuning configuration
tests/unit/combo-fusion-strategy.test.ts	Unit tests for single-model fast-path, quorum handling, and error cases

Summary

• OmniRoute provides 17 distinct routing strategies for single-model selection, covering priority, load balancing, cost optimization, and contextual routing.
• The fusion strategy is the only method that orchestrates multiple models simultaneously through a panel-and-judge architecture.
• Fusion execution relies on three phases: parallel fan-out with quorum-grace (collectPanel), answer extraction (extractPanelText), and judge synthesis (appendUserTurn).
• Configuration via fusionTuning allows precise control over latency and reliability through minPanel, stragglerGraceMs, and panelHardTimeoutMs parameters.

Frequently Asked Questions

What is the difference between the fusion and pipeline strategies?

The fusion strategy runs models in parallel and synthesizes their outputs through a judge, while the pipeline strategy chains models sequentially, where the output of one model becomes the input to the next. Fusion is designed for consensus and quality improvement, whereas pipeline is designed for multi-step processing.

How does the fusion strategy handle timeouts?

The fusion strategy uses a two-tier timeout system. The panelHardTimeoutMs sets an absolute ceiling for the entire panel fan-out, while stragglerGraceMs provides a grace period after minPanel responses have arrived. Once the grace period expires or the hard timeout hits, the combo proceeds with whatever answers have been collected.

Can I specify a custom model to act as the judge?

Yes. By setting the judgeModel field in the combo configuration, you can designate any available model to perform the synthesis. If omitted, the system defaults to the first model listed in the panel.

Where are the routing strategy constants defined?

All routing strategy identifiers are defined in src/shared/constants/routingStrategies.ts and exported as ROUTING_STRATEGY_VALUES and ROUTING_STRATEGIES. This file serves as the single source of truth for valid strategy names across the OmniRoute codebase.

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