Multi-Model STORM Research Pipeline with OpenRouter Fusion

I built my first multi-model STORM research pipeline because I got tired of trusting one model to think for me. That impulse turned into six months of work and a system I am still refining.

Every STORM implementation I found relies on one trick: a single language model roleplaying different personas. Ask it to be a historian, and it produces historian-sounding questions. Ask it to be a skeptic, and it channels a skeptic. The prompts look different underneath. The reasoning engine is identical. Same model, same training data, same blind spots wearing different hats.

I call that theatrical diversity. I wanted something closer to what happens when four different experts walk into a room and actually disagree.

Today I have a working system. Four free-tier models per research perspective inside OpenRouter Fusion. A DeepSeek V4 Flash judge that fuses their outputs. It runs inside an agent harness with zero hand-written orchestration code. A 10-perspective run costs about four and a half cents in judge calls, and it has a human checkpoint positioned between synthesis and curation that no published STORM variant positions after synthesis. Whether that checkpoint is the genuine article or a useful kludge is something I will let you decide.

This post covers why I built it, how it works, and where the honest edges of my own understanding sit. That last part matters more than the sales pitch.

What STORM Got Right (and What It Assumes)

Stanford’s STORM paper, published at NAACL 2024, made one claim that changed how I think about research automation. Direct prompting produces shallow questions. Simulated conversations between a writer and a topic expert produce better ones. Their FreshWiki dataset evaluation, their editor survey, and the 25 percent improvement in organization over baselines hold up.

STORM assumes something worth naming explicitly, though. The multiple perspectives in the system are persona prompts. The paper says so directly. It “personifies the LLM with specific perspectives for question asking.” One model drives every perspective. Multiple system prompts. Same underlying knowledge, same reasoning engine, same failure modes. The paper’s framing leans on stakeholder theory, the idea that different stakeholders prioritize different facets. That is a reasonable framework. But it is still one model pretending to be several people, not several models doing what they actually think.

Co-STORM, the EMNLP 2024 follow-up, took a different angle. The human-in-the-loop variant added a real person to the discussion, but the simulated experts stayed a single model in disguise. The Co-STORM human acts as a discourse participant. They steer what questions get asked during the interview phase. This is a genuinely thoughtful design that solves a real problem. But it is not the problem I was trying to solve.

My problem was narrower. What if the models themselves disagree? Not because I prompted them to disagree, but because they were built differently, trained on different data, and reached meaningfully different conclusions from the same evidence? That disagreement should be a signal, not noise. STORM’s architecture cannot capture it because the panel has one brain.

The Fusion Switch

Four months into working with Stanford’s reference implementation and two LangGraph ports, I hit a wall. Same model for every perspective in a research run, same results. Too consistent. Every “expert” ranked the same sources, emphasized the same themes, and missed the same assumptions. Different vocabulary. Same convergence. That problem became Phase 1 of the architecture I run today.

OpenRouter Fusion changed the equation. Fusion takes your prompt, fans it out to a panel of models you choose. Each model runs independently. A judge reads all four responses and produces a structured analysis: where the panel agrees, where they disagree, what each model caught that the others missed, and what none of them addressed.

My panel is four free-tier models:

• GLM 4.5 Air for frontier reasoning
• Nemotron 3 Ultra 550B for MoE-based reasoning at scale
• gpt-oss-120b for STEM and structured output
• Gemma 4 31B for general reasoning with a different training distribution

DeepSeek V4 Flash synthesizes the four outputs into one report I can work with. Temperature zero on the judge call, which keeps the synthesis anchored to the panel’s actual claims rather than invented middle positions I never asked for.

Here is what that looks like in practice. When I ask all four models to evaluate whether agentic AI systems will consolidate around one orchestration framework in 2027, GLM 4.5 Air reasons about adoption curves and developer lock-in. Nemotron reasons about enterprise procurement. Gemma reasons about open-source dynamics. They come back with overlapping but non-identical conclusions. The judge surfaces the delta between them. That delta is where the useful research lives.

This is not disagreement from prompt trickery. These models were trained by different labs, Zhipu/Z-AI, NVIDIA, OpenAI, Google, on different data, with different architectural choices. When Gemma calls a trend uncertain, and Owl Alpha calls it likely, that is not a persona mask slipping. That is two genuinely different reasoning systems evaluating the same evidence and reaching different confidence levels.

Whether this produces meaningfully better output than a single strong model with great prompting is a question I will address honestly below. The short version: I believe it does, but belief is not measurement, and the controlled comparison I would need to settle the question is still on my list. Phase 1 hands off to Phase 3 — curation driving the actual writing — with Phase 2.5 sitting between them, which is where things get interesting.

