The short version: a 27B open-source lineup, working on demand, beat a 1.6-trillion-parameter cloud flagship — at 1/18th the token cost.

1. The numbers first We call the system Fusion-MOA: one GPU server, a 27B open-source model doing the heavy lifting, a couple of peer models pulled in on demand when things stall. Three tests, results below. Terminal-Bench 2.1 (real terminal engineering tasks, 3-hour cap per problem)

The identical 27B model solved 25% more problems purely from a change in organization. The local lineup, with roughly 1/60th the parameters, outscored the giant by 15 points. Two problems — kv-store-grpc and password-recovery — were solved only by Fusion-MOA; neither cloud flagship cracked them.
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. On one hard problem, all three models got it wrong in round one; after one round of anonymous cross-discussion, all three self-corrected. Collaboration changed the outcome here — it wasn’t just a nice story.
SWE-bench Verified (real GitHub issue fixes, in progress): among problems graded so far, Fusion-MOA is at 11/14, including two that HY3 couldn’t fix.
Now the cost side. Across the same 20 terminal engineering tasks, input token usage:
LongCat-2.0: 266 million. HY3: 65.27 million. Fusion-MOA: 14.27 million — 1/18th.

And it runs entirely on our own hardware — no billing, no rate limits.

1. Why this works Harvard Business School and BCG coined a term for this: the Jagged Frontier. A model’s capability isn’t a smooth curve — it’s uneven terrain. Brilliant on one problem, worse than an intern on the next. In engineering work, that unevenness is sharp: some models catch what legacy code is really saying between the lines, some are good at tracing root causes through error logs, some are good at reasoning about downstream breakage. Fixing a real issue usually needs all three. Expecting one model to excel at every step is like expecting one engineer to also be the company’s best architect, debugger, and QA tester. Not a skill gap — an unreasonable ask. So Fusion-MOA’s logic is simple: stop competing on whose model is strongest, compete on who organizes models better.
2. How it’s organized The system (codenamed Pioneer R1) assigns clear roles instead of just adding headcount. A model only counts as a real unit once it has a defined role, endpoint, run policy, version, and traceable log: Cellᵢ = (modelᵢ, roleᵢ, endpointᵢ, policyᵢ, versionᵢ, traceᵢ) The general-purpose configuration in production: one Executor E, three read-only Analysts: C_g = {E, A₁, A₂, A₃} The distinction is about permissions, not tone. The Client/Agent owns task state and calls tools. The Gateway validates the interface and computes a stall signal — it never executes tools itself. The Executor E is the only party allowed to author text or invoke tools. The three Analysts read the same immutable snapshot, work independently, and can only return structured data. A verification module checks format and duplication, keeping at most two candidates. An operations control plane handles isolation, promotion, and rollback — with no authority over live requests. Three boundaries hold this together: who can participate, what each participant can see, and who can change state. Get those right and multi-model collaboration becomes auditable. Skip them, and adding more models just adds conflicts — which is exactly why more models doesn’t automatically mean more capability. Pioneer R1’s approach: ordinary requests take the shortest path, a bounded consultation only fires on a genuine stall, and there’s always exactly one author of the final action.

Fusion-MoA Pioneer R1 three-plane architecture
For your application, nothing changes about how you call it — swap in Fusion-MOA the way you’d swap models today, by changing a base_url. No application code needs to change.

1. Beyond the benchmark: does it survive production •Speed: MTP speculative decoding takes decoding from 16 to 62 tokens/s, close to 4x. Prefix-cache hit rate holds at 90–98%. •Context: 128K, enough for the oversized files and long logs that live in old repos. •Stability: a 3,600-second stress test ran 906 calls with zero restarts. Dropped connections cancel automatically, timeouts fail safe, non-compliant advisor output falls back to a single-model path automatically. The system only degrades gracefully — it never fails in a surprising way. •Domestic hardware: runs on China-made MetaX GPUs, fully validated on AMD’s W7900D too. No export-controlled hardware, no NVLink — one GPU per model, only text moves between cards.
2. Who this is for Three categories where a single model tends to fall short: Night-shift doctor for legacy systems — backlog issues sitting for months, ancestral code nobody touches, exactly where a single model loops and where on-demand consultation pays off most. Submit issues overnight, get patches by morning. Review board for hard technical decisions — tech selection, architecture review need multiple angles: performance, cost, risk. One model juggling all three usually gives you something that sounds right without being rigorous. Three independent perspectives, synthesized by the lead, holds up far better. Strike team for math and algorithm problems — 8/10 on HMMT matching a 744B flagship already makes the point: complementary strengths, merged, reach a ceiling no single model touches. All three share a trait: worth a good model, not worth flagship pricing on every call.
3. Who built it FusionMOA comes from Thundersoft’s NovaStack team. Thundersoft has years of depth in intelligent operating systems and has folded its chip and AI-algorithm capabilities into its own AI data center and model-serving platform. FusionMOA isn’t just a model framework — it’s an intelligent hub converting heterogeneous models’ strengths into deliverable outcomes. “Fusion” means deep logical merging of multiple models’ capabilities, candidate paths, and verifiable evidence, keeping decisions traceable. “MoA” (Mixture of Agents) gives dynamic orchestration — scheduling the right agent combination for the task in real time, instead of running every model redundantly.
4. Closing thought The past two years of large-model competition have mostly been about “bigger”: more parameters, more GPUs, pricier APIs. But shipping this into production teaches something simpler: nobody’s budget is unlimited, and no task is worth unlimited spend. Fusion-MOA is proof of a different path — a set of affordable, runnable open-source models, bound together by “executor + advisors + stall detection”: matching or beating flagships 10x or 60x its size, at a fraction of the token cost, on one OpenAI-compatible endpoint with zero code changes. The edge that matters going forward isn’t how big your model is — it’s how well you organize it. Fusion-MOA is open for enterprise beta and private-deployment evaluation. If your team is dealing with looping agents, spiraling flagship bills, or data that can’t leave your network, we’d like to talk. Reply “Fusion” on our official account for the beta process and technical whitepaper. Fusion-MOA v0.9 · single 8-GPU node · OpenAI-compatible · domestic-hardware ready