OmniRoute Combo Routing Strategies: Complete Guide to the 17 I8 Routing Algorithms

OmniRoute’s combo routing system provides 17 configurable strategies defined in ROUTING_STRATEGY_VALUES that determine how requests are dispatched across multiple AI provider models, ranging from simple round-robin to sophisticated cost-optimized and context-aware selection algorithms.

OmniRoute is an open-source AI gateway that aggregates multiple LLM providers through a unified combo routing interface. The OmniRoute combo routing strategies control how incoming requests are distributed across configured provider-model targets, enabling intelligent failover, load balancing, and cost optimization according to the routingStrategies.ts constants.

What Are the I8 Routing Strategies?

The term "I8 strategies" refers to the complete enumeration of routing algorithms available in OmniRoute’s combo system. These strategies are centrally defined in src/shared/constants/routingStrategies.ts and exported as the ROUTING_STRATEGY_VALUES array. While the system is sometimes colloquially referred to as having "18 strategies," the public-facing ROUTING_STRATEGY_VALUES contains 17 distinct strategies, with additional internal strategies maintained separately in INTERNAL_ROUTING_STRATEGY_VALUES.

Complete List of the 17 Combo Routing Strategies

The following table details every strategy available in the ROUTING_STRATEGY_VALUES enum:

Strategy	Description	Use Case
priority	Picks the first target that matches the requested priority tier (e.g., priority → fastest, flex → balanced).	Guarantees the highest-priority model is chosen when multiple models share the same tier.
weighted	Assigns a numeric weight to each target; selection is random but proportionally biased by weight.	Enables fine-grained traffic-shaping across providers.
fill-first	Sends traffic to a target until its quota or capacity limit is reached, then falls back to the next target.	Useful for throttling high-cost providers while fully utilizing cheaper ones.
round-robin	Cycles through targets in a fixed order, distributing requests evenly.	Simple load-balancing without regard to capacity or cost.
p2c	Power-of-Two-Choices: randomly picks two candidates and selects the one with the lower current load.	Improves load distribution while keeping selection computationally cheap.
random	Chooses a target uniformly at random.	Baseline random fallback when no other policy applies.
least-used	Selects the target that has processed the fewest requests so far.	Helps to evenly spread usage over time.
reset-aware	Gives preference to providers that have recently reset their usage counters.	Works well with daily or monthly quota resets.
reset-window	Similar to reset-aware but looks at a configurable time window after a reset.	Fine-tuned handling of quota-reset periods.
cost-optimized	Ranks targets by their effective cost (price multiplied by estimated token usage) and picks the cheapest.	Minimizes spend when multiple providers offer the same model.
strict-random	Random selection that excludes any target currently flagged as unhealthy or over-quota.	Guarantees that only healthy providers receive traffic.
auto	Auto-selection based on a combination of heuristics; the algorithm adapts to runtime metrics.	Default for most combos when the user does not specify a concrete strategy.
lkgp	Last-Known-Good-Provider: falls back to the most recent provider that successfully fulfilled a request.	Provides resilience after transient failures.
context-optimized	Chooses a target that can best satisfy the required context length or token limit.	Important for very long prompts or large context windows.
context-relay	Routes a request to a provider that can relay context from a previous turn (e.g., reasoning cache).	Enables multi-turn reasoning across providers.
headroom	Selects the provider with the most remaining headroom (quota divided by cost).	Balances usage to avoid hitting quotas prematurely.
fusion	Merges multiple providers into a single logical target, distributing parts of the request among them.	Advanced use-case for composite responses.

Internal Strategies

Beyond the 17 public strategies, the system maintains INTERNAL_ROUTING_STRATEGY_VALUES for server-side logic. This includes algorithms like quota-share, which handles internal quota-sharing logic not exposed to the UI or API.

Strategy Validation and Schema Enforcement

In src/shared/validation/schemas/combo.ts, the comboStrategySchema Zod validator ensures that only values from ROUTING_STRATEGY_VALUES are accepted when creating or updating combos. This guarantees type safety across the API surface.

