I built Fuse after watching coding agents repeatedly read and search the same .NET files to recover symbols, references, DI wiring, and project structure. On the write path, proposed C# changes often went through a longer edit and dotnet build loop just to get semantic feedback.
Fuse loads the solution through MSBuild and Roslyn, persists the derived index locally, and updates changed files incrementally. The same index supplies exact symbol lookup, .NET framework wiring, reduced task-scoped source, change impact, and Git-seeded review.
For proposed single-file C# content, fuse_check uses compiler state captured from the real build when available. It falls back to a scoped build and abstains if neither path can run.
This is not a claim that repository indexes or code graphs are new. CodeGraphContext, Serena, Sourcegraph, and coding-client indexes cover related parts of the category. Fuse is narrower: local .NET analysis through MSBuild and Roslyn, including framework-specific wiring and captured-compiler checks.
On the recorded NodaTime semantic index with 14,760 symbols, exact lookup was 1.8 ms at the median and task localization was 15.7 ms. In a separate compiler-labeled suite over the OrderingApp test families, Fuse recorded 0 false green and 0 false red on 1,000 generated single-file edits plus 8 curated cases. Both results are machine- and sample-bounded.
Analysis runs locally and can work offline. No model is required. The update check and a build using configured package feeds are the network-dependent cases.
Methods and limits: https://fuse.codes/docs/project/benchmarks
Reproduction: https://fuse.codes/docs/project/reproduce
Install: dotnet tool install -g Fuse
Repository: https://github.com/Litenova-Solutions/Fuse
Why can’t you use the charp LSP plugin for Claude code?
What does this give beyond that?