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

> Discover OmniRoute's 19 Auto-Combo routing strategies. This guide details how to implement these LLM request distribution methods for optimal provider pool management and advanced orchestration.

- Repository: [Diego Rodrigues de Sa e Souza/OmniRoute](https://github.com/diegosouzapw/OmniRoute)
- Tags: how-to-guide
- Published: 2026-08-19

---

**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`](https://github.com/diegosouzapw/OmniRoute/blob/main/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`](https://github.com/diegosouzapw/OmniRoute/blob/main/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.

```typescript
// 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`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/autoCombo/engine.ts)). This implementation applies a **13-factor scoring function** defined in [`open-sse/services/autoCombo/scoring.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/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`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/autoCombo/modePacks.ts) to adjust weights for presets like `fast`, `quality`, `cheap`, `reliable`, and `offline`.

```typescript
// 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`](https://github.com/diegosouzapw/OmniRoute/blob/main/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.

```typescript
// 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`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/autoCombo/pipelineRouter.ts), this strategy iteratively calls `handleSingleModel` for each defined stage, enabling workflows like preprocessing → generation → validation.

```typescript
// 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`](https://github.com/diegosouzapw/OmniRoute/blob/main/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`](https://github.com/diegosouzapw/OmniRoute/blob/main/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`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/fusion.ts) while Pipeline runs through [`open-sse/services/autoCombo/pipelineRouter.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/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.