IOSG: From Score Improvement to Payment, The Illusion of Demand for Model Fusion

Author: Yiping & David @ IOSG

This article is for educational and communication purposes only and does not constitute any investment advice. Please indicate the source when reprinting and contact the IOSG team for authorization and reprinting guidelines. All projects mentioned in this article are not recommendations or investment advice.

What is Model Fusion?

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

On June 12, OpenRouter released Fusion Router, titled Surpassing Frontier Performance with Fusion. In its DRACO deep 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 have a reviewing model compare and synthesize the results.

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 instead had the leading model responsible for planning and judgment, while delegating testing, mechanical modifications, and other tasks to a cheaper sidekick, dynamically switching models during execution.

The same term points to two opposing economic logics. OpenRouter buys higher limits with more computation; Cognition attempts to reduce expensive computation while maintaining existing quality. This contrast illustrates the issue better than any model ranking. The technical proposition of model fusion is indeed valid: multiple attempts have a chance to exceed a single attempt. However, the market truly rewards not "calling more models" but rather 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, a reviewing model compares the results, and finally, one model outputs the answer. Devin Fusion does not fall under this definition; it is closer to dynamic routing and task delegation. It is placed at the beginning because the market is treating "Fusion" as a generic 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 rarely pushes the efficiency frontier of cost—quality—delay outward. There are few tasks truly worth 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 rankings, but companies do not purchase ranking positions. Companies buy qualified results for a task while also considering price, delay, privacy, and stability. As long as a cheaper model has crossed the business acceptance line, continuing to pay for "smarter" may not make economic sense. Cost efficiency is the true mainline of the model market.

▲ Figure 2: Model Intelligence vs. Single Task Cost, with the horizontal axis on a logarithmic scale

The most noteworthy aspect of the chart is not the highest score in the top right corner but the points deviating from the price—ability trend: they provide sufficient capability at a lower price and are efficiency outliers on specific workloads. The composite index cannot directly answer which model is best for code review, Chinese studies, or regulated deployments, but it reveals a direction: model supply is becoming commoditized, and "strongest model" is separating from "optimal choice."

Facing the same quality gap, the market currently has four main purchasing methods.

The first 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 the high-end model is lower than the cost of errors or rework, this is usually still the first choice. The second is to increase computation on the same model during testing, such as extending inference, self-consistency, or multiple sampling. The third is routing, cascading, and task delegation: first using cheaper models to handle verifiable or mechanical parts, only upgrading when difficulties arise. The fourth is the narrow definition of Model Fusion: having multiple models repeatedly answer the same question, and then forming the final answer through reviewing and synthesizing models.

All four methods can "exchange quality for more computation," with the difference being where the computation is spent. Single model expansion purchases deeper reasoning, routing purchases more accurate resource allocation, while Fusion purchases more candidate answers. The first three methods concentrate the budget on the segments most likely to change the outcome; Fusion, however, pays for repeated opinions first and then bets that the reviewing model can identify effective differences. Candidate models can only surpass the first three solutions if they provide enough independent information and the reviewer can recognize this information.

Routing has already proven that the ability differences between models are primarily a scheduling opportunity. RouteLLM has reduced costs by more than 2 times in some evaluations without sacrificing quality; Switchcraft achieved an 84% cost reduction with an accuracy of 82.9%, estimating savings of over $3,600 per million requests according to the paper. The results still need to be replicated on the enterprise's own traffic, but the economic logic is straightforward: there is no need to have multiple models in a meeting; just assign each task to the cheapest qualified model.

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

Why Does Score Improvement Not Equal Value?

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

Cost Calculation: How Much Budget and Delay Need to Be Added?

The score improvement from Fusion is primarily a definite computational expenditure. OpenRouter will call multiple panel models in parallel, and then generate answers through reviewing and synthesizing models. All three groups in DRACO have improved scores: Fable 5 + GPT-5.5 rose from 65.3 to 69.0; Opus 4.8 self-fusion rose from 58.8 to 65.5; and the low-cost three-model group rose from 60.3 to 64.7.

