Not every hard problem needs a bigger model. Some just need a handful of ordinary models that know how to help each other.

Fusion-MOA: a 27B open-source lineup that outperforms a 1.6-trillion-parameter cloud flagship on real engineering benchmarks — at 1/18th the token cost.

1. Even flagship models go in circles Throwing more budget at a stuck coding agent doesn’t necessarily pull it out of the loop it’s stuck in. Picture the scenario: an eight-year-old codebase, a bug that’s sat unclaimed in the issue tracker for three months, handed off to the strongest cloud model the team has access to. It gets to work — reading code, making a change, running tests, hitting an error, revising, erroring again. By round 9, it has quietly rolled its own edit back to what it looked like in round 3. By round 14, it’s drifted there again. The issue isn’t capability — it’s that this particular reasoning path has hit a dead end, and the model doesn’t realize it. The billing system, on the other hand, is perfectly aware: tokens keep draining, the context window keeps swelling, and the bug sits exactly where it started. This isn’t an isolated case. Reviewing our own failure logs, a meaningful share of agentic task failures trace back not to insufficient capability, but to the model being stuck in a loop with nothing around to detect it and step in — the same move repeated, context exhausted, the run eventually forced to stop on a timeout. What’s notable is that around June, several parts of the industry converged on a similar direction independently: OpenRouter shipped a Fusion feature, letting multiple models answer separately before merging into a best output; Hermes built Mixture of Agents into an official capability; Cursor took it further still, deploying a swarm of over a thousand agents to rewrite the entire SQLite codebase. A bottleneck one model can’t get past, a group working together sometimes can. That raises a practical concern, though: does assembling “a group of models” mean standing up a GPU cluster first, and budgeting for a substantial pile of tokens? Over the past six months we tested a somewhat counterintuitive answer and turned it into a product: Fusion-MOA. The whole system runs on one GPU server — a 27B open-source model does the heavy lifting, and a couple of peer models get pulled in for a “consult” only when things stall. The result: a 50% pass rate on real terminal engineering tasks, ahead of a 295-billion-parameter cloud flagship, and a full 15 points ahead of a 1.6-trillion-parameter one. Its token bill? A rounding error by comparison. Here’s the full picture.
2. “Find the strongest model” was a flawed premise to begin with Harvard Business School and BCG ran a joint study that produced a term now cited fairly often — the Jagged Frontier. It describes something specific: an AI model’s capability isn’t a smooth curve, it’s closer to uneven terrain, full of peaks and sudden drops. The same model can excel on one problem and barely clear a beginner’s bar on the next. That unevenness is especially visible in engineering work: •Some models are good at picking up on implicit logic in legacy code that never made it into a comment; •Some models are good at tracing the actual root cause through a wall of error logs; •Some models are good at judging whether a given change will ripple into other modules. Fixing a real issue usually requires all three, together. Expecting a single model to be the best at each of these is a bit like expecting one engineer to also be the team’s best architect, best debugger, and best QA lead, all at once — not a capability gap, just an unreasonable expectation. Fusion-MOA’s design logic boils down to one line: The competition isn’t about which model is strongest. It’s about who organizes multiple models more sensibly.
3. What the system provides is a division of labor, not just a headcount Multi-model systems easily fall into a trap: treating “how many models are wired in” as a proxy for how well they collaborate. Pioneer R1 uses a different standard — a model only counts as a genuine unit in the system once it has a clearly defined role, an independent service endpoint, an explicit run policy, a version identifier, and a traceable call log. The i-th unit is written as: Cellᵢ = (modelᵢ, roleᵢ, endpointᵢ, policyᵢ, versionᵢ, traceᵢ) The complete set of standing units makes up fleet F. Rather than picking models on an ad hoc basis, each business Profile p is pre-bound to a fixed participant set Cₚ, a communication policy Mₚ, a finalization policy Vₚ, and a permission policy Aₚ: Cₚ⊆F, Profileₚ = (Cₚ, Mₚ, Vₚ, Aₚ) The general-purpose Profile currently in production consists of one Executor E and three read-only Analysts, A₁, A₂, A₃: C_g = {E, A₁, A₂, A₃} What separates these roles is system-level permission — not tone or personality. The Client or Agent holds the external task state and is responsible for sending messages and invoking tools. The Gateway validates whether the interface contract is being honored, generates a call-tracing ID, and calculates whether the system has hit a “deterministic stall” — but it doesn’t execute any tool itself. The Executor E owns the main task thread and is the only role authorized to produce the response body, initiate tool calls, or set the action plan. The three Analysts each read from the same immutable evidence snapshot, work independently with no cross-talk, and can only return structured Packets. A verification-and-selection module checks formatting, citations, deadlines, and duplication, surfacing at most two Packets. An operations control plane handles isolation testing, qualification checks, promotion, and rollback for candidate units — but has no operational authority over live requests whatsoever. The relationships among these roles reduce to three boundaries: a participation boundary defining who can enter a given Profile; an information boundary defining what each participant can see and return; and a permission boundary defining who can modify state, invoke tools, or submit the final result. Only once all three are clearly defined does multi-model collaboration become something that can actually be audited, rather than a tangle that’s hard to trace. That also explains a counterintuitive fact: wiring in more models doesn’t automatically translate to more capability. If every model can freely read and write the same state, overwrite each other’s workspace, and call tools directly on its own, the system just accumulates conflicts, and recovery costs climb accordingly. Pioneer R1’s approach: ordinary requests take the shortest path, a scope-limited consultation only triggers once the system confirms a genuine stall, and there’s always exactly one final author of the action taken.

