01 | A moment most engineering teams have lived through
It’s 11pm, the night before a release.
You’re staring at an eight-year-old codebase and an issue that’s been sitting untouched for three months. You hand it to the priciest cloud model on your account and watch it work: read the code, make a change, run the tests, hit an error, try again, hit another error.
By round 9, it has quietly reverted its own edit back to what it looked like in round 3.
By round 14, it’s drifted back there once more.
The model has stalled. The invoice hasn’t.
Tokens keep draining, the context window keeps filling up, and the issue itself hasn’t moved an inch.
This isn’t a rare glitch — it shows up constantly once AI coding moves past demos and into daily use. Looking at our own failure data, a large chunk of agentic task failures aren’t really about the model lacking the skill. They’re about the model getting stuck with nobody around to intervene: circling the same idea, repeating an action, overflowing its context, and eventually timing out.
Since June, several parts of the industry have arrived at roughly the same conclusion independently: OpenRouter launched Fusion, letting multiple models answer separately before merging into one output; Hermes turned Mixture of Agents into a first-class feature; Cursor used a swarm of over a thousand agents to rewrite the entirety of SQLite.
A dead end for one model isn’t necessarily a dead end for several.
Which raises the obvious follow-up: does building a “group” of models mean standing up a GPU cluster and burning a small fortune in tokens?
Over the last six months we tested a somewhat counterintuitive answer, and turned it into a product: Fusion-MOA. Running on one GPU server, with a 27B open-source model leading and a couple of peer models pulled in only when needed, it hit a 50% pass rate on real terminal engineering tasks — ahead of a 295-billion-parameter cloud flagship, and 15 points ahead of a 1.6-trillion-parameter giant.
Token spend? A fraction of either.
Here’s the full picture.
02 | “Pick the strongest model” was never a solid strategy to begin with
Harvard Business School and BCG ran a joint study that produced a fairly well-known term: the Jagged Frontier.
The idea is straightforward — a model’s capability isn’t a smooth line, it’s uneven terrain full of sudden peaks and drops. The same model can look brilliant on one problem and fall short of an intern on the next.
In real engineering work, that unevenness shows up clearly:
•Some models are good at catching what legacy code is really trying to say between the lines;
•Some models are good at tracing a root cause through a wall of error logs;
•Some models are good at reasoning through whether a fix will break something else downstream.
Fixing an actual issue usually needs all three of these at once.
Expecting a single model to excel at every one of them is a bit like expecting one engineer to also be the company’s best architect, best debugger, and best QA tester at the same time — not because they’re not skilled, but because the expectation itself doesn’t hold up.
So Fusion-MOA’s core bet comes down to one sentence:
Don’t compete on whose model is strongest. Compete on who organizes their models better.
03 | What Fusion-MOA is really doing: assigning clear roles, not just adding more models
Multi-model systems tend to fall into a common trap — treating the number of models as a proxy for how well they collaborate. Pioneer R1 uses a different definition instead: a model only counts as a genuine unit in the system once it has a defined role, a dedicated service endpoint, a run policy, a version, and a traceable log. The i-th unit is written as:
Cellᵢ = (modelᵢ, roleᵢ, endpointᵢ, policyᵢ, versionᵢ, traceᵢ)
The full set of standing units makes up fleet F. Rather than picking models ad hoc, each business Profile p is bound to a fixed set of participants 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 in production today has one Executor E and three read-only Analysts, A₁, A₂, A₃:
C_g = {E, A₁, A₂, A₃}
The distinction between these roles is about system-level permissions — not tone or personality.
The Client or Agent holds the external task state and handles sending messages and calling tools. The Gateway validates the interface contract, generates a call-tracing ID, and computes a deterministic stall signal — but never executes a tool itself. The Executor E owns the main thread and is the sole party permitted to write the response, invoke tools, or set the action plan. The three Analysts each read from the same immutable evidence snapshot, work independently, and can only return structured Packets. A verification and selection module checks format, citations, deadlines, and duplication, surfacing at most two Packets. An operations control plane manages isolation, qualification, promotion, and rollback for candidate units, but has no action authority in live requests.
The relationships between these roles reduce to three boundaries: a participation boundary — who’s allowed into a given Profile; an information boundary — what each participant can see and return; and a permission boundary — who can change state, call tools, or submit the final result. Multi-model collaboration only becomes something you can actually audit once all three are clearly defined.
That also explains why more models don’t automatically mean more capability. If every model can read and write the same state, overwrite one another’s workspace, and execute tools on its own, the system mostly just accumulates conflicts and cleanup work. Pioneer R1’s approach: ordinary requests run the shortest possible path, a bounded consultation only starts once the system detects a genuine stall, and there is always exactly one author of the final action.
Fusion-MoA Pioneer R1 three-plane architecture
For your application, none of this changes how you call it — swap in Fusion-MOA exactly the way you’d swap models today, by pointing at a different base_url. No application code needs to change. All the complexity of coordinating multiple models stays behind the interface, where you don’t have to think about it.
04 | The team behind it
Drawing on years of depth in intelligent operating systems, Thundersoft has channeled its chip and AI-algorithm capabilities directly into its AI data center and model-serving platform. Its NovaStack team has now shipped a next-generation AI agent and token substrate: FusionMOA.
FusionMOA isn’t just a model framework — it’s an intelligent hub that converts the strengths of heterogeneous models into deliverable, executable outcomes. It gets past the ceiling of any single model by deeply combining reinforcement learning with multi-agent coordination. “Fusion” here doesn’t mean simple weighted voting — 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, assembling the right combination of agents for a task’s structure in real time, rather than running every model redundantly on every request.
Built on FusionMOA, the goal is to turn a shifting, complex set of model capabilities into precise, verifiable, deliverable business value — a solid foundation for putting AI applications into real production.
05 | The numbers: what did a 27B lineup actually match?
Test setup first: every system ran the same problem set, the same agent framework, and the same official grader. The only variable is whether the model worked solo or as a team.
Round one: Terminal-Bench 2.1 (real terminal engineering tasks, 3-hour cap per problem)
Three numbers worth pausing on:
50% vs. 40%: the identical 27B model, purely from a change in how it’s organized, solved 25% more problems;
50% vs. 35%: a local combination with a fraction of the parameter count outscored the 1.6-trillion-parameter giant by 15 points;
Fusion-MOA also uniquely solved two problems — kv-store-grpc and password-recovery — that neither cloud flagship cracked. Not through brute force, but because the moment it stalled, a different model stepped in.
Round two: HMMT math competition problems (graded via sympy’s official equivalence checker)
A merged group of 20B–30B open-source models matched a 744B-class flagship, beating the best solo run (6/10) by two full problems. What happened along the way is worth noting: on one hard problem, all three models got it wrong in the first round; after one anonymous cross-discussion pass, all three landed on the correct answer independently. Collaboration producing a real effect, not just a talking point.
Round three: SWE-bench Verified (real GitHub issue fixes, in progress)
Among problems graded so far, Fusion-MOA’s pass rate stands at 11/14 — including two the 295-billion-parameter flagship HY3 couldn’t fix. On cost, it’s an entirely different story.
Across the same 20 terminal engineering tasks, input token usage:
LongCat-2.0: 266 million tokens
HY3: 65.27 million tokens
Fusion-MOA: 14.27 million tokens — 1/18 of the first number
And it runs entirely on our own hardware — no usage-based billing, no rate limits, no surprise invoices.
Thinking is expensive. Repeating the same dead end shouldn’t be. That’s the whole case for on-demand collaboration: let one model cover 98% of the road, and only bring in a group for the last 2% that’s genuinely hard.
06 | Plenty of systems can post a good score. Few can actually survive production.
Beyond the benchmarks, the engineering work behind Fusion-MOA is probably where the real commercial value lives:
•Fast. MTP speculative decoding takes the core model’s decoding speed from 16 tokens/s to 62 tokens/s — close to 4x. Prefix-cache hit rate holds at 90–98%, so longer tasks get smoother instead of slower.
•Long context. The full system supports 128K context — enough for the oversized files, long logs, and hundred-round tool-call histories that live in older 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 falls back to a single-model path automatically. At every point, the system is only allowed to degrade gracefully — never to fail in a surprising way.
•Domestic hardware ready. The production system runs on China-made MetaX GPUs and has also passed full validation on AMD’s W7900D platform. No dependence on export-controlled hardware, no NVLink requirement — one GPU per model, with only text moving between cards. Domestic, consumer-grade, or data-center-grade deployment — all three work.
07 | Who this is actually built for
Back to where we started. We think Fusion-MOA fits best in three situations where a single model consistently falls short:
① The night-shift doctor for legacy systems
Old issues sitting in the backlog for months, ancestral code nobody wants to touch — this is exactly where a single model is most prone to spinning in circles, and exactly where on-demand consultation pays off the most. Submit a batch of issues overnight, get back a batch of patches by morning.
② The review board for hard technical decisions
Tech selection, architecture review, migration planning — these inherently need multiple angles: performance, cost, risk. Ask one model to weigh all three at once and you typically get an answer that sounds reasonable without being rigorous. Let three perspectives reason independently, then have the lead synthesize the conclusion — the result holds up far 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 output can reach a ceiling no single model reaches alone.
More importantly, these three categories share a commercial trait:
They’re worth solving with a good model — but not worth paying flagship prices on every single call.
08 | A closing thought
Over the past two years, the competitive logic around large models has mostly been “bigger”: more parameters, more GPUs, pricier APIs.
But the reality of shipping this into production is simpler than that: nobody’s budget is unlimited, and no task is actually worth unlimited spend.
Fusion-MOA is proof of a different path — take a set of open-source models that are affordable, runnable, and tangible, and bind them together with an “executor + advisors + stall detection” structure:
•On capability, it matches or beats cloud flagships 10x, even 60x its size;
•On cost, token spend is a fraction of theirs, running entirely on our own hardware;
•On integration, it’s one OpenAI-compatible endpoint — zero code changes.
The edge that matters going forward won’t be how big your model is. It’ll be how well you organize it.
Fusion-MOA is now open for enterprise beta and private-deployment evaluation.
If your team is dealing with agents stuck in loops, flagship bills spiraling, or data that can’t leave your internal network — we’d like to talk.
Reply “Fusion” on our official account for the beta application process and the technical whitepaper.
Fusion-MOA v0.9 · single 8-GPU node · OpenAI-compatible · domestic-hardware ready
Collective intelligence, past any single model’s ceiling.
Top comments (0)