What It Actually Costs

Marketing answer: near-zero cost, all free-tier models.

Honest answer: mostly right, with footnotes that matter more than most blog posts bother with.

DeepSeek V4 Flash pricing as of June 2026: 14 cents per million input tokens on cache miss, 28 cents per million output tokens. Cache hit is 0.28 cents per million. Each Fusion call fires the panel models in parallel and runs one judge synthesis on top. Across a 10-perspective STORM-Full run, that works out to roughly ten judge invocations. Each judge call runs maybe 2,000 to 4,000 input tokens and 1,000 to 2,000 output tokens. Across ten of those, the judge costs around 3 to 5 cents. Call it four and a half cents per run at the conservative end. Fifty research runs cost about $2.25.

Footnotes that eat into that number:

Free-tier OpenRouter models have rate caps. The base tier is 50 requests per day, 20 requests per minute. A 10-perspective run with retries can blow through that if you are running multiple pipelines. Once you add $10 in credits, you jump to 1,000 requests per day. Different conversation entirely. I am running a funded account, making the rate limits a non-issue for me.

Fusion calls run 2 to 3 times longer than standard model calls, per OpenRouter’s published benchmark. That wall-clock cost never makes it into marketing copy. A research run that takes 90 seconds with a single model takes 3 to 5 minutes with Fusion. Not catastrophic. Real.

Retry overhead from rate-limited panel models adds 10 to 20 percent cost across a full run because failed calls consume tokens before they fail.

My actual verdict on “near-zero”: defensible at the per-run level, misleading if you skip the caveats. If zero-cost research at scale is what you need, single-model DeepSeek Flash without Fusion runs at about 3 cents per run, with no rate-limit dance. The Fusion premium buys you coverage diversity, not cheapness. Whether that 50 percent premium pays off depends on the work. For broad, multi-domain questions where differences in training data matter, I think it does. For narrow, well-defined queries, a single strong model with strong prompting likely covers most of the gap.

Why I Built It Inside an Agent Harness

This section took me longer to articulate than any other. It matters most precisely because it is the least flashy.

The original STORM is a Python library. A careful one. But it treats orchestration as a static script. If you want a truly dynamic, agentic AI research pipeline, you have to break away from hard-coded sequential modules: knowledge curation, outline generation, article generation, and article polishing. State passes between stages as JSON files. Customization happens through subclassing. If you want to swap a model or change the retrieval backend, you modify the runner code. Every implementation I found follows this pattern. It is the standard approach.

I looked at what writing that code would mean and realized I was about to build something I already had.

Hermes Agent, the platform I run on, has a built-in parallel delegation primitive. Feed it a goal string and a context block. It spawns an isolated subagent with its own conversation, terminal, and toolset. Three of these run concurrently by default. Only the final summary enters my context window. Interrupting me interrupts all active children.

I don’t write custom worker pools just to run four research perspectives in parallel. The harness handles that complexity for me. I do not wrangle prompt wrappers or context windows. I do not debug race conditions or hand-roll retry logic. I write three lines: a goal, a context, and a toolset array. The harness handles orchestration.

Across the whole project, that eliminates several hundred lines of infrastructure code I would have had to write and test. The exact count depends on how defensive you want your standalone Python to be. I have seen estimates as high as 800 lines. My actual count is closer to 400. Either way, meaningful.

But this is not a Hermes marketing post. The pattern transfers. Claude Code’s dynamic workflows and Agent() tool are the direct equivalent. LangGraph’s Send API plus subgraphs map cleanly. CrewAI’s role-based orchestration covers sequential and hierarchical research patterns. If your framework supports parallel subagent dispatch with an isolated context, you can do what I am describing. The primitive is universal. Hermes is just where I first found it. (If you want the longer version of how I got from a single chatbot to an 11-profile multi-agent system, I wrote up that whole arc in From Turing to Hermes.)

The honest limitation: harness-coupled pipelines lose typed data contracts. STORM’s original InformationTable is a structured artifact that flows between stages. Inside a harness, state passes as text summaries. You gain isolation and parallelism. You lose explicit schema. For research pipelines where intermediate artifacts matter, the right move is hybrid. Let the harness handle fan-out and orchestration. Let the filesystem handle structured inter-stage state. That is the architecture I actually run.

