Skip to content
FUMODocs

Capability and cost, measured together

Fusion evaluations measure task outcomes alongside the resources used by the complete system.

The results below come from FUMO Lab's Fusion whitepaper, Revision 0.1 (August 2026). The data and experiment details are in Section 5: Performance Beyond Proportional Compute↗.

Costs are in US dollars for one complete benchmark run, rounded to the nearest dollar. API pricing is quoted separately.

Reported results

Each benchmark is reported separately using its own score. Within a benchmark, higher scores and lower costs are better.

SystemGPQA Diamond scoreCost (USD)τ³-Banking scoreCost (USD)Terminal-Bench v2.1 scoreCost (USD)
Fusion Max94.9%$1349.5%$14586.5%$74
GPT 5.6 Sol (max)94.1%$2244.3%$25188.0%$86
Claude Fable 5 (fallback)92.6%$4538.1%$32284.6%$299
Sakana Fugu Ultra94.4%$9541.2%$22479.8%$144
Fusion Code93.5%$748.5%$15989.9%$71
Claude Opus 5 (max)93.2%$1842.1%$19389.1%$215
Kimi K393.5%$3046.0%$12285.0%$56

Source: the comparison table in Section 5 of Revision 0.1↗. Labels such as “max” and “fallback” identify the configurations used in those runs.

What the benchmarks test

GPQA Diamond — scientific reasoning

This workload tests difficult scientific reasoning. It probes whether complementary work and final judgment can improve answers to expert-level questions.

τ³-Banking — policy-constrained tool use

This workload tests whether agents can use knowledge, follow domain policies, and complete an interaction through tool calls.

Terminal-Bench v2.1 — agentic coding

This workload tests executable work in terminal environments. Planning, implementation, debugging, recovery, and external verification all matter to the result.

The three workloads cover different skills and failure modes. Use representative tasks from your own workflow to assess product fit.

Capability and cost trade-offs

The two Fusion products are different operating profiles of one system:

  • Fusion Max scores higher than GPT 5.6 Sol on GPQA Diamond and τ³-Banking in the reported runs, while its Terminal-Bench score is 1.5 percentage points lower. Its reported full-run cost is lower on all three.
  • Fusion Code meets or exceeds Claude Opus 5's reported score on all three workloads at lower full-run cost.
  • Compared with Kimi K3, Fusion Code matches or improves the scores, with higher costs on the Banking and Terminal-Bench runs.

The whitepaper's score–cost charts connect measured non-dominated points. At each such point, improving the score or reducing the cost requires a trade-off among the reported alternatives. The lines connect measured configurations only.

The preferred configuration depends on the workload and the balance of capability and cost you need.

Comparison limits

The whitepaper explicitly qualifies its Sakana Fugu Ultra comparison:

  • Model and provider snapshots differ.
  • Banking and Terminal-Bench runs are official-compatible rather than identical submissions.
  • That Terminal-Bench run is not leaderboard-comparable.
  • Fugu's GPQA score is 185/196 scored cases; two additional selected cases ended in execution errors.

The comparison table in Revision 0.1 does not include repeated-run uncertainty estimates or a complete per-run configuration manifest, so small score differences should be interpreted cautiously. Reproduction also requires latency data, attempt counts, timeouts, concurrency, cache treatment, scorer versions, and all internal model usage. Costs should cover the complete system, including all internal model calls.

A long-horizon example

The whitepaper also describes one Fusion Code Terminal-Bench path-tracing task: reconstructing an image from an unknown binary as a dependency-free C program under a compressed-source size limit.

The run changed its inspection method when basic utilities were unavailable, proceeded through analysis and implementation, and finished with external verification. It took about 29 minutes and 49 agent steps; the benchmark verifier passed all five tests.

The trace illustrates recovery and verification within a single task. Reliability across longer workflows requires evaluation over a larger set of tasks.

Evaluate your own workflow

Use the reported operating points to choose a starting profile, then test representative tasks with your own acceptance conditions. Record end-to-end success, latency, cost per successful task, tool failures, and premature completion. Keep infrastructure or scorer errors separate from model failures.

For experiment details or a workload-specific evaluation, contact FUMO Lab.

Read the whitepaper↗ · How Fusion works · Start using Fusion