Fuse
Concepts

How Fuse works

The warm-index pipeline behind a Fuse call: index, localize, resolve, expand, plan, render, and why it is shaped this way.

Fuse answers a context request from a warm, persistent index of the workspace. The index contains a typed semantic graph when the project loads semantically and a thinner syntax view when it does not. This page is the model behind a call. For the exact parameters of each tool, see the Tools reference; for how an agent strings calls together across a task, see The iterative workflow.

A warm index is a semantic graph that stays built between calls, stored in a single SQLite file at .fuse/fuse.db. Building it once and reusing it is what makes resolution and context planning cheap on the second and later calls.

The Pipeline

Loading diagram...
Loading diagram...
StageWhat it does
1. IndexExtract the best available semantic or syntax view and persist it.
2. LocalizeRank candidate files and symbols through the lexical channel, no bodies.
3. ResolveMap a service, request, route, config, or symbol to its real target.
4. ExpandWalk typed edges from the seeds, weighting and pruning the neighborhood.
5. PlanPick what to keep under the token budget; seeds are always kept.
6. RenderEmit source at mixed tiers, with a manifest and per-file provenance.

1. Index

Indexing loads the workspace through MSBuild and Roslyn and records a typed graph of nodes (types, members, routes, DI registrations, options bindings) and edges (calls, implements, injects, handles, binds). When a project does not load, Fuse falls back to syntax-only indexing for that project, which records fewer edges. The result is persisted to .fuse/fuse.db in WAL mode and reused on later calls, so the analysis cost is paid once. The index mode is reported as semantic, partial, or syntax.

2. Localize

Localization turns a free-text task into ranked candidate files and symbols, each with a reason and a token cost, and no source bodies. It uses deterministic lexical retrieval with subword, stem, comment, and dependency-centrality signals. Fuse ships no embedding model. Named routes, symbols, services, requests, and config sections use resolution instead.

3. Resolve

Resolution is the deterministic core. Given a name, Fuse walks the graph to its real target: a service interface to the concrete type registered for it in DI, a request or command to its handler, a route to its action or endpoint, a config section to the options type that binds it, or a symbol to its declaration. This is what text search cannot do: it finds the type that actually runs, not the one a name matches.

4. Expand

From the seeds (the localize candidates, the resolved targets, or the files in a Git diff) Fuse walks typed edges outward to a configurable depth. Each hop is weighted, and the expansion prunes low-weight branches so the result stays bounded rather than becoming the whole transitive closure. In review mode, Git supplies the changed files as must-keep seeds; expansion adds compact branch context rather than discovering the change set.

5. Plan

The plan chooses what to emit under the token budget. Must-keep seeds are always included; the rest fill the budget by weight, and the render tier of each file is chosen so the budget lands close to full. A budget of 0 means no limit.

6. Render

Rendering emits the planned set as source bodies at mixed render tiers (full, compressed, or signature-only skeleton), with a manifest that lists each file and its token cost and per-file provenance that records why each file is present. Best-effort secret redaction runs before source is added to the payload, and the chosen output format (xml, markdown, or json) is applied last.

Why It Is Shaped This Way

The stages are separated because they change for different reasons. Indexing cares about the build and the parse, localization and resolution about relevance and wiring, expansion about the graph, and rendering about output shape and budget. Keeping them apart means the persistent index is built once and reused, resolution is deterministic and independent of how context is later rendered, and a new language is an indexing and rendering concern, not a pipeline change. The deeper design is in the pipeline internals.

Tokens, the Unit That Matters

A token is the unit a language model reads. Models have a fixed context window measured in tokens, so the token count of a context plan decides how much of that window it consumes and what it costs. Fuse counts with a real tokenizer rather than estimating from character length, so the manifest's numbers match what the target model sees. See Tokenizers.

Inspect the Pipeline

Run fuse diagnostics ./src to read the index mode, then run fuse context ./src --seed OrderService --max-tokens 15000 --format markdown. Inspect the manifest to see each file's token cost, render tier, and provenance.

On this page