However, the improvement of Opus self-fusion is greater, indicating that the gains may come from additional search and sampling rather than cross-model knowledge complementarity. A fair comparison should consider self-consistency, longer reasoning, and strong single models under the same token budget. Existing research also shows that multi-agent systems can improve by up to 7.1 percentage points under approximately 20 times the computational load; when budgets are the same, debate and Mixture-of-Agents are only 1.3 and 2.7 percentage points higher than self-consistency, while another reasoning-token study found that a single agent is on par or better. Many "collaborative gains" may disappear after aligning computational accounts.

▲ Figure 3: OpenRouter's Benchmark Improvement and Product Cost

OpenRouter's default cost for a 3-model panel is about 4-5 times that of ordinary generation, and it is 2-3 times slower, but it has not disclosed the complete token, cost, and delay for each DRACO configuration, making it impossible to determine whether a 3.7-point improvement is worth it. The evaluation only included 100 pure text English tasks, and Fable-related configurations completed only 93 items; changing the reviewing model could shift absolute scores by 10-25 percentage points. It proves that Fusion can improve scores but does not prove that Fusion improves production ROI.

Selective calling can only dilute costs. According to the ranges disclosed by OpenRouter, when the trigger rate is 1%, the overall cost is about 1.03-1.04 times; at 10%, it is 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 challenging requests are most likely to trigger Fusion, but the system must wait for the slowest panel member, then complete reviewing and generation serially, so tail delays concentrate on the most valuable tasks. Multi-vendor calls also expand the fault surface, audit complexity, and privacy exposure. The costs of Fusion are not just API prices but also include waiting 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 corpora, web sources, and erroneous premises. In research tasks, this can lead to "citation washing": multiple models trace back to the same source but are packaged as multiple independent pieces of 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 evidence diversity may not necessarily increase.

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

When switching to 100 GPQA-Diamond questions, approximately 13 questions would cause all candidate models to answer incorrectly, leaving no correct answers available for voting, review, or synthesis. Discrepancies among models on easier questions amplify the value of combination, while they may fail together on tail-end questions where insurance is most needed.

Assessing Reliability: Can the System Identify and Synthesize Better Answers?

Even if candidate answers are complementary, their value still depends on the review process. When candidates are consistent, reviewers may mistakenly interpret related errors as high confidence; when candidates diverge, they must possess sufficient expertise to select correctly. Composite models may also erase key minority opinions or rewrite genuine discrepancies into definitive conclusions.

In coding tasks, compilers, tests, and static analysis are usually more reliable than another model's opinion; in creative tasks, reviews and composites can easily compress differences into average answers. The strongest ready-made review model in LitBench only aligns with human creative writing preferences 73% of the time. When tasks already have cheap external validators, or when "good" itself relies on subjective judgment, the score improvement from Fusion is hard to translate 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 this benefit is sufficient to create sustained payments. The former is a technical issue, while the latter is a market issue.

From Technical Applicability to Economic Viability

The probability of correcting errors multiplied by the loss avoidable per error must exceed the added costs of API, delays, operational complexity, and privacy risks.

Baseline scores cannot answer this profit and loss question. Fusion is only likely to be viable when the cost of errors is high, candidate models provide complementary search paths, there are no cheaper external validators, and the business can accept additional delays and vendor risks; the final results should still be confirmed by humans or external evidence.

▲ Figure 5: From Technical Applicability to Sustainable Demand

The main areas that meet these conditions are high-value research and due diligence, architecture and security reviews, and "second opinions" before irreversible decisions. Their commonality lies in incomplete constraints and high omission costs, where an independent line of thought is valuable in itself. In contrast, routine coding, real-time consumer applications, high-throughput low-margin workflows, and tasks that can be directly verified by tests or rules typically do not require Fusion. Regulatory bodies may also reject 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 it does not equate to scalable demand. To form sustained demand, error losses must be quantifiable, tasks must recur, there must be clear budget owners within the organization, and Fusion must continuously outperform human experts, strong single models, and external validation. However, due diligence budgets often flow to analysts and trusted sources, security budgets go to professional audits, and irreversible decisions occur too infrequently.

