In short: no extra parameters, no extra budget. A “review board” of open-source models outscored a 1.6T flagship by 15 points on real engineering tasks.
01 | A scene every engineering team knows
11 p.m., the night before a release.
An eight-year-old repository. An issue that’s been sitting untouched for three months. You hand it to the most expensive cloud model you have and watch it get to work — reading code, editing, running tests, hitting errors, editing again, erroring again.
By round 9, it has reverted the code back to what it looked like in round 3.
By round 14, it’s drifted back there again.
The model is stuck. The billing meter is not.
Tokens keep burning, context keeps growing, and the issue is exactly where it started.
This scene keeps repeating itself as AI coding moves from demo to production. Looking at our own numbers, a large share of failures in agentic tasks aren’t cases of the model “not knowing how” — they’re cases of the model getting stuck with nobody around to nudge it: spinning in place, repeating the same move, blowing past the context limit, and finally timing out.
Since June, the industry has been converging on the same answer from several directions at once: OpenRouter shipped Fusion, letting several models answer independently before merging into one best solution; Hermes turned Mixture of Agents into an official feature; Cursor rewrote all of SQLite using a swarm of over a thousand agents.
A path one model can’t finish, a group of models often can.
But that raises an obvious question: does assembling a group of models mean assembling a GPU cluster and burning through a truckload of tokens?
Over the past six months we built our answer to that, and it’s a bit counterintuitive: Fusion-MOA. Running on a single GPU server, with a 27B open-source model in the lead and a few peer models pulled in for on-demand “consultation,” it hit a 50% pass rate on real terminal engineering tasks — beating a 295-billion-parameter cloud flagship, and beating a 1.6-trillion-parameter giant by 15 percentage points.
And it used only a sliver of the tokens either of them did.
Here’s the full breakdown.
02 | “Just pick the strongest model” was never a real strategy
Harvard Business School and BCG ran a joint study that produced a well-known idea: the Jagged Frontier.
The gist: an AI model’s capability isn’t a smooth curve — it’s a jagged cliff full of peaks and drops. The same model can be brilliant on one problem and worse than an intern on the very next one.
In engineering work, that plays out in sharp relief:
•Some models are good at picking up the “subtext” buried in legacy code;
•Some models are good at sniffing out root causes from a wall of error logs;
•Some models are good at reasoning through whether a change will break something else downstream.
Fixing a real issue usually requires all three skills at once.
Expecting one model to be the best at every step of that is like expecting one engineer to simultaneously be the company’s best architect, best debugger, and best tester — not because they aren’t good, but because the ask itself doesn’t make sense.
So Fusion-MOA’s starting premise comes down to one line:
Stop competing on whose model is strongest. Compete on who organizes their models most intelligently.
03 | What Fusion-MOA actually does: give the AI team defined roles, not just headcount
Multi-model systems tend to fall into a trap: treating “number of models” as a stand-in for collaborative capability. Pioneer R1 takes a different definition — a model only counts as a real unit in the system once it has a clearly defined role, service endpoint, execution policy, version, and traceable log. The i-th model unit is written as:
Cellᵢ = (modelᵢ, roleᵢ, endpointᵢ, policyᵢ, versionᵢ, traceᵢ)
The full set of standing units forms fleet F. Rather than searching for arbitrary models on the fly, each business Profile p binds 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 current general-purpose Profile consists of one Executor E and three read-only Analysts A₁, A₂, A₃:
C_g = {E, A₁, A₂, A₃}
These roles map to different system-level permissions — not to different tones of voice.
The Client or Agent owns the external task state and is responsible for sending messages and invoking tools. The Gateway validates interface contracts, generates call-tracing IDs, and computes a deterministic “stall” signal — but it never executes tools itself. The Executor E owns the main thread and is the only party allowed to author text, invoke tools, or set the action plan. The three Analysts each read the same immutable evidence snapshot, work independently of one another, and can only return structured Packets. A verification-and-selection module checks format, citations, deadlines, and duplication, and surfaces at most two Packets. An operations control plane handles isolation, qualification checks, promotion, and rollback for candidate units — but sits entirely outside the action-permission chain for live requests.
The relationships between these roles boil down to three boundaries: a participation boundary — who can enter this Profile; an information boundary — what each participant can see and return; and a permission boundary — who can modify state, call tools, or submit the final result. Multi-model collaboration only becomes auditable once all three boundaries are clearly defined.
This also explains why adding more models doesn’t automatically add more capability. If every model can read and write the same state, overwrite each other’s workspace, or execute tools directly, the system just accumulates conflicts and recovery costs. Pioneer R1’s approach: ordinary requests take the shortest path, a bounded consultation only kicks in once the system detects a deterministic stall, and there is always exactly one author of the final action.
Fusion-MoA Pioneer R1 three-plane architecture
For your application, nothing about how you call it changes — swap GPT for Fusion-MOA the same way you’d call any model, by changing one base_url. Not a single line of application code needs to be rewritten. All the complexity of multi-model coordination stays behind the interface, invisible and out of your way.
04 | Who’s behind it
Building on years of accumulated depth in intelligent operating systems, Thundersoft (中科创达) has folded its chip- and AI-algorithm capabilities directly into its AI data center and model-serving platform. Its NovaStack team has now shipped a new-generation AI agent and token substrate: FusionMOA.
FusionMOA isn’t just a model framework — it’s an intelligent hub that turns the strengths of heterogeneous models into deliverable, executable outcomes. It moves past the ceiling of any single model by deeply combining reinforcement learning with a multi-agent coordination mechanism. “Fusion” here isn’t a simple weighted vote — it’s a deep logical merge across multiple models’ capabilities, candidate paths, and verifiable evidence, so every decision stays traceable. “MoA” (Mixture of Agents) gives the system dynamic orchestration: it assembles the most fitting combination of agents in real time based on task structure, instead of running every model in full, redundantly, every time.
Built on FusionMOA, the goal is to turn a shifting, complex landscape of model capabilities into precise, verifiable, deliverable business value — a solid foundation for putting AI applications into production.
05 | Where the numbers land: who did a 27B lineup actually match?
Test setup, stated up front: every system runs the same problem set, the same agent framework, and the same official grader. The only variable is whether the model works alone or as a team.
Round one: Terminal-Bench 2.1 (real terminal engineering tasks, 3-hour limit per problem)
Three numbers worth sitting with:
50% vs. 40%: the exact same 27B model solved 25% more problems purely from a change in how it’s organized;
50% vs. 35%: a local combination with a fraction of its parameter count outscored the 1.6-trillion-parameter giant by 15 points;
Fusion-MOA also uniquely cracked two problems — kv-store-grpc and password-recovery — that neither cloud flagship solved. Not through brute force, but because someone else stepped in the moment it got stuck.
Round two: HMMT math competition problems (graded by sympy’s official equivalence checker)
A merged group of 20B–30B open-source models matched a 744B-class flagship, and beat the best solo score (6/10) by a full two problems. The process itself was telling: on one hard problem, all three models got it wrong in round one; after one round of anonymous cross-discussion, all three self-corrected to the right answer. Collaboration producing an actual chemistry effect isn’t just a nice phrase — it happened.
Round three: SWE-bench Verified (real GitHub issue fixes, in progress)
Among the problems graded so far, Fusion-MOA’s pass rate is 11/14 — including two that the 295-billion-parameter flagship HY3 couldn’t fix. On the cost side, it’s a different story entirely.
Across the same 20 terminal engineering tasks, input token consumption:
LongCat-2.0: 266 million tokens
HY3: 65.27 million tokens
Fusion-MOA: 14.27 million tokens — 1/18 of the first figure
And it all runs on our own hardware — no metered billing, no rate limits, no surprise invoices.
Thinking is expensive. Re-running the same dead end shouldn’t be. That’s the whole point of on-demand collaboration: let one model handle 98% of the road, and bring in a group only for the last 2% that’s actually hard.
06 | Plenty of systems can post a good benchmark. Few can actually run in production.
Beyond the scores, the engineering work behind Fusion-MOA is arguably where the real commercial value sits:
•Fast. MTP speculative decoding lifts the core model’s decoding speed from 16 tokens/s to 62 tokens/s — nearly 4x. Prefix-cache hit rate holds steady at 90–98%, so long-running tasks get smoother, not slower.
•Long. The whole system supports 128K context — enough room for the giant files, sprawling logs, and hundred-round tool-call histories that live in old repositories.
•Stable. A 3,600-second continuous stress test ran 906 calls with zero restarts. Dropped connections cancel automatically, timeouts fail safe automatically, and any non-compliant advisor output automatically falls back to a single-model path. At every point, the system is only allowed to degrade gracefully — never to fail in an interesting way.
•Ready for domestic hardware. The production system runs on MetaX (沐曦) GPUs made in China, and has also passed full validation on AMD’s W7900D platform. No dependence on export-controlled hardware, no NVLink required — one GPU per model, with only text passed between cards. Domestic, consumer-grade, or data-center-grade — all three deployment paths work.
07 | Who is this actually for
Back to the opening scene. We think Fusion-MOA fits best where a single model genuinely can’t get the job done, in three categories:
① The night-shift doctor for legacy systems
Old issues that have sat in the backlog for months, ancestral code nobody dares touch — this is exactly where a single model is most likely to spin into a dead loop, and exactly where on-demand consultation pays off most. Submit a batch of issues at night, get back a batch of patches by morning.
② The review board for hard technical calls
Tech selection, architecture review, migration plans — these tasks inherently need multiple angles: performance, cost, risk. Ask one model to weigh all three at once and you usually get an answer that “sounds right” without being rigorous. Let three independent perspectives reason separately, then have the lead synthesize a conclusion — the result holds up much better.
③ The strike team for math and algorithm problems
Competition problems, proofs, algorithm optimization — an 8/10 on HMMT matching a 744B flagship already makes the point: when models’ strengths complement each other, the merged result can reach a ceiling no single model can touch alone.
More importantly, all three categories share one commercial trait:
They’re worth using a good model for — but not worth paying flagship prices on every single call.
08 | Closing thought
For the past two years, the competitive logic in large models has mostly been “bigger”: more parameters, more GPUs, pricier APIs.
But the reality of putting this into production is simpler: nobody’s budget is unlimited, and no task is actually worth unlimited money.
Fusion-MOA is proof of a different path — taking a set of open-source models that are affordable, runnable, and tangible, and binding them together with an “executor + advisors + stall detection” structure:
•On capability, it matches or beats cloud flagships with 10x, even 60x its parameter count;
•On cost, token consumption is a fraction of theirs, running entirely on our own hardware;
•On integration, it’s one OpenAI-compatible endpoint — zero lines of code to change.
The competitive edge of the future won’t come from how large your model is. It’ll come from how well you organize your AI.
Fusion-MOA is now open for enterprise beta testing and private-deployment evaluation.
If your team is dealing with agents stuck in dead loops, flagship-model bills spiraling out of control, or data that can’t leave your internal network — we’d like to talk.
Reply “Fusion” on our official account to get the beta application process and the technical whitepaper.
Fusion-MOA v0.9 · single 8-GPU node · OpenAI-compatible · ready for domestic hardware
Collective intelligence, beyond any single model’s ceiling.
Top comments (0)