# OmniRoute's 19 Combo Routing Strategies: Complete Guide with Use Cases

> Explore OmniRoute's 19 combo routing strategies. This guide details each strategy, its use cases, and implementation in open-sse/services/combo.ts for optimal routing.

- Repository: [Diego Rodrigues de Sa e Souza/OmniRoute](https://github.com/diegosouzapw/OmniRoute)
- Tags: deep-dive
- Published: 2026-08-24

---

**OmniRoute provides 19 distinct `RouterStrategy` options in its Auto-Combo engine, ranging from simple priority selection to advanced multi-model fusion and pipeline chaining, each defined in [`open-sse/services/combo.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/combo.ts) with specialized implementations for complex logic.**

This guide breaks down every routing strategy in the [diegosouzapw/OmniRoute](https://github.com/diegosouzapw/OmniRoute) repository, explains when to use each, and maps them to their actual source code locations. Whether you're optimizing for cost, latency, quality, or reliability, understanding these 19 combo routing strategies lets you configure `ComboConfig.strategy` precisely for your workload.

---

## How Strategies Are Implemented

OmniRoute's combo router lives in [`open-sse/services/combo.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/combo.ts). It receives a `ComboConfig` object with a `strategy` field, then dispatches to the appropriate handler via a large `switch` statement.

```typescript
// Conceptual structure from open-sse/services/combo.ts
function router(candidates: ProviderCandidate[], config: ComboConfig): ProviderCandidate {
  switch (config.strategy) {
    case 'priority':      // Strategy 1
    case 'weighted':      // Strategy 2
    // ... 17 more cases
    case 'pipeline':      // Strategy 19
    default:
      throw new Error(`Unknown strategy: ${config.strategy}`);
  }
}

```

Some strategies handle logic inline; complex ones delegate to dedicated modules like [`fusion.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/fusion.ts) or [`pipelineRouter.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/pipelineRouter.ts).

---

## Simple Selection Strategies (1–7)

These seven strategies provide deterministic or stochastic selection without complex scoring.

### priority

**Use when:** You have a clear preference order and want failover behavior.

Picks the first **healthy** provider in the candidate list order. Implementation is a linear scan in [`open-sse/services/combo.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/combo.ts) for the first provider passing health checks.

```typescript
// Configuration example
const config: ComboConfig = {
  strategy: 'priority',
  providers: ['gpt-4', 'claude-3', 'gemini-pro']  // tried in this order
};

```

### weighted

**Use when:** Providers have different capacity limits or you want proportional traffic splitting.

Chooses according to the `weight` field on each connection. Weights are normalized to probabilities; higher weights receive proportionally more traffic.

### fill-first

**Use when:** Maximizing quota utilization on primary providers before engaging backups.

Fills the first provider's quota completely before moving to the next. Tracks remaining quota per provider and only advances when current is exhausted.

### round-robin

**Use when:** Even distribution across equally-capable providers with session-stickiness needs.

Cycles through providers on successive requests. Maintains state to track position in the rotation; supports session affinity so repeat requests from same context hit the same provider.

### p2c (Power-of-Two-Choices)

**Use when:** You want better load balancing than pure random without the overhead of perfect least-loaded tracking.

Randomly samples **two** providers, picks the one with better health/quota metrics. Avoids the "herd behavior" problem of naive least-loaded selection.

### random

**Use when:** Simple, stateless distribution across healthy providers with no preference.

Pure random selection filtered to healthy providers only. Lowest overhead, no state maintenance.

### least-used

**Use when:** Short-term fairness matters and you can track per-provider request counts.

Selects the provider with the fewest handled requests in the current window. Resets on interval or can use decay algorithms.

---

## Quota-Aware Strategies (8–12)

These five strategies incorporate provider-specific constraints like cost, reset windows, and remaining capacity.

### cost-optimized

**Use when:** Operating under tight budget constraints with acceptable quality trade-offs.

Prefers lowest-cost provider while respecting per-request budget ceilings. Looks up cost metadata on each candidate and filters by `maxCost` before selecting minimum.

### reset-aware

**Use when:** Providers have hard quota windows (hourly/daily) and you want to exploit timing.

Gives priority to providers whose quota-reset window is **imminent**. Calculates time-until-reset for each candidate and boosts score for near-term reset openings.

### reset-window

**Use when:** Strict adherence to provider availability schedules is required.

Enforces the provider's reset-window schedule as a **hard constraint**. Only selects providers currently within their active window, regardless of other merits.

### headroom

**Use when:** Avoiding quota exhaustion is critical for reliability.

Chooses the provider with the **most remaining quota headroom** (absolute or percentage). Protects against cascading failures from quota depletion.

### strict-random

**Use when:** Random selection must satisfy multiple hard constraints (health + quota + window).

Random selection that respects a **strict** combined constraint set: healthy, quota-available, and window-active. Falls back to lower tiers only if no candidates satisfy all constraints.

---

## Intelligent Selection Strategies (13–17)

These five strategies use request context, history, or scoring engines for smarter routing.

### auto

**Use when:** You want optimal provider selection without manual tuning for each request type.

Hands candidates to the **Auto-Combo engine** ([`open-sse/services/autoCombo/engine.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/autoCombo/engine.ts)), which scores each with a 13-factor (or 14-factor) function. Factors include latency history, error rate, cost, context match, and more.

```typescript
// Mode packs bias the scoring
const config: ComboConfig = {
  strategy: 'auto',
  mode: 'fast'      // 'fast' | 'balanced' | 'quality' | 'cheap' | 'reliable' | 'offline'
};

```

Mode packs defined in [`open-sse/services/autoCombo/modePacks.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/autoCombo/modePacks.ts) adjust `DEFAULT_WEIGHTS` from [`open-sse/services/autoCombo/scoring.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/autoCombo/scoring.ts).

