From Score Improvement to Payment: The Illusion of Demand in Model Fusion

Authors: Yiping & David, IOSG

1. 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 the Fusion Router, titled Surpassing Frontier Performance with Fusion. In its DRACO deep research evaluation, the model group composed of Fable 5 and GPT-5.5 scored 69.0, surpassing the 65.3 score of the single Fable 5 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 review model compare and synthesize the results.

On June 29, Cognition released Devin Fusion, with the title Frontier Performance at 35% Lower Cost. It does not have multiple models repeat the entire task; instead, it assigns planning and judgment to the frontier model, while delegating tasks like testing and mechanical modifications to a cheaper sidekick, dynamically switching models during execution.

The same term points to two opposing economic logics. OpenRouter buys a higher ceiling with more computation; Cognition manages 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 the chance to exceed a single attempt. But 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 review model compares the results, and finally, one model outputs the answer. Devin Fusion does not fit 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 general term for all multi-model orchestration, while truly effective products are often moving 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, and it will be harder to become an independent category.

2. What options do models currently have?

Discussions about 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 cheaper models have crossed the business acceptance line, continuing to pay for "smarter" may not make economic sense. Cost efficiency is the true main line of the model market.

▲ Figure 2: Model intelligence and single-task cost, with the horizontal axis in logarithmic scale The most noteworthy aspect of the figure is not the highest score in the top right corner, but the points that deviate from the price—ability trend: they provide sufficient capability at a lower price and are efficiency outliers for specific workloads. A comprehensive index cannot directly answer which model is best for code review, Chinese studies, or regulated deployments, but it reveals a direction: model supply is being commoditized, and "strongest model" is separating from "optimal choice."

In the face of the same quality gap, there are currently four main purchasing methods in the market.

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 preferred 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 use a cheap model 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 a final answer through review and synthesis 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 links most likely to change the outcome; Fusion, however, pays for repeated opinions first, then bets that the review model can identify effective differences. Candidate models can only surpass the first three solutions if they provide enough independent information and the review 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 82.9% accuracy rate with an 84% cost reduction, saving over $3,600 per million requests according to paper calculations. The results still need to be replicated on the company'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 address quality gaps; only when these methods are still insufficient is there reason to purchase more candidate answers for Fusion.

3. Why does improving scores not equal value?

Because Fusion must simultaneously cross three thresholds: incremental quality must cover the additional costs and delays, candidate models must provide independent information, and the review must reliably identify better answers. If any one of these does not hold, score improvements cannot be converted into production value. Computational cost: How much budget and delay need to be added? The score improvement from Fusion is primarily a certain computational expenditure. OpenRouter will call multiple panel models in parallel, and then generate answers through review and synthesis models. All three groups in DRACO raised their 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; 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 benefits may come from additional search and sampling rather than cross-model knowledge complementarity. Fair comparisons 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 at most 7.1 percentage points under about 20 times the computational load; when budgets are the same, debate and Mixture-of-Agents only exceed self-consistency by 1.3 and 2.7 percentage points, while another study on equal reasoning tokens found that a single agent performs equally or better. Many "collaborative gains" will disappear after aligning the computational accounts.

▲ Figure 3: OpenRouter's benchmark improvements and product costs OpenRouter's default cost for a 3-model panel is about 4-5 times that of ordinary generation, 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 the 3.7 point improvement is worth it. The evaluation only included 100 pure text English tasks, and the Fable-related configurations only completed 93 tasks; changing the review model can move 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 range 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 has reached 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, then complete review and generation serially, thus tail delays concentrate on the most valuable tasks. Multi-vendor calls also expand the failure surface, auditing complexity, and privacy exposure. The costs of Fusion are not just the API price but also include waiting time and additional 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 tracing back to the same source but 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.

Josef Chen, co-founder and CEO of KAIKAKU.AI, studied 67 models from 21 service providers in the 2026 paper When Does Combining Language Models Help?. In open mathematical tasks, the predicted probability of all models answering incorrectly at the same time was 2.3%, but the actual measurement 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%. Replacing with 100 GPQA-Diamond questions, about 13 questions would lead all candidate models to answer incorrectly together, leaving no correct answers for voting, reviewing, or synthesizing. Discrepancies among models on easy questions can amplify the combined value, while on tail questions where insurance is most needed, they may fail together. Judging 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 identify related errors as high confidence; when candidates diverge, it must have sufficient expertise to choose correctly. Synthesis models may also erase key minority opinions or rewrite real divergences into definitive conclusions.

