Author: Yiping & David @ IOSG

This article is for learning and communication purposes only and does not constitute any investment advice. Please cite the source when reprinting, and contact the IOSG team for authorization and reprint instructions. All projects mentioned in the article are not recommendations or investment advice.

What is Model Fusion?

In June 2026, the AI market saw two products named "Fusion" within less than three weeks.

On June 12, OpenRouter released Fusion Router, titled Surpassing Frontier Performance with Fusion. In its DRACO in-depth research evaluation, the model group consisting of Fable 5 and GPT-5.5 scored 69.0, surpassing the 65.3 score of the Fable 5 single model. OpenRouter’s selling point is straightforward: when a single model is not good enough, let multiple models answer the same question, and then let the review model compare and synthesize.

On June 29, Cognition released Devin Fusion, but its title was Frontier Performance at 35% Lower Cost. It did not have multiple models repeat the entire task, but rather let the frontier model handle planning and judgment, while assigning testing and mechanical modifications to a cheaper sidekick, dynamically switching models during execution.

The same term points to two opposing economic logics. OpenRouter uses more computation to purchase a higher ceiling; Cognition attempts to reduce expensive computation while maintaining the original quality. This contrast illustrates the issue better than any model ranking chart. The technical proposition of model fusion does indeed hold: multiple attempts have the opportunity to surpass a single attempt. But what the market truly rewards is not 'more model calls', but who can spend less and deliver faster after meeting quality thresholds.

▲ Figure 1: Two types of Fusion in the same month

This article defines Model Fusion as a narrower architecture: multiple models answer the same task in parallel, the review model compares results, and finally a single model outputs the answer. Devin Fusion does not fall under this definition; it is more closely aligned with dynamic routing and task delegation. The reason it is mentioned at the beginning is that the market is treating "Fusion" as a general term for all multi-model orchestration, while truly effective products often move away from the narrow definition of model fusion.

Our judgment is somewhat pessimistic: Model Fusion is an expensive quality insurance. It can improve the absolute performance of certain tasks, but it rarely truly pushes the efficiency frontier of cost-quality-latency outward. There are few tasks that justify purchasing this insurance. It will remain, but is more likely to become a low-frequency triggered feature rather than a default architecture, making it harder to become an independent category.

What options are currently available for models?

Discussing Fusion can easily lead to accuracy ranking discussions, but companies do not purchase ranking positions. Companies purchase a qualified result for a task while also calculating price, latency, privacy, and stability. As long as cheap models have

crossed the business acceptance line, continuing to pay for "smarter" might not make economic sense. Cost efficiency is the true main line of the model market.

▲ Figure 2: Model intelligence and single task cost, horizontal axis is on a logarithmic scale

The most noteworthy part of the image is not the highest score at the far top right, but the points that deviate from the price-capability trend: they provide sufficient capability at a lower price and are efficiency outliers on specific workloads. The comprehensive index cannot directly answer which model is best for code review, Chinese research, or regulated deployment, but it reveals a direction: model supply is being commoditized, “strongest model” and “optimal choice” are separating.

In the face of the same quality gap, the market currently has four main purchasing methods.

The first method is to directly upgrade to a stronger single model. It is the simplest and easiest to audit; as long as the marginal price increase of high-end models is lower than the cost of errors or rework, this is usually still the top choice. The second method is to increase calculations when testing the same model, such as extending reasoning, self-consistency, or multiple sampling. The third method is routing, cascading, and task delegation: first use cheap models to handle verifiable or mechanical parts, upgrading only when difficulties are encountered. The fourth is the narrow Model Fusion: letting multiple models answer the same question repeatedly, then using review and synthesis models to form the final answer.

All four methods can "trade more computation for quality," differing in where the computation is spent. Single model expansion buys deeper reasoning, routing purchases more accurate resource allocation, while Fusion buys more candidate answers. The first three methods concentrate the budget on the link most likely to change the outcome; Fusion pays for repeated opinions first and then bets that the review model can identify effective differences. Candidate models can only surpass the first three schemes if they provide sufficient independent information and the review can recognize this information.

Routing has already demonstrated that the capability differences between models represent a scheduling opportunity. RouteLLM has reduced costs by more than 2 times in some evaluations without sacrificing quality; Switchcraft achieved an 82.9% accuracy rate with an 84% cost reduction, estimated by the paper to save over $3,600 per million requests. Results still need to be replicated on the enterprises' own traffic, but the economic logic is clear: there is no need for multiple models to have meetings, just assign each task to the cheapest qualified model.

This means that the market will first use upgrades, routing, and verification to address quality gaps; only when these methods are still insufficient is there reason to purchase more candidate answers for Fusion.

Why does a score increase not equal value?

Because Fusion must simultaneously cross three thresholds: the incremental quality must cover the additional costs and delays, candidate models must provide independent information, and the reviews must stably identify better answers. If any of these does not hold, the score improvement cannot transform into production value.