### lkgp (Last-Known-Good-Provider)

**Use when:** Request patterns show temporal locality—same prompt types or user sessions.

Re-uses the provider that **succeeded on the previous request**. Maintains LKGP state per context key; falls through to secondary selection if unavailable.

### context-optimized

**Use when:** Requests vary significantly in requirements (vision, tool use, long context).

Scores candidates by **context match**: vision capability, tool support, context window size, and specific model features. Providers with better feature alignment receive priority.

### cache-optimized

**Use when:** Repeated similar prompts are common and cache hit rates are meaningful.

Prefers providers that already have a **cached response** for the same prompt hash. Checks cache metadata before scoring; can skip inference entirely on exact match.

### context-relay

**Use when:** You want models to leverage request metadata without application-level prompt engineering.

Sends the request's **context as part of the prompt**, then selects based on response quality. The strategy itself becomes part of the inference process.

---

## Multi-Model Strategies (18–19)

These final two strategies involve multiple providers in a single request—either in parallel or in sequence.

### fusion

**Use when:** Maximum answer quality justifies compute cost, or disagreement detection is valuable.

**Fans out** the request to a *panel* of models in parallel, then uses a *judge* model to synthesize a single answer. Implemented in [`open-sse/services/fusion.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/fusion.ts).

```typescript
const config: ComboConfig = {
  strategy: 'fusion',
  fusionPanel: ['gpt-4', 'claude-3-opus', 'gemini-ultra'],
  fusionJudgeModel: 'gpt-4'  // Synthesizes final output
};

```

Uses `Promise.all` for parallel execution; judge receives all panel responses plus original prompt.

### pipeline

**Use when:** Multi-step reasoning benefits from different models at each stage (e.g., planning → execution → verification).

**Chains** multiple providers/models sequentially, feeding each stage's output to the next. Implemented in [`open-sse/services/autoCombo/pipelineRouter.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/autoCombo/pipelineRouter.ts).

```typescript
const config: ComboConfig = {
  strategy: 'pipeline',
  pipeline: [
    { model: 'gpt-4', purpose: 'plan' },
    { model: 'claude-3-haiku', purpose: 'execute' },
    { model: 'gpt-4-mini', purpose: 'verify' }
  ]
};

```

Iteratively calls `handleSingleModel` per stage; early termination possible on failure.

---

## Strategy Selection Cheat Sheet

| Goal | Recommended Strategy | Key File |
|------|---------------------|----------|
| Fastest possible response | `priority` with fastest-first ordering | [`combo.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/combo.ts) |
| Even load distribution | `round-robin` or `p2c` | [`combo.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/combo.ts) |
| Minimum cost | `cost-optimized` or `auto` mode: `'cheap'` | [`combo.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/combo.ts) / `autoCombo/*` |
| Maximum reliability | `strict-random` or `auto` mode: `'reliable'` | [`combo.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/combo.ts) / `autoCombo/*` |
| Best answer quality | `fusion` | [`fusion.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/fusion.ts) |
| Complex multi-step workflows | `pipeline` | [`pipelineRouter.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/pipelineRouter.ts) |
| Exploit temporal locality | `lkgp` | [`combo.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/combo.ts) |
| Dynamic optimal selection | `auto` with appropriate mode pack | `autoCombo/*` |

---

## Summary

- **OmniRoute's 19 combo routing strategies** span three categories: simple selection (7), quota-aware intelligent selection (12), and multi-model composition (2).
- **Core implementation** resides in [`open-sse/services/combo.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/combo.ts), with complex strategies delegating to `autoCombo/*`, [`fusion.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/fusion.ts), and [`pipelineRouter.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/pipelineRouter.ts).
- **Configuration** is via `ComboConfig.strategy`, with additional options like `mode` for the `auto` strategy and `fusionPanel`/`pipeline` for multi-model approaches.
- **Version reference:** All file paths and implementations confirmed from release `v3.8.50` of `diegosouzapw/OmniRoute`.

For full technical documentation, see [[`docs/routing/AUTO-COMBO.md`](https://github.com/diegosouzapw/OmniRoute/blob/main/docs/routing/AUTO-COMBO.md)](https://github.com/diegosouzapw/OmniRoute/blob/release/v3.8.50/docs/routing/AUTO-COMBO.md).

---

## Frequently Asked Questions

### What is the difference between `auto` and `priority` strategies?

`priority` performs a simple linear scan for the first healthy provider, while `auto` invokes the full Auto-Combo scoring engine with 13+ weighted factors including latency history, cost, error rate, and context match. Use `priority` for predictable, low-overhead routing; use `auto` when you want data-driven optimal selection without manual tuning.

### When should I use `fusion` versus `pipeline`?

Use `fusion` when you want **parallel** execution with answer synthesis—ideal for quality-critical tasks where model disagreement provides signal. Use `pipeline` for **sequential** multi-stage workflows where each step's output feeds the next—ideal for structured reasoning chains or when later stages depend on earlier results.

### How do mode packs modify the `auto` strategy?

Mode packs in [`open-sse/services/autoCombo/modePacks.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/autoCombo/modePacks.ts) adjust the `DEFAULT_WEIGHTS` table in [`scoring.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/scoring.ts). For example, mode `'fast'` increases latency weight while decreasing cost weight; mode `'quality'` boosts accuracy and context-match weights. This biases the 13-factor score without changing the underlying candidate evaluation logic.

### Can strategies be combined or nested?

Not directly through configuration—the `strategy` field accepts a single string. However, you can approximate nested behavior: use `auto` (which internally weights multiple factors), implement custom logic at the application layer, or use `pipeline` to chain stages with different strategies per stage by embedding OmniRoute calls within each pipeline step.