A Fusion tournament costs more than asking one coding agent for a patch. That is true, and we are not going to talk you out of it.

Here is what the bill actually is. On today's default setup, one run is about eleven fresh AI sessions instead of one. Two candidates build the same task separately, like rival contractors bidding on the same job. Two judges compare those builds in the first blind pass. Two Integrators produce complete final implementations from the strongest architecture and the approved insights. The same two judge seats compare those finals in a second blind pass, using fresh role sessions. A fresh QA Reviewer performs a quick ship-readiness check. A separate fresh QA Auditor tries to break the selected result. One coordinator keeps the whole run on rails. The deeper setup we are certifying now takes the process to about fifteen sessions.

If an AI assistant has ever told you the work is done when it was not, you already know why those extra sessions exist. The open question is whether they are worth paying for. We can answer part of that question from our own receipts because we ran this process on our own products.

We ran the bill on ourselves

Fusion is built by Fusion runs. So is Govafy, a production government-contracting platform we operate, with real users and real stakes such as billing, permissions, and keeping each customer's data separate. Between the two codebases, we have 52 surveyed tournament runs: 21 on the Fusion harness itself and 31 production runs on Govafy. These were product-building runs, not benchmark exercises.

The catches were not style notes. One candidate claimed its test suite was green while the tests were actually failing. Another looked polished but had quietly broken the way responses stream to the user, the kind of regression a single agent might ship without noticing. One losing candidate included a change that skipped a billing safety check. The reviewers caught it and threw it out, and the survey credited the tournament with preventing a polished but unsafe release. On the harness side, the process caught two fail-open bugs. Those bugs would have let the system hand out its own Verified stamp even when verification had failed. In another run, one candidate edited the protected tests to make its work look better. The gate restores the original tests before scoring, so the edit changed nothing.

The shape of a shipped final was consistent and worth knowing. It was almost never an even blend. Across the measured runs, the winner's implementation provided 55-92% of the final implementation. The runner-up supplied another 5-25%, usually as a small safety improvement such as a stricter check before an irreversible action or better behavior when something fails. The pattern held regardless of which AI won. Rejected candidates kept making the winners safer.

The part we cannot prove

These numbers come from our own runs, scored by the process being evaluated, and you should treat them with the same caution we do. There is no comparison group. Nobody built the same 52 tasks a second time with a single agent to measure the difference. Only runs that finished and shipped were surveyed, so abandoned work is invisible in the data. Our harness surveys also did not record token totals. They say "not captured" instead of pretending the number is zero.

So we will not publish a return-on-investment figure. We do not have one that would survive this blog's own counting rules.

The layers are not infallible either. In one Govafy run, every gate and check passed, and a routine check after release still found a user-facing routing failure the whole pipeline had missed. That run is in our evidence too.

Here is what we can show instead. On small local smoke runs with partial cost capture, the recorded equivalent cost ranged from $0.67 to $3.65 for candidates, judges, and Integrators. Those figures are not complete current-workflow bills, and subscription CLI estimates are not billing truth. One fail-closed run recorded a $1.66 equivalent cost but could not verify its result. Its receipt says fusion_verified: false. Fusion issued no Verified stamp and charged no Fusion credits because the run did not meet its contract. Model-provider token charges can still apply, especially when customers bring their own keys. A failed run is free explains the distinction between Fusion's charge and the underlying model spend.

Fusion is a bounded tournament, not an open-ended swarm

Swarm is a broad label for multi-agent systems. Some swarms use copies of one model, while others mix models. Some divide work into pieces, let agents exchange messages, and assemble a shared answer. That can be useful when the work separates cleanly. It also creates more paths through which an early mistake can spread.