Computational Cost: How much budget and delay need to be added?

The score increase from Fusion is primarily a definitive computational expenditure. OpenRouter will call multiple panel models in parallel, then generate answers through review and synthesis models. All three groups of controls in DRACO showed increased scores: Fable 5 + GPT-5.5 increased from 65.3 to 69.0; Opus 4.8 self-fusion went from 58.8 to 65.5; the low-cost three-model group increased from 60.3 to 64.7.

However, the larger improvement from Opus self-fusion indicates that the gains may come from additional searches and sampling, rather than cross-model knowledge complementarity. A fair comparison should evaluate self-consistency, longer reasoning, and strong single models under the same token budget. Existing research also shows: multi-agent systems can improve by up to 7.1 percentage points under about 20 times the computation; when budgets are aligned, debate and Mixture-of-Agents only surpass self-consistency by 1.3 and 2.7 percentage points, while another reasoning-token study found a single agent performed equally or better. Many "collaborative gains" will disappear after aligning computational accounts.

▲ Figure 3: Benchmark increases and product costs of OpenRouter

The default cost of the three-model panel of OpenRouter is approximately 4-5 times that of ordinary generation, 2-3 times slower, but it has not disclosed the complete tokens, costs, and delays of each DRACO configuration, making it impossible to determine if the 3.7 score increase is worth it. Evaluations also had only 100 pure text English tasks, with Fable-related configurations only completing 93; switching review models can move the absolute score by 10-25 percentage points. It proves that Fusion can increase scores, but does not prove that Fusion improves production ROI.

Selective calls can only dilute costs. Based on the intervals disclosed by OpenRouter, at a trigger rate of 1%, overall costs are about 1.03-1.04 times; at 10%, it’s 1.30-1.40 times; and at 25%, it reaches 1.75-2.00 times.

▲ Figure 4: Overall economics of selective calling Fusion

The most difficult requests are most likely to trigger Fusion, but the system must wait for the slowest panel member and then serially complete the review and generation, thus tail latency concentrates on the most valuable tasks. Multi-vendor calls also expand the failure surface, audit complexity, and privacy exposure. The costs of Fusion are not just the API prices, but also include wait times and new system risks.

Information Complementarity: Do multiple models really provide different information?

The value of Fusion depends on whether candidate models bring independent information, but different models often share training corpuses, web sources, and erroneous assumptions. In research tasks, this can lead to "citation laundering": multiple models tracing back to the same source, yet repackaged as independent evidence. If the system does not retain claim-level provenance and search paths, as the number of models increases, API costs rise almost linearly, while the diversity of evidence may not increase.

Josef Chen, co-founder and CEO of KAIKAKU.AI, studied 67 models from 21 providers in his 2026 paper When Does Combining Language Models Help?. In an open mathematics task, the predicted probability of all models answering incorrectly simultaneously was 2.3%, but the actual measured rate reached 5.2%—about 2.3 times the predicted value; the joint failure rate of the scoring code task and the open-answer version GPQA-Diamond further rose to 7.9% and 12.7%.

When replaced with 100 GPQA-Diamond tasks, approximately 13 questions would cause all candidate models to incorrectly answer together, leaving no correct answers for voting, reviewing, or synthesizing. The discrepancies of models on easy questions amplify the combined value, while on the tail problems where insurance is most needed, they may instead fail together.

Judgment Reliability: Can the system identify and synthesize better answers?

Even if candidate answers are complementary, value still depends on the review. When candidates are consistent, the review may mistakenly recognize related errors as high confidence; when candidates diverge, it must possess sufficient expertise to choose correctly. The synthesis model may also erase key minority opinions or rewrite genuine divergences into definite conclusions.

In code tasks, compilers, tests, and static analysis are often more reliable than another model’s opinion; in creative tasks, reviews and syntheses are also likely to average out differences into a mean answer. The strongest off-the-shelf review model in LitBench only aligns with human creative writing preferences at 73%. When tasks have cheap external validators, or "good" itself relies on subjective judgment, the score increase from Fusion is difficult to convert into payable value.

Who will pay for Fusion?

The demand for Fusion depends on two thresholds: whether tasks can benefit from multiple models, and whether such benefits are sufficient to generate sustained payment. The former is a technical issue, and the latter is a market issue.

From Technical Applicability to Economic Validity

The probability of correcting mistakes multiplied by the single mistake cost avoided must exceed the additional API costs, delays, operational complexities, and privacy risks.

Benchmark scores cannot answer this profitability question. Fusion is only valid when the cost of mistakes is high, candidate models provide complementary search paths, there are no cheaper external validators, and the business can accept extra delays and vendor risks; the final result should still be confirmed by humans or external evidence.

▲ Figure 5: From technical applicability to sustainable demand