Therefore, we are not optimistic about companies that merely create multi-model wrappers, default to running panels, or treat static model selection algorithms as a moat. Connecting APIs is easily replicable, and fixed strategies will quickly 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 errors, pricing this insurance becomes impossible. Those most likely to capture value are the parties that possess the real results: gateway and agent platforms, vertical applications, workflow owners, and evaluation and observability products. They understand error costs, can observe outcomes, and can optimize triggering strategies. What is truly difficult to replicate is not the panel list, but the judgment of when not to invoke Fusion.

Market Validation

The public market is still insufficient to assess the scale of demand for Fusion, but it is already evident how it is being used. The Perplexity Model Council is only open to Max users and Enterprise Max users at $200 per month, allowing users to manually select three models for investment research, complex decision-making, and information validation; public user cases include integrating the Model Council into stock research processes via browser automation. Hermes Mixture of Agents has turned Fusion into a selectable virtual model within agents: users can upgrade a single difficult question via /moa or continuously enable it in complex sessions, with multiple reference models providing analysis, followed by an aggregator calling tools to complete tasks. Hermes later reduced the default fan-out frequency, reusing the previous round of model opinions 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 typical usage being proactive upgrades after single models hit bottlenecks, rather than default high-frequency automation processes. 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 inference prices superficially benefits Fusion, but it will also simultaneously lower the costs of strong single models, routing, and external validation. Fusion does not compete with yesterday's model call, but with the continuously improving next generation of single models and orchestration baselines.

Cognition's Devin Fusion showcases the direction of this competition: keeping expensive models for judgment phases while assigning verifiable, mechanical tasks to cheaper models. In vendor self-tests, the total score of Fusion + Fable 5 slightly increased from 57.0 to 57.6, while the average cost 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. The clearly defined and thoroughly tested ES6 refactor rose from 98 to 100 points; however, the React/Redux functionality, which relied on interactive understanding and implicit needs, fell from 54 points to 27 points after being incorrectly delegated.

▲ Figure 6: Task Scores and Costs of Devin Fusion

These are cases selected by vendors and do not represent the overall distribution, but they point clearly: the core capability of future multi-model systems is not to call more models, but to delineate the correct downgrade boundaries. Verifiable, mechanical tasks can be assigned to cheaper models, while judgment-intensive tasks must be reserved for cutting-edge models. OpenRouter sells "more intelligence," while Cognition sells "equivalent intelligence at a lower cost"; the latter proposition is closer to the long-term direction. The closer a system is to production economics, the less it resembles narrow Model Fusion and the more it resembles routing, delegation, and validation.

In late July, media reports indicated that Stripe is negotiating to acquire OpenRouter for about $10 billion, although the deal has not been confirmed. This signal should not be interpreted as Fusion having already gained market validation: the core value of OpenRouter 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 control for OpenRouter, allowing developers to create accounts, obtain API keys, and connect payments directly through Stripe Projects. What Stripe is likely to purchase is the transaction entry for AI inference: OpenRouter manages model selection, token usage, and costs, while Stripe handles pricing, billing, and payments. This provides a market signal for the value judgment mentioned earlier: the value in the multi-model era is more likely to remain with those who can observe tasks, allocate calls, and complete settlements in the orchestration layer, while Fusion is merely 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, verification costs, and error losses; only when stronger single models, extended inference, and external tools are still insufficient will they enter multi-model divergence searches. Trigger rates, incremental success rates, and verified unit result costs will be the meaningful product metrics. Fusion will remain as a low-frequency feature rather than becoming a default architecture or an independent category.