Stimulir Fusion

Virtual models#

Fusion exposes two virtual model ids on the OpenAI-compatible chat completions endpoint. Call them exactly like any other model, with a hyb_* API key:

curl https://api.stimulir.com/api/v1/inference/chat/completions \
  -H "Authorization: Bearer hyb_..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "stimulir/fusion",
    "messages": [{"role": "user", "content": "Design a migration plan for this schema"}]
  }'

How it works#

The gateway dispatches your prompt to every panel model in parallel. Each panelist answers independently and never sees the other answers. A judge model then analyzes the full set: where the panel agrees, where it contradicts itself, what each answer covers only partially, which insights are unique, and what every panelist missed. The judge writes the final answer and that is the only completion returned.

With "stream": true the judge's answer streams as normal SSE chunks under the fusion model id, so existing streaming clients work unchanged.

Configuration#

Configure fusion per request with a body-level fusion object. Any model the gateway can route is legal, up to 8 panelists:

{
  "model": "stimulir/fusion",
  "messages": [{"role": "user", "content": "Review this consolidation approach"}],
  "fusion": {
    "panel": ["zai-org/GLM-5.2", "claude-opus-4-6", "gemini-2.5-flash"],
    "judge": "claude-opus-4-6",
    "mode": "auto",
    "analysis": true
  },
  "stream": true
}

Clients that cannot set request-body keys, Codex only exposes static provider headers, can pass the same object through an X-Fusion header instead. The body key wins when both are present:

curl https://api.stimulir.com/api/v1/inference/chat/completions \
  -H "Authorization: Bearer hyb_..." \
  -H 'X-Fusion: {"mode": "auto", "tools_mode": "panel"}' \
  -H "Content-Type: application/json" \
  -d '{"model": "stimulir/fusion", "messages": [{"role": "user", "content": "..."}]}'

Vision, perceive then panel#

Fusion accepts image inputs even when the panel includes text-only models. When a request carries images, a vision perceiver (default moonshotai/Kimi-K2.6, override with fusion.perceiver) analyzes them first, layout, verbatim text, tables, chart values, and that analysis replaces the raw images as shared grounding for every panelist and the judge. One vision call per request; if the perceiver fails, the run degrades gracefully instead of erroring.

Context windows#

Before the fan-out, the gateway estimates the input size and checks it against each panelist's confirmed context window. Panelists that cannot fit the input are skipped (reported in the response, see below) and the rest proceed; if no panelist fits, the judge answers solo; if even the judge cannot fit, the request returns a clean 400 with code context_length_exceeded and the actual token numbers, never a cryptic upstream error. Panelist drafts are also budget-truncated so the judge's own window can never overflow.

Reliability#

Every stage degrades instead of failing the request:

• A failing panelist is retried once against a fallback model, then dropped; the run continues with whatever survives.
• If every panelist fails, the judge answers solo, you still get a completion whenever the judge lane works.
• If the judge fails after the panel produced drafts, the strongest panelist draft is returned as the completion (streaming or not) instead of a 5xx.
• If the vision perceiver fails, the run continues with a placeholder instead of erroring.
• Billing is the sum of the underlying panel and judge completions. There is no markup on top.
• Every child call appears in the workspace trace tree tagged fusion:<model-id>, so the full fan-out is auditable in the Console. See Usage & Billing.

Reading the response#

Non-streaming fusion responses carry an additive fusion object (OpenAI SDKs ignore unknown fields). fusion.route tells you how the request actually ran, panel (full recipe), solo (adaptive or degraded single-judge), or panelist_fallback (judge failed; best draft returned), and fusion.panelists reports each panelist's status, including context-window skips. With fusion.analysis: true the judge's structured panel analysis rides along:

{
  "model": "stimulir/fusion",
  "choices": [{ "message": { "content": "..." } }],
  "fusion": {
    "route": "panel",
    "judge": "zai-org/GLM-5.2",
    "panelists": [
      { "model": "zai-org/GLM-5.2", "status": "success" },
      { "model": "moonshotai/Kimi-K2.6", "status": "success" },
      { "model": "MiniMaxAI/MiniMax-M2.5", "status": "error", "error": "..." }
    ],
    "analysis": {
      "consensus": ["A and B agree that ..."],
      "contradictions": [],
      "partial_coverage": ["Only C addressed the rollback path"],
      "unique_insights": ["B noted the index regression"],
      "blind_spots": []
    }
  }
}

When to use it#

Fusion is built for quality-critical work: deep reasoning, hard coding questions, research, and review, where being wrong costs more than a few extra completions. For mixed traffic, set fusion.mode: "auto" and the gateway sends simple prompts to a single model while hard prompts get the full panel.

From the CLI#

# Streams the judge's answer
stimulir fusion "your question" [--panel model1,model2] [--judge model] [--project <id>] [--no-stream]

# Use the frontier tier (stimulir/fusion-max)
stimulir fusion "your question" --max

Python SDK#

from stimulir import StimulirClient

client = StimulirClient(api_key="hyb_...")

result = client.fusion.complete(
    "your question",
    panel=["zai-org/GLM-5.2", "moonshotai/Kimi-K2.6"],
    judge="zai-org/GLM-5.2",
    max_tier=False,
)