OpenRouter launched Fusion, a compound model that spreads a single prompt across several frontier models and merges their replies into one answer. Cognition, the startup behind the Devin coding agent, entered the same space within about six weeks of that release. Jerry Liu, founder of LlamaIndex, the open-source framework for retrieval and agent orchestration, flagged the pattern in a July 15 post on X: two well-capitalized companies shipped competing routers inside the same short window, and neither is treating routing as a side feature.
The stated goal behind both products is sound. No team wants frontier-model pricing on every token when a cheaper model would have returned the same answer. That is the correct problem to solve. Panel-style routing, querying multiple large models per request and synthesizing a consensus reply, is the wrong way to solve it.
Fanning one prompt out to several frontier models multiplies token spend on every call, even when the final output is a single answer. That is closer to an ensemble technique built for accuracy than a cost-control mechanism. It may raise quality on hard, ambiguous prompts. It does not obviously lower the bill, and it adds the latency of waiting on the slowest model in the panel before synthesis can happen. Neither OpenRouter nor Cognition has published cost or latency figures comparing this approach to narrower, workflow-specific routing, so the tradeoff remains unverified by either company.
Liu’s underlying claim is the more useful one: routing value concentrates at the task level, not the platform level. The narrower the workflow, the more a builder can exploit the gap between what a cheap model can already do and what a frontier model would cost to do instead. A support-ticket classifier, a unit-test generator, and a contract-clause extractor each have a different accuracy ceiling for each candidate model, and that ceiling has to be measured per task, not assumed from a general leaderboard.
That measurement is the actual hard problem, and it is where both new products still leave the work to the customer. Determining which model clears the accuracy bar for a specific task, at an acceptable cost and latency, requires a task-specific eval harness: real examples from that workflow, a scoring method tied to what “correct” means for that task, and a sweep across candidate models at their actual price points. A generic compound router cannot shortcut that process because it has no visibility into what any individual customer’s workflow actually requires.
This has an obvious precedent. Recommendation systems went through the same shift a decade ago, moving away from single global models toward hundreds of narrow, task-tuned rankers, because a model optimized for everything is optimized for nothing in particular. Model routing looks headed the same direction: fewer general-purpose panels, more per-workflow routers built on evals the customer owns.
Teams evaluating Fusion or Cognition’s router should not treat either as a drop-in cost fix. Build the task-specific eval harness first, on the two or three highest-volume workflows, before adopting a general router; the harness will tell you whether a compound model is buying accuracy you need or margin you are giving away.
Jerry Liu, founder of LlamaIndex, posted this analysis on X on July 15, 2026.
