Introducing Fuse v5: Up to 7.4x Faster dotnet build and 5.7x Faster dotnet test for AI Agents

If you use Claude Code, Cursor, Codex or Copilot on a .NET repository, your agent checks its work by running dotnet build and dotnet test, often dozens of times in one task. Fuse 5 is a .NET tool that answers those checks from a solution it keeps loaded in the background. On four open-source and generated repositories it found the compiler errors an edit caused up to 7.4x faster than dotnet build, and ran the affected tests up to 5.7x faster than dotnet test.

This post is for .NET developers who let AI agents edit their code. It covers the problem Fuse solves, what the agent gets, the benchmarks, what Fuse costs, and how to set it up in one command.

The problem: agents verify with the slowest tools you have

A person runs dotnet build when they think they are done. An agent runs it after almost every edit, because it has no other way to know whether the code compiles. Each run has three problems:

• It is slow. MSBuild evaluates the projects, resolves references and compiles again, even when the agent changed one line in one method.
• It prints too much. A build log or a full test run is thousands of tokens, and most of it says that things are fine. The agent reads all of it.
• It does not scale to subagents. Three subagents running dotnet build at once load the solution three times and fail on each other's locked files in bin and obj, with errors such as MSB3021 and CS2012.

There is also a quieter problem. A build reports every error in the solution, including the ones that were already there before the agent started. The agent cannot tell which errors are its own, so it spends turns fixing problems it did not cause.

What Fuse gives the agent

Fuse keeps a warm Roslyn compilation of your repository in a background process, the engine, and compares the working tree with the last commit (HEAD). After each edit, it tells the agent two things:

• which compiler errors the edit caused, in every project
• which affected tests fail

In practice that means:

• Only introduced errors. An error that already existed at HEAD is never reported, so the agent works on what it broke.
• Breaks in other projects. Rename a method in a library, and Fuse lists every broken caller in every project that uses it, with the declaration change that broke it.
• Only affected tests. Tests the change cannot reach do not run. When only .cs files changed, the tests run without MSBuild.
• Short output. At most 20 errors or 10 test failures, plus one summary line. A clean edit produces no output at all.
• Made for subagents. All agents in a repository share one engine, so the solution is loaded once. Builds and test runs through Fuse take turns, so parallel builds do not fail on locked files. Each git worktree gets its own engine.

Here is what the agent sees after renaming Calc.Add in a library that two other projects use:

$ fuse check
App/Program.cs(3,30): error CS1061: 'Calc' does not contain a definition for 'Add' and no accessible extension method 'Add' accepting a first argument of type 'Calc' could be found (are you missing a using directive or an assembly reference?)
  removed: public int Add(int a, int b)
Lib.Tests/CalcTests.cs(6,54): error CS1061: 'Calc' does not contain a definition for 'Add' and no accessible extension method 'Add' accepting a first argument of type 'Calc' could be found (are you missing a using directive or an assembly reference?)
  removed: public int Add(int a, int b)
fuse: 2 error(s) introduced in 2 file(s) (App, Lib.Tests); Lib declarations changed, 2 dependent project(s) checked

Two errors, the line that caused them, and one summary line. No build log.

The benchmarks

The evals in the repository run the fuse executable the way an agent does and compare every answer with a real dotnet build or dotnet test. They ran on one Windows machine against four repositories: a small generated solution, NodaTime, Jellyfin and the .NET Community Toolkit. The times below are medians.

Once the engine has loaded the edited project, a check after an edit inside a method body took between 164 ms and 714 ms at the median, depending on the repository.

Speed does not help if the answers are wrong, so the evals also check accuracy. Across 120 generated cases (168 edits), Fuse missed 1 compiler error that the build reported, and reported no error that the build contradicted. The one miss was on NodaTime: the edit made a method private, the build reported a follow-on CS1503, and Fuse reported a different but accurate CS0122 at the same five places. The Benchmarks page explains each row, names the result files behind it, and lists the commits measured.

The test speedup depends on how much of the suite a change reaches. On the Community Toolkit a change usually reaches one area of the code, so fuse test ran 13.7 percent of the tests on average. On NodaTime most changes reached an application project that Fuse cannot trace to tests by name, so it ran 80 percent of the tests, and the time saved came from running without MSBuild.

What it costs

Fuse is not free, and it is better to know the costs before you install it:

• Memory. The engine keeps the loaded projects in memory until it has been idle for 30 minutes: 271 MB to 2,429 MB in the benchmarks. Each git worktree uses its own engine.
• A slow first check across projects. The first edit that affects other projects has to load them. On Jellyfin (40 projects) that took up to 49.1 s; the median signature edit took 186 ms.
• One check at a time. Agents in the same repository wait for each other's checks.
• Not a full build. Fuse checks C# only and selects tests by reading the code, so a few cases still need fuse build or fuse test --all. The Limits page lists them.

Fuse also stays out of the way when something goes wrong. If Fuse fails, the hook exits silently and the agent carries on as if Fuse were not installed. Fuse never edits your code, never runs dotnet restore on its own, runs locally and sends no telemetry.

Set it up

You need the .NET 10 SDK, a git repository with at least one commit, and restored projects.

Install the tool:

dotnet tool install -g Fuse

Then, in the root of your repository:

fuse init

wrote .claude/settings.json
wrote .gitignore
fuse: hooks registered; after each edit your agent gets the compiler errors the edit introduced, `dotnet test` runs the affected tests, and `dotnet build` prints only its errors

That is the whole setup. There is no configuration file. fuse init detects which agents the repository uses and registers Fuse with each one:

From then on the agent gets Fuse's answer after each edit, and its dotnet build and dotnet test commands run through Fuse. You can run fuse check, fuse test and fuse build in a terminal yourself; they print exactly what the agent receives.

What is new in 5.x

Fuse 5.0.0 was a complete rewrite of the 4.x line, built around the engine, the hooks and the three-tool MCP server. Fuse 5.1.0, the current release, makes subagents safe to run side by side: builds and test runs through Fuse take a per-repository lock, so they no longer fail on each other's files. It also adds a cause line under each error in a file the agent did not edit, and fixes a long list of cases where a check or test selection missed a change. If you are on 5.0.0, run fuse init again after updating; the changelog has the upgrade steps.

Try it

Install Fuse on a repository where your agent already runs dotnet build and dotnet test, and watch how many turns and tokens a task takes. Getting started walks through the setup and shows what the hooks send the agent.

Fuse is open source under the Apache 2.0 license. Bug reports, questions and pull requests are welcome on GitHub, and the package is on NuGet.