The 19 Auto-Combo Routing Strategies in OmniRoute: Complete Implementation Guide

OmniRoute provides 19 configurable Auto-Combo routing strategies that determine how LLM requests are distributed across provider pools, ranging from simple priority selection to intelligent multi-model fusion and pipeline orchestration.

The Auto-Combo engine in diegosouzapw/OmniRoute serves as the central request router for multi-provider LLM workloads. Each strategy defined in open-sse/services/combo.ts implements a specific selection algorithm that evaluates provider health, quota status, cost constraints, and contextual relevance to route requests optimally.

How the Core Router Dispatches Strategies

The main entry point for all routing decisions is the combo.ts service. When a request arrives with a ComboConfig specifying a strategy, the router executes a large switch statement to delegate execution to the appropriate handler.

// Conceptual usage in ComboConfig
const config: ComboConfig = {
  strategy: 'auto', // or 'fusion', 'priority', etc.
  providers: ['openai/gpt-4', 'anthropic/claude-3'],
  modePack: 'quality' // optional bias for auto strategy
};

For most single-provider selection strategies, logic remains inline within the switch cases. Complex strategies like fusion, pipeline, and auto delegate to dedicated modules to handle multi-stage processing.

Category 1: Basic Selection Strategies

These six strategies implement fundamental load distribution patterns without external dependencies.

Priority Routing

The priority strategy selects the first healthy provider in the candidate list. This deterministic approach ensures predictable failover chains where provider order reflects business preference or capability tiers.

Weighted Distribution

The weighted strategy uses a weight field defined on each connection to bias selection probability. Higher weights increase selection frequency proportionally across the pool.

Round-Robin Cycling

The round-robin strategy maintains session-aware counters to cycle through providers on successive requests. This balances load evenly across homogeneous provider pools.

Random Selection

Two variants exist: random performs pure random selection from healthy candidates, while strict-random adds hard constraints requiring providers to meet minimum health and quota thresholds before inclusion in the selection pool.

Power-of-Two-Choices (P2C)

The p2c strategy randomly samples two providers and selects the one with superior health metrics or available quota. This algorithm provides better load balancing than pure random selection without the overhead of global state tracking.

Category 2: Quota and Capacity Management

These strategies optimize for provider rate limits and throughput constraints.

Fill-First

The fill-first strategy exhausts the first provider's quota before moving to subsequent candidates. This maximizes utilization of preferred providers before falling back to alternatives.

Least-Used

The least-used strategy tracks request counts per provider and routes to the candidate with the lowest historical usage. This prevents over-utilization of fast responders that might otherwise dominate traffic.

Headroom Optimization

The headroom strategy selects the provider with the most remaining quota headroom relative to its limits. This prevents premature exhaustion of providers with small windows while distributing load across high-capacity targets.

Reset-Aware and Reset-Window

Two complementary strategies handle quota reset timing. Reset-aware prioritizes providers whose quota-reset windows are about to open, while reset-window enforces strict scheduling based on the provider's defined reset timetable.

Category 3: Cost and Context Optimization

These strategies incorporate financial and semantic factors into routing decisions.

Cost-Optimized

The cost-optimized strategy queries provider pricing metadata and selects the lowest-cost option that satisfies per-request budget constraints defined in the configuration.

Context-Optimized

The context-optimized strategy scores candidates based on semantic alignment with the request context, including tool usage requirements, vision capabilities, and specialized model features.

Cache-Optimized

The cache-optimized strategy checks for cached responses across the provider pool and routes to providers that already possess computed results for identical prompts, reducing latency and token costs.

Context-Relay

The context-relay strategy sends request context as part of the prompt to multiple providers, then selects the optimal response based on quality heuristics.

Category 4: Advanced Intelligent Routing

These strategies implement sophisticated selection algorithms and stateful routing.

Last-Known-Good-Provider (LKGP)

The lkgp strategy maintains session state to reuse the provider that succeeded on the previous request, only falling back to alternative selection when the preferred provider becomes unhealthy.

Auto Strategy

