How OmniRoute Fusion Routing Uses a Judge Model for Answer Synthesis

The OmniRoute Fusion routing strategy synthesizes answers by first fanning out prompts to a parallel panel of models, then using a dedicated judge model to analyze consensus, contradictions, and blind spots across all responses to produce a single authoritative answer.

The fusion routing strategy in OmniRoute (diegosouzapw/OmniRoute) implements a two-phase approach that combines the diversity of multiple LLM responses with the quality control of a synthesis step. This pattern, implemented in open-sse/services/fusion.ts, is particularly valuable when you need robust answers that benefit from cross-model verification without exposing users to raw model disagreements.

How the Fusion Strategy Works

Fusion operates through distinct panel and judge phases. Understanding both is essential for configuring effective combo strategies in OmniRoute.

Phase 1: Panel Fan-Out

The strategy begins by dispatching the original user prompt to every model in the configured panel simultaneously. According to the source code, these calls are forced to be non-streaming and stripped of tools to ensure each panel member returns a complete prose answer.

The implementation uses a quorum-grace mechanism that stops waiting once a configurable minimum number of panels (minPanel) have succeeded, while still allowing a short grace window (stragglerGraceMs) for slower members to complete:

// From open-sse/services/fusion.ts#L31-L38
// Panel calls are parallelized with quorum-grace collection

This design prioritizes latency efficiency — you don't wait for every straggler, but you don't rush to judgment either.

Phase 2: Judge Synthesis

Once panel responses are gathered, the judge model receives a synthesized prompt containing all anonymized answers and detailed instructions to produce the final output.

Judge Model Selection Logic

OmniRoute implements a three-tier fallback system for selecting which model performs synthesis:

1. Explicit configuration — if judgeModel is specified in the combo config, that model is used verbatim.
2. Default panel member — if no explicit judge is set, the first panel model (panel[0]) becomes the default judge.
3. Survivor fallback — if the default judge fails during fan-out, the strategy falls back to the first surviving panel model so synthesis can still occur.

This logic is resolved immediately before synthesis:

// From open-sse/services/fusion.ts#L30-L36
const effectiveJudge = hasExplicitJudge
  ? judge
  : answers.some(a => a.model === getFusionModelString(panel[0]))
    ? getFusionModelString(panel[0])
    : answers[0].model;

The implementation at open-sse/services/fusion.ts#L10-L12 defines these selection priorities, ensuring Fusion remains resilient even when panel members fail.

Building the Judge Prompt

The buildJudgePrompt helper function formats collected panel answers into an anonymized structure that prevents the judge from knowing which source came from which model. This anonymization reduces bias toward brand-name models.

The function constructs:

// From open-sse/services/fusion.ts#L124-L141
export function buildJudgePrompt(answers: Array<{ text: string }>): string {
  const panel = answers.map((a, i) => `[Source ${i + 1}]\n${a.text}`).join("\n\n");
  return [
    `You are the JUDGE in a model-fusion panel…`,
    /* instructions: analyze consensus, contradictions, partial coverage, 
       unique insights, blind spots */
    "=== PANEL RESPONSES ===",
    panel,
    "=== END PANEL RESPONSES ===",
    "",
    "Now write the final answer to the user's original request."
  ].join("\n");
}

The judge instructions explicitly direct the model to:

• Analyze consensus and contradictions across sources
• Identify partial coverage and unique insights
• Spot blind spots that individual panel members missed
• Produce one authoritative answer while ignoring the fact that multiple models were consulted

Dispatching the Judge for Final Synthesis

The synthesized prompt is appended as a new user turn via appendUserTurn and sent to the selected judge model through the standard single-model handler. The implementation supports both target-based invocation (when judgeTarget provides resolved connection info) and name-based invocation:

const judgeBody = appendUserTurn(body, buildJudgePrompt(answers));
return judgeTarget
  ? handleSingleModel(judgeBody, judgeTarget.modelStr, judgeTarget)
  : handleSingleModel(judgeBody, effectiveJudge);

This dispatch pattern at open-sse/services/fusion.ts#L22-L33 ensures the judge step integrates cleanly with OmniRoute's existing model handling infrastructure.

Configuration Examples

Basic Fusion with Explicit Judge

import { handleFusionChat } from "open-sse/services/fusion.ts";

const combo = {
  name: "my-fusion",
  strategy: "fusion",
  judgeModel: "openai/gpt-4-judge",  // Dedicated judge model
  fusionTuning: { 
    minPanel: 3,           // Wait for at least 3 successes
    stragglerGraceMs: 5000 // 5-second grace window
  },
};

await handleFusionChat({
  body: requestBody,
  models: ["openai/gpt-4", "anthropic/claude-2", "google/gemini-1.5"],
  handleSingleModel,
  log: comboLogger,
  comboName: combo.name,
  judgeModel: combo.judgeModel,
  tuning: combo.fusionTuning,
});

Minimal Fusion Using Default Judge

// First panel model (openai/gpt-4) serves as judge if it survives
await handleFusionChat({
  body,
  models: ["openai/gpt-4", "openai/gpt-3.5"],
  handleSingleModel,
  log,
});

Key Implementation Files

File	Purpose
open-sse/services/fusion.ts	Core Fusion implementation: panel fan-out, judge selection, prompt building, synthesis dispatch
open-sse/services/combo/types.ts	Type definitions (HandleSingleModel, ComboLogger) used by Fusion
open-sse/utils/error.ts	Sanitized error responses for total panel failure scenarios
open-sse/translator/helpers/geminiHelper.ts	extractTextContent helper for normalizing panel answers across providers

Summary

• Fusion routing in OmniRoute combines parallel panel execution with judge model synthesis to deliver higher-quality answers than any single model alone.

• The judge model is selected through explicit configuration, default panel membership, or survivor fallback — ensuring synthesis always remains possible.

• Anonymized prompts prevent judge bias while structured instructions guide analysis of consensus, contradictions, and blind spots.

• Tunable parameters (minPanel, stragglerGraceMs) let operators balance latency against answer quality for their specific use cases.

• All core logic resides in open-sse/services/fusion.ts, with clean integration into OmniRoute's single-model dispatch infrastructure.

Frequently Asked Questions

What happens if all panel models fail before reaching quorum?

If no panel members succeed within the configured timeouts, Fusion returns a sanitized error response using helpers from open-sse/utils/error.ts. No judge synthesis is attempted without at least one valid panel answer.

Can I use a different judge model than the panel models?

Yes. The judgeModel configuration field accepts any model string supported by your OmniRoute deployment. This allows you to use smaller, faster models for the panel and a more capable model specifically for synthesis, optimizing cost-performance tradeoffs.

Why are panel responses anonymized as "Source N" rather than labeled with model names?

Anonymization prevents the judge model from developing preferences based on brand recognition or known capabilities of specific providers. This design choice, implemented in buildJudgePrompt, ensures the judge evaluates answers purely on content quality rather than source authority.

Does Fusion support streaming responses?

No. According to the source code at open-sse/services/fusion.ts#L31-L38, panel calls are forced to be non-streaming to ensure complete answers are available for synthesis. The final judge response may be streamable depending on your handleSingleModel implementation, but the internal panel phase requires full responses.

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