Fusion-MoA Pioneer R1 three-plane architecture
For the integrator, nothing about the call pattern changes — however you were calling GPT before, you call Fusion-MOA the same way, just pointed at a different base_url. No changes to application-layer code are required. All the complexity of coordinating multiple models is wrapped inside the interface, invisible to whoever’s using it.

1. Who built this Drawing on years of technical depth in intelligent operating systems, Thundersoft has folded its chip and AI-algorithm capabilities into its own AI data center and model-serving platform. Its NovaStack team, bringing together core R&D talent, has produced a next-generation AI agent and token infrastructure: FusionMOA. FusionMOA isn’t simply a model framework — it functions more like an intelligent hub that converts the individual strengths of heterogeneous models into deliverable, executable outcomes. It gets past the capability ceiling of any single model by deeply combining reinforcement learning with multi-agent coordination. “Fusion” here isn’t simple weighted voting — it’s a deep logical merge across multiple models’ capabilities, candidate paths, and verifiable evidence, keeping every decision traceable back to its source. “MoA” (Mixture of Agents) gives the system dynamic orchestration, scheduling the right combination of agents in real time based on the task’s structure, rather than having every model participate indiscriminately, in full, every time. Built on FusionMOA, what we’re aiming for is turning a shifting, complex range of model capabilities into precise, verifiable, deliverable business value — a dependable intelligent foundation for putting AI applications into genuine production use.
2. Benchmark comparison: what the 27B lineup actually achieved Test conditions first: every system used the identical problem set, the identical agent framework, and the identical official grading standard. The only variable is whether the model answered solo or as a team. Test one: Terminal-Bench 2.1 (real terminal engineering tasks, 3-hour cap per problem)

Three numbers worth flagging:
50% vs. 40%: the exact same 27B model, purely by adjusting how it’s organized, solved 25% more problems — an increase attributable entirely to the collaboration mechanism itself;
50% vs. 35%: a locally deployed combination with far fewer parameters than the competitor outscored the 1.6-trillion-parameter flagship by 15 points;
Worth noting: kv-store-grpc and password-recovery were solved exclusively by Fusion-MOA — neither cloud flagship passed either one. That’s not a function of raw compute; it’s a function of a different model stepping in the instant the system detected a stall.
Test two: HMMT math competition problems (graded via sympy’s official equivalence checker)

A merged setup made up of 20B–30B-class open-source models matched a 744B-class flagship’s score, beating the best solo attempt (6/10) by two full problems. One detail from the process is worth recording: on one hard problem, all three models got it wrong in the first round; after one round of anonymous cross-discussion, all three independently corrected themselves to the right answer. Collaboration produced a real capability gain here — not just a marketing line.
Test three: SWE-bench Verified (real GitHub issue fixes, testing ongoing)
Among problems officially graded so far, Fusion-MOA’s pass rate stands at 11/14 — including two that the 295-billion-parameter flagship HY3 failed to fix. On the cost dimension, the picture looks entirely different.
Across the same 20 terminal engineering tasks, here’s the input token comparison:
LongCat-2.0: 266 million tokens
HY3: 65.27 million tokens
Fusion-MOA: 14.27 million tokens — just 1/18th of the first figure