In coding tasks, compilers, testing, and static analysis are often more reliable than another model's opinion; in creative tasks, reviews and synthesis can easily compress differences into average answers. The strongest ready-made review model in LitBench only aligned with human creative writing preferences 73% of the time. When tasks already have cheap external validators, or "good" itself relies on subjective judgment, the score improvement from Fusion is hard to translate into payable value.

4. 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 form sustained payment. 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 single error avoidable loss must exceed the additional API costs, delays, operational complexity, and privacy risks.

Benchmark 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 tasks that meet these conditions are high-value research and due diligence, architecture and security reviews, and "second opinions" before irreversible decisions. Their commonality is incomplete constraints and high omission costs, and another 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 testing or rules typically do not require Fusion. Regulatory agencies may also refuse multi-vendor panels due to data boundaries and auditing requirements. From willingness to pay to sustainable demand Being technically useful can lead to high willingness to pay, but does not equal scalable demand. To form sustained demand, error losses must be quantifiable, tasks must occur repeatedly, 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 flow to professional audits, and irreversible decisions occur too infrequently.

Therefore, we are not optimistic about companies that only create multi-model wrappers, default to running panels, or treat static model selection algorithms as a moat. Connecting APIs is easy to replicate, 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 has actually corrected, it is impossible to price this insurance. The parties most likely to capture value are those who understand the real results: gateway and agent platforms, vertical applications, workflow owners, and evaluation and observability products. They know the cost of errors, can observe results, and can optimize triggering strategies. What is truly hard to replicate is not the panel list, but the judgment of when not to call Fusion. Market validation The open market is still insufficient to judge the scale of demand for Fusion, but it is already clear how it is being used. The Perplexity Model Council is only open to Max users at $200 per month and Enterprise Max users, where users 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 through browser automation. Hermes Mixture of Agents has made Fusion a selectable virtual model within agents: users can upgrade just one difficult question through /moa or continuously enable it in complex sessions, with multiple reference models providing analysis, and then the 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 the typical usage being proactive upgrades when a single model encounters bottlenecks, rather than default high-frequency automated 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.

5. 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 is not competing against yesterday's single model call, but against the continuously improving next-generation single models and orchestration baselines.

Cognition's Devin Fusion demonstrates the direction of this competition: leaving expensive models for judgment phases while delegating verifiable and mechanical work to cheaper models. In vendor self-testing, the total score of Fusion + Fable 5 slightly rose 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. Clearly defined boundaries and sufficiently tested ES6 refactoring rose from 98 to 100; React/Redux functions, which rely on interactive understanding and implicit requirements, dropped from 54 to 27 when 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 point clearly: the core capability of future multi-model systems is not to call more models, but to delineate the correct downgrade boundaries. Verifiable and mechanical tasks can be assigned to cheaper models, while judgment-intensive tasks must be reserved for frontier 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 was negotiating to acquire OpenRouter for about $10 billion, although the deal has not been 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 control for OpenRouter, allowing developers to create accounts, obtain API keys, and connect payments directly through Stripe Projects. What Stripe is truly likely to purchase is the transaction entry for AI inference: OpenRouter controls 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 the orchestration layer that can observe tasks, allocate calls, and complete settlements, while Fusion is merely a high-cost upgrade strategy on top of it.

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 reasoning, 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 independent category.

6. Sources

• OpenRouter: Surpassing Frontier Performance with Fusion

• OpenRouter Fusion Router documentation

• Cognition: Devin Fusion --- Frontier Performance at 35% Lower Cost

• Microsoft Research: Switchcraft --- AI Model Router for Agentic Tool Calling

• When Does Combining Language Models Help?

• Multi-Agent Reasoning Improves Compute Efficiency

• Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets

• Mixture-of-Agents Enhances Large Language Model Capabilities

• RouteLLM: Learning to Route LLMs with Preference Data

• LitBench: A Benchmark for Creative-Writing Evaluation

• Artificial Analysis model comparison

• The Price of Progress: Price Performance and the Future of AI

• Perplexity: What is Model Council?

• Perplexity user example: Model Council for financial research

• Hermes Agent: Mixture of Agents documentation

• Stripe powers OpenRouterʼs global AI model access

• Axios: Whatʼs behind Stripeʼs reported OpenRouter move