How OmniRoute's Fusion Routing Strategy Uses a Judge Model to Synthesize Answers

OmniRoute's fusion routing strategy fans out requests to multiple "panel" models in parallel, then uses a dedicated judge model to analyze their anonymized answers and synthesize a single authoritative response.

The fusion combo strategy in OmniRoute (located in diegosouzapw/OmniRoute) implements a sophisticated multi-model routing pattern that improves response quality through consensus analysis and synthesis. Rather than relying on a single model, this approach leverages the diversity of multiple models while masking their individual limitations behind a unified judge evaluation.

How the Fusion Pipeline Works

The fusion strategy operates across three distinct phases: panel fan-out, answer collection, and judge synthesis. Each phase is implemented with specific error handling and graceful degradation paths.

Phase 1: Panel Fan-Out with Parallel Dispatch

The fusion entry point is handleFusionChat in open-sse/services/fusion.ts (lines 70-78). This function first validates the panel configuration and rejects oversize panels that would exceed resource limits. For tool-bearing requests, fusion may be bypassed entirely since tool calls require precise execution chains.

The actual dispatch happens through dispatchFusionModel and collectPanel (lines 78-84, 82-88). The system sends requests to every panel model in parallel with streaming disabled and tool calls stripped:

// Fan-out the request to the panel models (non-streaming, tools stripped)
const panelBody = { ...rest, stream: false };
const calls = panelToDispatch.map(target =>
  withTimeout(
    dispatchFusionModel(handleSingleModel, panelBody, target),
    cfg.panelHardTimeoutMs
  )
);
const settled = await collectPanel(calls, { ...cfg, minPanel });

A quorum-grace timeout limits straggler penalty—slow panel members don't block the entire synthesis process.

Phase 2: Extracting and Normalizing Panel Answers

Once responses return, extractPanelText (lines 55-97) normalizes provider-specific response formats into plain text. This handles variations between OpenAI, Anthropic, Google, and other provider response structures:

// Gather successful texts
const answers: Array<{ model: string; text: string }> = [];
for (const res of settled) {
  const json = await (res as Response).clone().json();
  const text = extractPanelText(json);
  if (text) answers.push({ model: getFusionModelString(target), text });
}

The extractTextContent helper from open-sse/translator/helpers/geminiHelper.ts provides underlying provider normalization used by this extraction layer.

Phase 3: Judge Model Synthesis

The critical synthesis step uses buildJudgePrompt (lines 22-42) to construct a specially formatted prompt. All panel answers are anonymized as "Source N" to prevent brand bias from influencing the judge:

// Build the judge prompt (anonymized sources)
const judgePrompt = buildJudgePrompt(answers);

// Append the prompt as a new user turn and dispatch to the judge
const judgeBody = appendUserTurn(body, judgePrompt);
return handleSingleModel(judgeBody, effectiveJudge);

The appendUserTurn function (lines 86-88) inserts this judge prompt as an additional user message while preserving the original request structure, including any tool parameters that the judge itself might need to emit.

Judge Model Instructions and Decision Logic

The judge model receives explicit instructions within buildJudgePrompt to perform three core tasks:

1. Analyze — Evaluate the panel for consensus, contradictions, partial coverage, unique insights, and blind spots
2. Reason independently — Override panel consensus if the judge possesses superior knowledge
3. Synthesize authoritatively — Produce a single final answer without mentioning sources or the multi-model consultation process

This design deliberately hides the synthesis mechanism from end users. The response appears as a seamless single-model answer, eliminating UI complexity while delivering higher quality through behind-the-scenes multi-model evaluation.

The judge dispatch uses handleSingleModel (lines 89-90) with fallback logic: if the configured judge model is unavailable, the system promotes the first surviving panel member to serve as the judge.

Graceful Degradation Paths

OmniRoute's fusion implementation includes three explicit degradation scenarios:

Scenario	Behavior
Zero panel answers	Returns HTTP 503 with per-model failure details for debugging
Single panel answer	Returns directly unless explicit judge model configured; if judge configured, still routes through judge review
Multiple answers	Full synthesis through judge model as described above

The test suites in tests/unit/fusion-judge-model-6455.test.ts and tests/unit/fusion-judge-survivor.test.ts verify these paths, including proper judge invocation and fallback behavior when the default judge fails.

Key Implementation Files

File	Responsibility
open-sse/services/fusion.ts	Core fusion orchestration: panel fan-out, answer collection, judge synthesis
open-sse/services/combo/fusionPanel.ts	Panel construction and per-target admission gating
open-sse/translator/helpers/geminiHelper.ts	Response normalization utilities for extractPanelText
tests/unit/fusion-judge-model-6455.test.ts	Judge model invocation and synthesis verification
tests/unit/fusion-judge-survivor.test.ts	Judge fallback to surviving panel members

Summary

• Fusion routing in OmniRoute combines parallel panel execution with centralized judge synthesis
• The judge model anonymizes sources to eliminate brand bias and produces unified, authoritative answers
• Implementation spans handleFusionChat, buildJudgePrompt, and handleSingleModel in open-sse/services/fusion.ts
• Graceful degradation handles 0, 1, or multiple panel responses without client-side failures
• Streaming flags and tool parameters are preserved so the judge can still emit tool calls when needed

Frequently Asked Questions

What happens if all panel models fail to respond?

OmniRoute returns an HTTP 503 error with detailed per-model failure information. This allows operators to diagnose whether failures are provider-specific or systemic. The architecture treats total panel failure as a service degradation event rather than attempting synthesis without source material.

Does the judge model always improve answer quality?

The judge can improve quality through error detection (identifying when panel members contradict established facts), coverage expansion (combining partial answers into complete responses), and bias elimination (anonymizing sources removes brand loyalty effects). However, quality depends on the judge model's own capabilities—configuring a weak judge may not improve upon strong panel consensus.

Can the judge model invoke tools during synthesis?

Yes. The judgeBody construction preserves the original request's tool parameters and streaming configuration. If the synthesized response requires tool execution—particularly when panel answers revealed gaps requiring external data—the judge can emit tool calls just like any single-model request.

How does OmniRoute prevent the judge from simply copying the most verbose panel answer?

The buildJudgePrompt explicitly instructs the judge to apply its own reasoning and override consensus when warranted. By requiring independent analysis rather than mechanical aggregation, the prompt design encourages genuine synthesis. The anonymization of sources as "Source N" further prevents the judge from weighting answers by perceived authority or verbosity.

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