And the whole system runs on our own servers — no usage-based billing, no rate limits, and no risk of a bill suddenly spiking.
Reasoning has a real cost. Repeating that reasoning in the same dead end shouldn’t. That’s the point of on-demand collaboration — let one model handle 98% of routine work, and only hand the genuinely hard 2% to a group.

1. A good benchmark score is easy. Surviving production isn’t. Beyond the numbers, the engineering investment behind Fusion-MOA is probably where the real value sits: •Response speed. MTP speculative decoding takes the core model’s decoding speed from 16 tokens/s to 62 tokens/s — nearly a 4x jump. Prefix-cache hit rate holds steady in the 90–98% range, so efficiency actually improves the longer a task runs. •Context length. The full system supports 128K context, enough room for the oversized files, long logs, and hundred-round tool-call histories that accumulate in older codebases. •System stability. A continuous stress test ran for 3,600 seconds across 906 calls with zero restarts. Dropped connections cancel automatically, timeouts fail safe automatically, and any non-compliant advisor output triggers an automatic fallback to a single-model path. Under any circumstance, the system is only permitted to degrade gracefully — never to fail unpredictably. •Domestic-hardware compatible. The current production system runs on domestically produced MetaX GPUs, and has also completed full validation on AMD’s W7900D platform. It depends on neither restricted hardware nor NVLink — one GPU per model, with only text passed between cards. Domestic deployment, consumer-grade deployment, and data-center-grade deployment are all viable paths.
2. Who this is built for Back to where this started. We think Fusion-MOA fits best for three kinds of work a single model consistently struggles with: ① A night-shift process for legacy systems Backlog issues sitting for months, historical code nobody wants to touch — this is exactly where a single model is most prone to looping, and exactly where on-demand collaboration pays off most visibly. Submit a batch of issues overnight, get back a batch of fixes by morning. ② A review mechanism for complex technical decisions Tech selection, architecture review, migration planning — this kind of work inherently needs multiple angles: performance, cost, risk. Ask one model to weigh all three simultaneously and you usually get an answer that looks reasonable without being rigorous. Let three independent perspectives reason it through separately, then have the lead model synthesize a conclusion — the result holds up considerably better. ③ A task force for math and algorithm problems Competition problems, mathematical proofs, algorithm optimization — an 8/10 on HMMT matching a 744B-class flagship already proves the point: when multiple models’ strengths complement each other, the merged result can exceed what any single model reaches alone. More importantly, these three categories share a trait: They’re all worth solving with a strong model — but none of them justifies paying flagship prices on every single call.
3. Closing thoughts Over the past two years, the competitive logic around large models has revolved almost entirely around scale — more parameters, more compute, pricier APIs. But what engineering practice actually shows is more grounded than that: no team’s budget is unlimited, and no task genuinely justifies unlimited spend. Fusion-MOA is proof of a different path — take a set of open-source models that are affordable, self-hostable, and fully under your control, and bind them together through an “executor + advisors + stall detection” organizational structure: •On capability: it matches or exceeds cloud flagships 10x, even 60x its own size; •On cost: token spend is a rounding error against theirs, running entirely on owned hardware; •On integration: a single OpenAI-compatible endpoint is all it takes, with zero code changes. The factor that will actually separate teams going forward isn’t the scale of the model they use — it’s how well they organize their AI system. Fusion-MOA is currently open for enterprise beta testing and private-deployment evaluation. If your team is dealing with agents caught in loops, flagship model bills that are hard to control, or data that can’t leave your internal network — we’d welcome a conversation. Reply “Fusion” on our official account for the beta application process and the technical whitepaper. Fusion-MOA v0.9 · single 8-GPU node deployment · OpenAI-compatible · domestic-hardware ready Collective intelligence, beyond any single model’s ceiling.