OpenRouter Launches Fusion Multi-Model Intelligent Fusion Service
OpenRouter, a US-based AI middleware platform, has launched "Fusion," a service that orchestrates multiple large language models to outperform single flagship models. By combining panel models and a judge model, Fusion achieved higher scores in the DRACO benchmark than individual models like GPT-5.5 or Opus 4.8. While inspired by ensemble learning, Fusion's advantage lies in engineering closed-source model collaboration and diverse tool usage. Despite higher latency and costs, it suggests a shift in how AI capability is measured, potentially compressing flagship model premiums while elevating middleware value.
A mini-game called "Synthetic Watermelon" was once popular. Its gameplay is simple: two identical fruits collide to become a larger one. Grapes synthesize into cherries, cherries into oranges, with the ultimate goal of synthesizing a watermelon.
What happens if this logic is applied to the AI field?
Recently, US large model aggregation platform OpenRouter actually created a product capable of "synthesizing large AI," named Fusion. In benchmark tests, three mid-priced models, through reasonable orchestration by Fusion, systematically outperformed all single flagship models of the same period. Moreover, combining three identical models yielded scores higher than the original model answering alone.
Survival Anxiety of Middleware Platforms Spawned Fusion
Founded in 2023, OpenRouter is headquartered in New York, US, and is a startup providing an AI middleware layer.
Co-founder Alex Atallah was previously an engineer at Palantir and co-founded the globally renowned NFT trading platform OpenSea in 2017. Another co-founder, Louis Vichy, is a serial entrepreneur focused on developer tools and platform-layer products.
OpenRouter provides developers with a unified API gateway, accessing over 400 large language models, covering major vendors like OpenAI, Anthropic, Google, Kimi, DeepSeek, etc., with a profit model of charging a 5% commission.
According to disclosed data, since its establishment, the platform's monthly consumption amount has grown from about $800,000 in October 2024 to about $8 million in May 2025. The platform's weekly routed token quota has reached the level of 25 to 27 trillion. In terms of financing, in less than three years, OpenRouter has entered the unicorn ranks.
However, its biggest business risk is being bypassed: once a leading model clearly dominates in a certain scenario, developers can directly access that vendor's API without paying extra commission to OpenRouter.
To address this crisis, Fusion emerged. They aim to provide cross-vendor model collaboration that no single model vendor can offer.
Functionality Implementation and Actual Performance
Fusion's architecture is roughly as follows: Users specify a caller model in the API request. The caller model decides to enable Fusion. The system distributes prompts in parallel to several panel models. Each model simultaneously enables three server-side tools, including web search, web scraping, and bash command execution (the most common command-line interpreter for Linux and macOS systems).
After panel models complete tasks independently, a judge model reads all answers and produces a structured JSON analysis. Finally, the caller model writes the final answer based on this analysis, without enabling web search tools during the writing phase. By default, the judge model and caller model are the same model.
The entire process is encapsulated on the server side. Developers only need to fill the model field as "openrouter/fusion" to call the entire toolset. Panel members and judge models can be customized by users.
To avoid infinite nesting of orchestration, each internal request carries an "x-openrouter-fusion-depth" header, preventing panel models and judge models from recursively calling Fusion.
Having discussed the mechanism, how does Fusion actually perform in benchmark tests?
In February 2026, Perplexity open-sourced a benchmark test named DRACO, containing 100 deep research tasks. These questions stem from real user requests collected by the platform. Scoring criteria cover four dimensions: factual accuracy, breadth and depth of analysis, presentation quality, and citation quality. Some criteria have negative weights; models are penalized for errors or dangerous suggestions, making strategies like padding word count ineffective.
Fusion's test results on DRACO show that a dual-panel composed of Fable 5 and GPT-5.5 (synthesized model is Claude Opus 4.8) scored 69.0. In comparison, Fable 5 alone scored 65.3, and GPT-5.5 alone scored 60.0.
(Source: OpenRouter)
Among low-cost models, Fusion demonstrates a high cost-performance advantage. Three relatively economical models, Gemini 3 Flash, Kimi K2.6, and DeepSeek V4 Pro, achieved 64.7 points after synthesis, exceeding standalone Opus 4.8 (58.8 points) and GPT-5.5 (60.0 points), but with overall reasoning costs only half of frontier models.
OpenRouter also paired Opus 4.8 with Opus 4.8 to form a "twin panel," with the judge and caller models also being Opus 4.8. Results show this self-synthesized combination scored 65.5, which is 6.7 points higher than testing Opus 4.8 alone.
Researchers unexpectedly found during testing that after enabling web search, some models retrieved DRACO's scoring criteria. This unconscious cheating constituted data contamination. The team subsequently blocked relevant pages uniformly through a domain exclusion mechanism. The final published content reflects performance after blocking.
Ensemble Learning Has Existed for a Long Time, Where Is the Moat?
The idea of combining multiple models to improve performance dates back to the 1990s. Machine learning has a tradition of Ensemble Learning. Classic methods like Random Forest and Boosting are built on "multiple weak models beating a single strong model."
Entering the large language model era, one of the most representative works of this strategy is the dual-module ensemble framework LLM-Blender released in 2023: one module picks the best from candidate answers of multiple open-source models; the other module gives the top-scoring candidates and the original question to a fusion model to generate a comprehensive answer.
Figure | LLM-Blender Architecture (Source: DOI: 10.18653/v1/2023.acl-long.792)
It is not hard to see that Fusion's "panel model + judge model" solution is highly similar to the structure of the veteran LLM-Blender: parallel calling of multiple models, letting a more capable model read all answers and output an answer.
The result that "three Opus 4.8s are stronger than one Opus 4.8" actually echoes the concept of self-consistency: sampling the same model independently multiple times for the same question and then voting usually yields better results than a single output.
However, Fusion's value lies not in the algorithm. Scheduling collaboration of closed-source models, engineering encapsulation, and diverse tool calls are its true moat.
Ensemble research requires access to internal parameters like model weights and raw calculation results, requiring at least knowledge of the complete probability distribution. Therefore, most academic work is based on open-source models. However, currently the most capable models are mostly closed-source, accessible only via API for text output. For OpenRouter to do ensemble across closed-source models, it must simultaneously possess access permissions from multiple vendors and stable scheduling capabilities.
Secondly, a usable multi-model ensemble process needs to handle concurrent calls, timeout and failure fallback, synthesis prompt templates, cost accounting, load balancing, etc. For general development teams, this is a significant engineering investment. Fusion encapsulates the entire process into a single API call, greatly lowering the operational threshold for developers.
Third is the diversity at the tool call level. Traditional ensemble research mostly involves pure text Q&A, where differences between multiple models mainly reflect in generation strategies. When Fusion executes tasks, each panel model calls retrieval and filtering tools independently. For tasks requiring high information coverage, the final synthesized result not only integrates multiple reasoning paths but also covers multiple independent information sources, surpassing the performance of single-model multiple sampling.
Product Is Imperfect, But Promises to Redefine the Unit of Large Model Capability
OpenRouter explicitly states that Fusion is not suitable as a direct replacement for programming models. Choosing DRACO as a benchmark is more about evaluating its performance in single-turn deep research tasks, not covering scenarios like programming, real-time dialogue, multimodal, etc. Long-cycle tasks where the Fable series excels are also not within the test scope.
After calling Fusion, the single response time is usually 2 to 3 times that of normal calls. Parallel reasoning of multiple panel models plus one synthesis reasoning stacks, making overall costs far higher than single-model solutions, and time consumption will also rise significantly.
It should be noted that the upper limit of Fusion's synthesis quality depends on the judge model's understanding and induction capabilities. Currently selecting Opus 4.8 as the judge yields good results temporarily. But when task complexity continues to rise and panel models' comprehensive capabilities approach or exceed existing strongest models, judgment and output by a single model will become unreliable. Considering models may have systematic biases, there is ongoing controversy in academia regarding letting large models act as judges.
Beyond product limitations, Fusion has raised a more noteworthy issue: the unit of large model capability will be redefined. Single model performance may no longer be the sole orientation for user selection.
Leading vendors compete around the capability limits of single models, escalating parameter scale, training data, and alignment methods in turns. Fusion, however, confirms a possibility: orchestration technology systematically combining multiple mid-tier models can reach levels close to or exceeding flagship models.
If this rule is proven effective in more scenarios, the premium space for flagship models will be compressed. But for middleware like OpenRouter, stronger control capabilities will upgrade it from an API intermediary to a value-creating link.
Imagine if panel models expand from 2 to 10, and the synthesized model itself can be served by multi-model ensemble. When more tools like code execution and long-term memory are included in this framework, how big the final synthesized "watermelon" can grow is anyone's guess.
References:
https://openrouter.ai/blog/announcements/fusion-beats-frontier/
https://openrouter.ai/docs/guides/features/server-tools/fusion
https://arxiv.org/abs/2602.11685
https://aclanthology.org/2023.acl-long.792/
Note: Cover/First image generated with AI assistance.
This page provides an editorial summary based on publicly available information. It is not a republished article. Use the source link below for the original report.