The research here is useful but needs context. Google Research evaluated 180 agent-system configurations in a study published this January. Agents working in parallel with no coordination amplified errors by up to 17.2x. A central coordinator contained the same amplification to 4.4x. On tasks that must happen in strict order, every multi-agent variant they tested performed 39-70% worse. None of their benchmarks involved working inside a real codebase, so treat the numbers as evidence about the mechanism rather than a forecast for your repository. The mechanism still matters: uncoordinated agents can compound each other's mistakes.

Anthropic reported that its multi-agent research system used about 15x the tokens of an ordinary chat and concluded that the economics work only when the value of the task covers the spend. That figure comes from research workloads, not coding. The same write-up notes that most coding work parallelizes less readily than research does.

Fusion is built around both findings, and it differs from an open-ended swarm in two ways that matter.

The diversity is deliberate. Repeated samples from one model can produce useful variation. Cross-provider diversity adds another source of contrast because models from different labs do not share identical training and tendencies. Our measured tournaments paired models from different labs. The candidates repeatedly noticed different things. One might supply the stronger architecture while another catches a narrow safety risk. The jury judges across model families too, blind to which model wrote what, so no lab grades only its own homework.

The structure is bounded. The parallel part of a run is the one place independence genuinely helps: rival candidates attempt the same locked task without seeing each other's work. Everywhere errors could spread, there is a controlled sequence. One coordinator controls state. One protected test gate remains outside candidate control. One blind jury compares evidence. Repair loops are bounded, and one receipt records the result. Candidates do not negotiate a shared answer. Later roles consume frozen artifacts and hold different jobs under different incentives: build, compare, combine, and attack.

An open-ended swarm asks how many agents it can add. Fusion asks two harder questions: do these agents provide useful independent evidence, and which result has earned the right to be believed?

When one agent is the better buy

Often, and we would rather tell you than have you find out.

The Agentless study made the case well. A simple three-step pipeline found the faulty spot, wrote the fix, and checked the fix. It solved 32% of SWE-bench Lite, a standard benchmark built from real GitHub issues, at about $0.70 per issue. That kept pace with far more elaborate open-source agents at the time. Cheap and simple is a serious baseline. We treat it as one.

Our own surveys agree, and we publish the uncomfortable ones on purpose. One Govafy survey concluded that a single agent plus one mandatory independent adversarial QA pass would have captured roughly 85% of the value at about half the build cost for a narrow, well-scoped change. Another flatly called the full tournament overkill for a small, low-risk UI change. Both verdicts came out of our own process, and both sit in the evidence briefs next to the wins.

That is why depth is a dial, not a doctrine. A small, reversible change with solid existing tests deserves one builder and one fresh reviewer. An ambiguous problem with more than one plausible design deserves two candidates and a jury. Anything guarding money, access, recovery, or releases deserves the full tournament. There the expensive failure is not a broken patch. It is a polished patch that quietly weakens a guarantee. The roster is a knob, and the price follows the depth you choose. Fusion charges its fee only when the run meets its Definition of Good, the pass-or-fail checklist agreed before work starts. Underlying model-provider charges remain separate.

Three kinds of spend

One last honesty cut, because "more tokens" blurs three different things.

Deliberate redundancy is the cost of options. Rival candidates exist so the jury has something real to compare. Across measured harness runs, about half of candidate work was not adopted. That is the price of contrast, the same way a design review pays for the sketches it rejects.

Verification spend is a reviewer who finds nothing. That is not zero return. It is the implementation surviving an independent attempt to break it. Teams already buy this every time a security test comes back clean.

Operational waste is the real enemy: stalled sessions, duplicate launches, and environment failures. Our Govafy surveys logged plenty of it. Every instance feeds the fix list. Each one we remove makes the honest spend cheaper without weakening the verification.

The meter that matters

The cheapest way to produce a patch is one strong agent, and nothing in our data disputes that. The cheapest way to be right about a change that matters is a different purchase.

Tokens price the run. Being wrong prices the ship.

When the work is small, buy less Fusion. When the work guards money, access, or trust, the extra sessions are not overhead. They are the product.

Source ledger