The auto strategy delegates candidate evaluation to the Auto-Combo engine (open-sse/services/autoCombo/engine.ts). This implementation applies a 13-factor scoring function defined in open-sse/services/autoCombo/scoring.ts, evaluating:

• Provider health status
• Remaining quota ratios
• Latency percentiles
• Cost per token
• Context compatibility

The engine applies mode-pack biases from open-sse/services/autoCombo/modePacks.ts to adjust weights for presets like fast, quality, cheap, reliable, and offline.

// Auto strategy with mode pack
const autoConfig: ComboConfig = {
  strategy: 'auto',
  modePack: 'quality', // Biases toward high-performance providers
  providers: ['gpt-4', 'claude-3-opus', 'gemini-pro']
};

Category 5: Multi-Provider Orchestration

These final two strategies break the single-provider model to execute complex workflows across multiple models.

Fusion

The fusion strategy implements a panel-judge pattern defined in open-sse/services/fusion.ts. It fans out requests to a panel of models in parallel, then invokes a designated fusionJudgeModel to synthesize the final answer from multiple responses.

// Fusion configuration
const fusionConfig: ComboConfig = {
  strategy: 'fusion',
  panel: ['gpt-3.5-turbo', 'claude-3-haiku', 'gemini-flash'],
  fusionJudgeModel: 'gpt-4o'
};

Pipeline

The pipeline strategy chains multiple providers sequentially, where each stage's output feeds into the next stage's input. Implemented in open-sse/services/autoCombo/pipelineRouter.ts, this strategy iteratively calls handleSingleModel for each defined stage, enabling workflows like preprocessing → generation → validation.

// Pipeline configuration
const pipelineConfig: ComboConfig = {
  strategy: 'pipeline',
  stages: [
    { provider: 'gpt-3.5-turbo', task: 'summarize' },
    { provider: 'claude-3-sonnet', task: 'analyze' },
    { provider: 'gpt-4', task: 'finalize' }
  ]
};

Summary

• OmniRoute implements 19 distinct routing strategies in open-sse/services/combo.ts, controlled via the strategy field in ComboConfig.
• Simple strategies (priority, weighted, round-robin, random, p2c) handle basic provider selection with minimal overhead.
• Quota-aware strategies (fill-first, headroom, reset-aware, reset-window) optimize for rate limit constraints and capacity planning.
• Context strategies (context-optimized, cache-optimized, context-relay) route based on semantic requirements and cached state.
• Advanced routing (auto, lkgp) uses the Auto-Combo engine with 13-factor scoring and session persistence.
• Orchestration strategies (fusion, pipeline) enable parallel panel processing and sequential chaining through dedicated modules.

Frequently Asked Questions

How do I configure the Auto-Combo strategy for maximum response quality?

Set strategy: 'auto' and specify modePack: 'quality' in your ComboConfig. This biases the scoring function in open-sse/services/autoCombo/scoring.ts to weight latency and reliability factors higher than cost, preferring high-performance providers like GPT-4 or Claude 3 Opus even at higher token prices.

What is the difference between the fusion and pipeline strategies?

Fusion routes requests to multiple providers simultaneously and synthesizes responses using a judge model, ideal for consensus-based answers. Pipeline chains providers sequentially where each stage feeds the next, suitable for multi-step workflows like preprocessing raw inputs or iterative refinement. Fusion executes in open-sse/services/fusion.ts while Pipeline runs through open-sse/services/autoCombo/pipelineRouter.ts.

Which strategy should I use to minimize costs across multiple providers?

Use the cost-optimized strategy for simple cost-based selection, or auto with modePack: 'cheap' for intelligent balancing that considers both price and performance. The cost-optimized strategy strictly selects the lowest-cost healthy provider, while the auto strategy with cheap mode avoids expensive providers unless no alternatives meet quality thresholds.

How does the Power-of-Two-Choices (P2C) strategy improve load balancing?

The p2c strategy reduces the variance of load distribution compared to pure random selection by sampling two candidates and selecting the healthier option. This prevents the "thundering herd" problem where truly random selection might overload a single fast provider, while avoiding the complexity of global state required by least-used or headroom strategies.

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