According to tests/unit/autocombo-unification.test.ts, the schema validation is strictly tied to the constants file:

// tests/unit/autocombo-unification.test.ts
import { ROUTING_STRATEGY_VALUES } from "@/shared/constants/routingStrategies";
import { comboStrategySchema } from "@/shared/validation/schemas/combo";

describe("combo strategy schema", () => {
  it("exposes exactly the I8 strategies", () => {
    const schemaValues = comboStrategySchema.options;
    expect(schemaValues).toEqual([...ROUTING_STRATEGY_VALUES]);
  });
});

Runtime Strategy Execution

The actual selection logic runs in open-sse/services/combo.ts. The getStrategyHandler() function maps a strategy string to its implementation, while resolveComboTargets() prepares the candidate list based on the combo configuration.

// open-sse/services/combo.ts
import { resolveComboTargets } from "./combo";
import { getStrategyHandler } from "./strategies";

export async function handleComboChat(combo, request) {
  const targets = await resolveComboTargets(combo);
  const chooser = getStrategyHandler(combo.strategy);   // Selects the I8 strategy
  const ordered = chooser(targets);                    // Generates ordered target list
  
  for (const target of ordered) {
    const result = await handleSingleModel(target, request);
    if (result.success) return result;
  }
  throw new Error("All combo targets failed");
}

Practical Implementation Examples

When creating a combo via the API, you specify the strategy from ROUTING_STRATEGY_VALUES in the request body:

// src/app/api/v1/combo/route.ts
import { createCombo } from "@/lib/db/combo";
import { ROUTING_STRATEGY_VALUES } from "@/shared/constants/routingStrategies";

await createCombo({
  name: "fast-priority-combo",
  strategy: "priority",               // Any value from ROUTING_STRATEGY_VALUES
  models: [
    { provider: "openai", model: "gpt-4o-mini", tier: "priority" },
    { provider: "anthropic", model: "claude-3-haiku-20240307", tier: "flex" },
  ],
});

Summary

• OmniRoute defines 17 public routing strategies in ROUTING_STRATEGY_VALUES located at src/shared/constants/routingStrategies.ts.
• Strategies range from simple algorithms like random and round-robin to sophisticated selections like cost-optimized, context-relay, and p2c (Power-of-Two-Choices).
• The comboStrategySchema Zod validator in src/shared/validation/schemas/combo.ts enforces valid strategy values across the API.
• Runtime selection occurs in open-sse/services/combo.ts via the getStrategyHandler() function, which orders targets according to the selected strategy before attempting requests.
• Additional internal strategies such as quota-share exist in INTERNAL_ROUTING_STRATEGY_VALUES for server-side quota management.

Frequently Asked Questions

What is the difference between public and internal routing strategies in OmniRoute?

Public strategies are exposed via ROUTING_STRATEGY_VALUES in src/shared/constants/routingStrategies.ts and are available for configuration through the UI and API. Internal strategies, defined in INTERNAL_ROUTING_STRATEGY_VALUES, are reserved for server-side logic such as quota-share and are not accessible for direct combo configuration.

How does the auto strategy decide which provider to use?

The auto strategy implemented in open-sse/services/combo.ts combines multiple heuristics including current load, historical success rates, and cost metrics to dynamically select the optimal provider. Unlike static strategies, it adapts to real-time runtime metrics without requiring manual configuration.

Which strategy minimizes API costs in OmniRoute?

The cost-optimized strategy ranks targets by their effective cost (calculated as price multiplied by estimated token usage) and selects the cheapest viable provider. This strategy is ideal forcost-sensitive workloads where multiple providers offer equivalent model capabilities.

Can I create custom routing strategies in OmniRoute?

Currently, the system validates all strategy values against the predefined ROUTING_STRATEGY_VALUES enum. Adding custom strategies requires modifying src/shared/constants/routingStrategies.ts to include the new value, updating src/shared/validation/schemas/combo.ts to recognize it, and implementing the corresponding handler logic in open-sse/services/strategies/.

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