One more thing matters here. Stanford’s original pipeline threads information through four modules using a shared in-memory state. The harness fan-out model lives in two places simultaneously: in the research dispatch (Phase 1) and in the synthesizing judge, and then writes the intermediate state back out to the filesystem to bridge the gap into Phase 3. This is a real engineering tension, not an academic footnote. I call it a tradeoff I live with because the alternative is writing those 400 lines.

The Checkpoint Nobody Else Does

There is a moment in my pipeline that I have not found in any published STORM variant. It sits after the Fusion panel synthesizes findings and before curation drives writing. I think it is one of two things this post contributes. The other is the multi-model panel itself.

Co-STORM puts the human inside the interview loop. The human observes the discourse between simulated experts, injects utterances to steer the discussion, and catches what the system misses through participatory serendipity. It is a thoughtful design. The collaboration between human and AI drives the research. My pipeline splits these responsibilities differently.

To situate this in the full flow: Phase 1 is the Fusion panel running four models in parallel per perspective. Phase 3 is curation, driving the actual writing. Phase 2.5 is what happens in between, and it has no equivalent in any published STORM variant I found. After the Fusion panel synthesizes, before those findings drive anything else, I read the fused report and stress-test it. Not as an editor. Not as a fact-checker. As a domain practitioner. “Does this match your experience? What is the part that feels wrong entirely? What did the panel miss because it was not in any training data you have internalized?”

Three classes of error this catches that I have not seen addressed elsewhere. Synthesis-level coherence failures. Source bias transfer, which the original STORM paper names explicitly as an open challenge: promotional source tone bleeding into generated conclusions. And over-association of unrelated facts, harder to catch than factual hallucination, because each fact is correct, but the implied relationship is fabricated.

I bring a particular lens to this work. Twenty-five years in higher education operations and DC logistics. Graduate coursework covering business intelligence. Active trading. Building production AI systems since early 2024. When the Fusion panel synthesizes claims about enterprise AI adoption, I have tacit models the panel lacks because practitioners rarely publish what they know from experience, reading balance sheets at 2 AM. That is the value I bring. It is not replicable with another model.

The honest limitation is that this checkpoint is a bottleneck. It serializes the pipeline. Multiple research flows are stacking up in Phase 2.5, and gates are piling up fast. It trades throughput for accuracy, not both at once. For personal brand content where the expert is always available and quality beats volume, the tradeoff makes sense. For a content farm, it does not scale, and nobody should pretend otherwise.

I want to be precise about the novelty claim because getting this wrong would poison the whole post. Co-STORM is a published human-in-the-loop variant, I cited it above, and it does real work. The distinction is where the human enters. Co-STORM’s human participates during the interview phase, steering discourse as it happens. Mine validates conclusions after synthesis, before those conclusions drive anything. That is a different checkpoint at a different pipeline stage with a different job. A post-synthesis, pre-curation human validation gate does not appear in any published STORM variant I found, and that is the narrower claim I am making. “Structured way” is still doing work in that sentence. I will not pretend the finding is bigger than it is.

What the Skeptic Gets Right

Several months ago, Shan et al. published a finding at ACL 2026 that I cannot ignore. When you control for prompt conditioning, single-agent systems produce higher semantic diversity than multi-agent systems with identical backbones. A single model, asked to generate from five different perspectives in a single pass, outperforms five agents with the same perspectives distributed across them. The mechanism is what the researchers call “information visibility.” Parallel agents converge on overlapping ideas because they cannot see each other’s reasoning.

This is a real finding, and I want to name it clearly because my entire pipeline could be misread as contradicting it. The key distinction is that Shan et al. tested identical backbones across all conditions. Five agents, same model, different system prompts. Their finding concerns prompt diversity within a single architecture. My approach uses four genuinely different architectures and system prompts. Nemotron and Gemma differ from two instances of GLM 4.5 Air because they are not two copies of the same model with swapped system prompts; they are structurally different systems.

The 2025 DEI paper on heterogeneous evolutionary inference supports the principle. Heterogeneous, different-architecture ensembles achieved 124 percent higher diversity quality scores than homogeneous ensembles at equal budget. That was a biological inference task, not LLM research. I cite it as an existence proof that architectural diversity matters, not as a direct measurement of my pipeline. “I treat this domain transfer as a known risk that requires manual verification at the validation gate.

Here is where the skeptic has teeth. I have not run the controlled experiment that would actually matter: a single model with four diverse prompts, plus synthesis against four different models, with equal token budgets, on the same research topics. That comparison would settle the question. I have not done it. I believe my approach produces better coverage. I have the DRACO-adjacent evidence and the DEI paper. But belief is not measurement, and I will not call it proof.