The main suitable areas include high-value research and due diligence, architectural and security reviews, and "second opinions" before irreversible decisions. Their commonality is incomplete constraints and high omission costs, where another independent idea is valuable in itself. In contrast, routine coding, real-time consumer applications, high-throughput low-margin workflows, and tasks that can be directly validated by tests or rules generally do not require Fusion. Regulatory bodies may also refuse multi-vendor panels due to data boundaries and audit requirements.

From Willingness to Pay to Sustainable Demand

Technical usefulness can lead to high willingness to pay, but does not equate to scalable demand. To form sustained demand, the cost of mistakes must be quantifiable, tasks must occur repeatedly, and there must be clear budget responsibility within the organization. Fusion must also continually outperform human experts, strong single models, and external validations. However, due diligence budgets often flow to analysts and credible sources, security budgets flow to professional audits, and irreversible decisions rarely occur.

Therefore, we are not optimistic about companies that simply do a multi-model wrapper, default run panels, or treat static model selection algorithms as a moat. Connecting APIs is easy to replicate, and fixed strategies will rapidly become ineffective as model capabilities and prices change; if one does not know how much an error is worth or how many times Fusion actually corrected something, it’s impossible to price this insurance. The parties most likely to capture value are those that have a grasp on real outcomes: gateway and agent platforms, vertical applications, workflow owners, and evaluation and observability products. They know the costs of errors, can observe results, and can optimize trigger strategies. The truly hard-to-replicate aspect is not the panel list, but the judgment of when not to call Fusion.

Market Validation

The public market is not yet sufficient to determine the scale of demand for Fusion, but it is already apparent how it is being used. The Perplexity Model Council is only available to Max users and Enterprise Max users who pay $200 per month, allowing them to manually select three models via the web for investment research, complex decisions, and information verification; public user cases include integrating the Model Council into stock research processes via browser automation. Hermes Mixture of Agents has made Fusion a virtual model that can be selected among agents: users can upgrade a difficult question via /moa or continuously enable it in complex sessions, with analyses provided by multiple reference models, then called upon by an aggregator to complete the task. Hermes later reduced the default fan-out frequency, reusing opinions from the previous cycle to control costs. These cases illustrate that the real demand for Fusion is concentrated in low-frequency difficult tasks such as research, debugging, review, and important decision-making, with the typical usage being proactive upgrades when a single model hits a bottleneck, rather than a default, high-frequency automation process. Existing evidence proves that this demand exists, but public information is still insufficient to determine whether it can form an independent, scalable paid market.

The Future of Fusion

The decline in reasoning costs superficially favors Fusion, but it will also reduce the costs of strong single models, routing, and external validation simultaneously. Fusion is not competing against yesterday's model call, but against the continuously improving next-generation single models and orchestration baselines.

Cognition's Devin Fusion demonstrates the direction of this competition: keeping expensive models for judgment phases, while assigning verifiable and mechanical tasks to cheaper models. In vendor self-tests, the score of Fusion + Fable 5 slightly rose from 57.0 to 57.6, while average costs dropped from $5.12 to $3.00; however, in the five published cases, costs decreased by 25%-62%, while task scores fluctuated between +12 and -27. Clearly defined boundaries and thoroughly tested ES6 refactoring rose from 98 points to 100 points; however, React/Redux functions that rely on interactive understanding and implicit requirements fell from 54 points to 27 points due to erroneous delegation.

▲ Figure 6: Task scores and costs of Devin Fusion

These are cases selected by vendors and do not represent the overall distribution, but point clearly: the core capability of future multi-model systems is not to call more models, but to delineate the correct degradation boundaries. Verifiable, mechanical tasks can be delegated to cheaper models, while judgment-intensive tasks must be reserved for frontier models. OpenRouter sells "more intelligence," Cognition sells "the same intelligence, at a lower cost"; the latter proposition is closer to the long-term direction. In late July, media reported that Stripe was negotiating to acquire OpenRouter for about $10 billion, although the deal has yet to be confirmed. This signal should not be interpreted as Fusion having gained market validation: OpenRouter's core value is not a specific panel, but a neutral calling layer connecting over 5 million developers with more than 400 models. Stripe has already provided billing, tax, and risk management for OpenRouter, and allows developers to create accounts, obtain API keys, and proceed with payments directly through Stripe Projects. What Stripe may actually be purchasing is the transaction entry for AI reasoning: OpenRouter governs model selection, token usage, and costs, while Stripe handles pricing, billing, and payments. This provides a market signal for the value judgment discussed earlier: the value in the multi-model era is more likely to remain with those who can observe tasks, allocate calls, and finalize settlements, with Fusion merely being a high-cost upgrade strategy on top of that.

Future multi-model systems will not default to convening panels but will first estimate task difficulty, validation costs, and error losses; only when stronger single models, extended reasoning, and external tools are still insufficient, will it enter multi-model discrepancy searches. Trigger rates, incremental success rates, and verified unit result costs will be the meaningful product indicators. Fusion will remain as a low-frequency feature rather than becoming a default architecture or an independent category.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。