# How OmniRoute’s Fusion Combo Routing Strategy Works: Parallel Model Execution and Judge Synthesis

> Discover OmniRoute's fusion combo routing strategy. It uses parallel LLM execution and a judge model to synthesize the best response, optimizing performance and accuracy.

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

---

**The Fusion strategy fans out a single request to multiple LLMs in parallel, then employs a dedicated judge model to evaluate and synthesize the optimal single response from their candidate answers.**

The **Fusion** combo routing strategy is one of 19 distinct routing methods implemented in OmniRoute’s auto-combo engine. Unlike single-target strategies that route to one provider, Fusion exploits parallelism to aggregate intelligence from a curated panel of models, making it ideal for use cases requiring high-quality, consensus-driven outputs.

## What Is the Fusion Combo Routing Strategy?

In OmniRoute’s architecture, the **Fusion** strategy functions as a meta-router that coordinates multi-model inference. When a request specifies the `fusion` model identifier, the system does not select a single backend. Instead, it constructs a **panel** of target models, invokes them concurrently, and delegates final answer selection to a specialized **judge model**—typically a more capable LLM configured to merge or select from candidate responses.

This approach trades increased latency and token consumption for improved response quality, particularly when the panel combines complementary models (e.g., a fast "lite" variant alongside a slower "expert" model).

## How the Fusion Workflow Executes

The Fusion implementation follows a strict five-phase pipeline defined in [`open-sse/services/fusion.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/fusion.ts) and [`open-sse/services/combo/fusionPanel.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/combo/fusionPanel.ts).

### Step 1: Building the Model Panel

The process begins in [`open-sse/services/combo/fusionPanel.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/combo/fusionPanel.ts), where the `buildPanel()` function assembles the target model set. The panel definition includes selection criteria, model ordering, and optional weighting parameters. The router gathers eligible models—often mixing cheap and high-quality providers—into a execution list that respects the user’s configuration.

### Step 2: Parallel Execution via handleSingleModel

Once the panel is constructed, the `FusionExecutor` invokes `handleSingleModel` for each target concurrently. Each call executes through the standard executor pipeline, maintaining full compliance with per-model **rate limits**, **circuit breakers**, and **connection cooldowns**. This ensures that Fusion requests do not bypass OmniRoute’s existing resilience mechanisms.

### Step 3: Candidate Collection and Normalization

After all panel calls complete (or timeout), the system collects the raw completions. The collector normalizes outputs into a common format, ensuring consistent presentation regardless of provider-specific response structures. These normalized candidates represent the "fan-out" phase of the Fusion strategy.

### Step 4: Judge Model Synthesis

The critical synthesis step occurs via `FusionSynthesizer.runJudge()` in [`open-sse/services/fusion.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/fusion.ts). The pre-selected **judge model** receives a single prompt containing all candidate answers, with instructions to either choose the best response or merge the strengths of multiple candidates into a unified answer. This synthesis request routes through the regular executor chain, inheriting the same retry and error-handling logic as standard requests.

### Step 5: Streaming the Final Response

The judge model’s generated completion streams back to the client as the sole API response. OmniRoute’s design preserves the single-response contract: intermediate candidate answers remain internal and are never exposed to the caller.

## Key Source Files and Architecture

The Fusion strategy implementation spans three critical files within the `open-sse/` directory:

- **[`open-sse/services/fusion.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/fusion.ts)** – Orchestrates parallel panel execution, aggregates results, and triggers judge model synthesis via `FusionSynthesizer.runJudge()`.
- **[`open-sse/services/combo/fusionPanel.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/combo/fusionPanel.ts)** – Defines panel assembly logic in `buildPanel()`, managing model selection, ordering, and weighting criteria.
- **[`open-sse/handlers/chatCore.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/handlers/chatCore.ts)** – Serves as the entry point for chat completions, detecting the `"fusion"` model name and instantiating the `FusionExecutor` to handle the request.

## Invoking the Fusion Strategy

Client code requires no special SDK; the strategy activates via the model parameter in standard API calls:

```typescript
import fetch from "node-fetch";

const payload = {
  model: "fusion",  // Activates the Fusion strategy
  messages: [{ role: "user", content: "Explain quantum tunnelling." }],
  // Optional: custom panel configuration via extra fields
};

const response = await fetch("http://localhost:20128/v1/chat/completions", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify(payload),
});

const data = await response.json();
console.log("Fusion answer:", data.choices[0].message.content);

```

Internally, [`chatCore.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/chatCore.ts) routes this request to `FusionExecutor`, which executes the five-phase workflow described above.

## Performance Trade-offs and Considerations

**Latency**: Fusion incurs higher latency than single-target routing because it waits for the slowest panel member to respond (or timeout) before judge synthesis can begin.

**Token Usage**: Total token consumption equals the sum of all panel model outputs plus the judge model’s synthesis input and output, making this strategy significantly more expensive than direct routing.

**Quality Gains**: When configured with complementary models (e.g., domain-specific experts alongside generalist models), Fusion demonstrably reduces hallucination rates and improves answer comprehensiveness through the judge’s evaluative synthesis.

## Summary

- **Fusion** is one of 19 combo-routing strategies in OmniRoute that uses parallel model execution and judge-based synthesis.
- The workflow executes in [`open-sse/services/fusion.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/fusion.ts), assembling panels via [`fusionPanel.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/fusionPanel.ts) and routing through [`chatCore.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/chatCore.ts).
- **Parallel fan-out** occurs via `handleSingleModel` calls that respect individual rate limits and circuit breakers.
- A dedicated **judge model** synthesizes the final answer from candidate responses generated by the panel.
- The strategy is invoked by setting `model: "fusion"` in API requests, with trade-offs including higher latency and token costs offset by improved output quality.

## Frequently Asked Questions

### What distinguishes Fusion from other OmniRoute combo strategies?

Unlike single-target strategies that route to one model, or fallback strategies that sequence models, Fusion actively utilizes **all** models in a defined panel simultaneously. It is unique among the 19 combo methods for employing a secondary "judge" LLM to synthesize a consensus output rather than selecting or chaining existing responses.

### How does the judge model determine which candidate answer is best?

The judge model receives a system prompt instructing it to evaluate candidates based on accuracy, completeness, and relevance. According to the implementation in [`fusion.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/fusion.ts), the judge either selects the single best candidate or merges elements from multiple candidates into a coherent final response, depending on the synthesis configuration provided in the combo definition.

### Can developers customize the model panel used by Fusion?

Yes. The panel composition is fully configurable through [`open-sse/services/combo/fusionPanel.ts`](https://github.com/diegosouzapw/OmniRoute/blob/main/open-sse/services/combo/fusionPanel.ts). Developers can define selection criteria, specify exact model identifiers, set weighting schemas, and establish ordering preferences to tailor the panel to specific domains or cost constraints.

### Does the Fusion strategy respect rate limiting and circuit breakers?

Absolutely. Each call to a panel member routes through `handleSingleModel`, which enforces OmniRoute’s standard resilience mechanisms including **rate limiting**, **circuit breakers**, and **connection cooldowns**. The judge model synthesis also executes through the standard executor chain, ensuring consistent error handling across all phases.