The skeptic’s strongest point is OpenRouter’s own published self-fusion result: Claude Opus 4.8 fused with itself, two copies of the same model, gained 6.7 percentage points on the DRACO benchmark over solo Claude Opus. The synthesis step itself does substantial work independent of model diversity. If a meaningful share of Fusion’s lift comes from synthesis alone, then the multi-model panel amplifies an effect that competent prompt engineering partly captures.

I keep the claim narrow: architectural diversity adds a measurable signal on top of synthesis for research synthesis tasks. That is what the adjacent evidence supports. Broader claims would be speculation.

What This Is Not

Three boundaries on this multi-model STORM research pipeline write-up.

This is not a benchmark paper. I am a practitioner evaluating my own tool using adjacent academic evidence, not a controlled experiment with power analysis. People who do that work should do it on this architecture. I am describing what I found, not what is true in general.

This is not a universal claim that multi-model Fusion beats single-model approaches on every task. The evidence is narrow. One pipeline, one research synthesis workload, one panel configuration. Code generation, conversational agents, creative writing, and real-time applications. I do not know how Fusion performs on those because I have DRACO and adjacent extrapolation.

This is not framework marketing. I use Hermes Agent, OpenRouter, and DeepSeek because they were the tools that worked. I am not affiliated with any of them. The contribution here is the pipeline pattern, not specific vendor choices.

Building Your Own Multi-Model STORM Research Pipeline

If you wanted to reconstruct this multi-model STORM research pipeline architecture, four components would get you there.

A multi-model fan-out layer. OpenRouter Fusion is one option. Manual fan-out using your provider API directly works. The requirement is that you can dispatch the same prompt to N models in parallel and collect all N responses without hand-wrangling context windows.

A judge or synthesis layer. DeepSeek V4 Flash at temperature zero works. So does any model that reliably produces structured output from multiple inputs. The job is to extract consensus, disagreement, unique coverage, and blind spots. Not to pick the winner. To analyze the spread.

An orchestration layer. An agent harness with native parallel delegation is the lowest-effort. A standalone async script with retry logic and rate management works if you prefer explicit control. The requirement is isolation between perspective runs and summary-only return to the parent context. Everything else is an implementation detail.

A human checkpoint after synthesis. This one is optional. Everything works without it. But if you are building for correctness rather than throughput, the post-synthesis validation gate is where the pipeline earns its keep.

The total tooling footprint consists of the orchestration framework you already run and a judge model. Panel models are free. The judge is cheap. The infrastructure you already have does the scheduling.

I went deep on the structural side of this same problem, separating raw sources from compiled, cross-linked knowledge, in a recent piece on why my Obsidian vault was already compliant with Google’s Open Knowledge Format. Different layer of the stack than Fusion, same underlying instinct: don’t trust one source, one model, or one format to do all the work.

What I Am Still Testing

Running against limitations without pretending they are features.

I need the controlled baseline: a single model, four diverse prompts, and synthesis, all with an equal token budget, on the same research topics. Without it, the architectural diversity claim sits on adjacent evidence.

I need a downscaled Phase 2.5. Simplify it to “top three things the panel is most confident about, human validates only those.” Removes most of the bottleneck while keeping the highest-value validation work.

I need to understand the co-failure ceiling. A 2026 paper proved that ensemble accuracy has a hard upper bound, given the rate at which all panel models fail on the same query. If my four free-tier models fail on the same five percent of queries, the glass ceiling is 95 percent regardless of synthesis quality. I have not measured that rate for my panel.

I need to know whether the pipeline produces better published content, not just better research notes. The original STORM paper measured outline quality and editor ratings. I should measure the same. Published post quality, reader engagement, and citation accuracy over time. These are open problems on my end.

Why It Matters

Not because everyone should run four models to write a blog post.

The AI research tooling landscape optimizes the model: bigger weights, longer context, more expensive inference. I am optimizing the harness around the model. Free-tier intelligence with cheap synthesis beats frontier-price intelligence alone on coverage. That should not surprise anyone. Four junior analysts with diverse backgrounds outperformed one senior analyst in open-ended research. Not because the junior analysts are smarter. Because they catch different things.

The compound system, research methodology, model diversity, synthesis, and human validation produce output that no single component could produce alone. That is the finding. Implementation is secondary.

I built this multi-model STORM research pipeline because I needed to trust the research before I could trust the writing. Now I do. That is worth 4.5 cents per run.

Repo: github.com/bmtrnavsky/storm-fusion-research-pipeline