Fusion Style Workflow

Fusion-Style Workflows: Publish a Multi-Model Panel as an Observable Virtual Model

中文版

OpenRouter Fusion made one idea much more visible: the next useful model endpoint may not be a single larger model. It may be a compound workflow made of multiple models, tools, reviewers, and synthesis steps.

1flowbase is not only a model router. It lets you turn this Fusion-style pattern into a reusable, publishable, and observable virtual model endpoint. Your client calls one model name, while 1flowbase runs the full workflow behind it and records node inputs, outputs, tokens, tool callbacks, failures, and traces.

When to use it

Fusion-style workflows are best for tasks where a better answer is worth extra latency and cost:

• Complex research: ask multiple models independently, then synthesize consensus, contradictions, and blind spots.
• Architecture review: let different models inspect implementation, risk, cost, and maintainability.
• Code or document review: run several model perspectives before producing a final recommendation.
• Multi-model fallback and cost control: combine strong, small, cheap, and specialized models into one observable virtual model.
• Upstream model for agents: expose one standard endpoint to Claude Code, Codex, OpenCode, Continue, or other clients, while running your own workflow internally.

Do not use a Fusion-style workflow for every request. Simple Q&A, cheap classification, and basic formatting usually do not need a model panel. Use it when the task has high value, high uncertainty, or a high cost of being wrong.

Import the official template

1flowbase includes an official fusion template. Open the Templates page, find fusion, and click Import template.

After importing, you get a ready-to-preview workflow. Start with the template to understand the structure, then replace the models, tools, and review strategy with your own.

Workflow structure

The template uses this core shape:

Start -> Main LLM -> Answer
             |
             +-> fusion tool
                    |
                    +-> Branch LLM2 / LLM3 / LLM4
                    +-> Synthesis LLM5
                    +-> Tool Result

The main LLM receives the user request and calls the mounted fusion tool when the task benefits from multi-model review. The fusion tool fans the task out to branch LLMs, passes the branch results into a synthesis LLM, and returns a tool result to the main LLM.

The highlighted area is the model panel. You can configure the branch LLMs with different providers, strengths, context lengths, and cost profiles.

Configure the tool node

Open the main LLM node settings, enable Mount LLM, then add or edit a tool registration. The template uses problem_review as the tool name.

Key settings:

• Description: explain when the tool should be called, for example: "This is a review panel tool. Calling it reviews the input task."
• Allow branch LLM: enable this so the tool can call downstream branch LLMs.
• Tool mode: choose fusion.
• Pre-intercept / Schema fields: add fields only when you need strict input structure. For a basic review workflow, keep it simple first.
• Mounted LLM list: connect the branch and synthesis LLMs used by the tool.

Start with the default template and make it work before adding more models. Too many branch models increase cost, latency, and debugging complexity at the same time.

Run and preview

After importing the template, return to the workflow page and click Preview. Try a prompt that benefits from model review:

Review this plan for the next development cycle: connect Playwright and quality gates to CI/CD, then give risks, benefits, and a two-week execution plan.

During execution, the main LLM decides whether to call problem_review. If it succeeds, the branch LLMs execute according to the workflow, the synthesis node creates the tool result, and the main LLM turns it into the final user-facing answer.

Inspect run logs

Open Log from the left sidebar, select the run, then open Conversation log and the Track tab. You can inspect the tool chain, status, and token usage of each sub-call.

Check these details:

• Whether problem_review appears under Tools.
• Whether fusion Executed successfully returned.
• Token usage for each branch LLM, such as LLM2, LLM3, LLM4, and LLM5.
• Which node failed, timed out, or returned unexpected content.
• Whether the final answer actually uses the differences between branch outputs instead of copying one model.

This is the main difference from a plain model router: you do not only get a final answer. You can see what happened behind it.

Publish as a virtual model endpoint

Once the workflow is stable, click publish to expose it as a virtual model endpoint. External clients can call it like a normal model.

Common compatible APIs:

OpenAI Responses API
OpenAI Chat Completions API
Claude-compatible Messages API

To the client, it is one model name. To you, it is an observable workflow with branch LLMs, review steps, tool callbacks, and trace logs.

Recommended names

Use names that explain when the endpoint should be used:

fusion-review
architecture-review-panel
research-fusion
code-review-council

The name should describe the use case, not only the underlying provider.

Minimum useful setup

For a first working version, start with:

Main LLM: decides when to call the fusion tool and writes the final answer
Branch LLM A: cheap and fast model for broad coverage
Branch LLM B: stronger reasoning model for risks and edge cases
Branch LLM C: model from another provider for diversity
Synthesis LLM: extracts consensus, contradictions, blind spots, and final advice

After that, add more branches, budget gates, fallback, JSON Schema, or custom tools only when the logs show you need them.

FAQ

Why is it slower?
A Fusion-style workflow calls multiple models and waits for review or synthesis. It is naturally slower than a single-model call. Use it for high-value tasks, not every prompt.

Why does it cost more?
The workflow creates multiple model calls. Use the run log to inspect token usage per branch, then reduce the number of branches, use cheaper models, or trigger fusion only for specific tasks.

Why is the final answer not better?
Check the tool description first. If the main LLM does not know when to call problem_review, or if the branch LLMs are too similar, the fusion gain will be small.

How do I know which model contributed the most?
Open the Track log, expand the fusion tool, and compare branch outputs, token usage, failure status, and what the final answer actually used.

Is this a replacement for OpenRouter Fusion?
1flowbase is a visual, publishable, and observable runtime for Fusion-style workflows. You can use OpenRouter models, other providers, local models, and your own tool nodes in the same workflow.

Core idea

OpenRouter Fusion proved that multi-model synthesis is useful.
1flowbase makes that workflow controllable, observable, reusable, and publishable.

If you are building AI agents, coding agents, research assistants, or internal knowledge workflows, the Fusion template is a good starting point: let multiple models think independently, then let 1flowbase show you what happened at every step.