Normally one agent does everything: reads the code, decides what to change, and makes the change. Fusion splits that. The lead stays focused on decisions, and hands off two kinds of work to a sidekick:
/fusion
That enables the harness for every session. There is no argument and no per-session toggle.
A single agent holding a whole task in context degrades as the task grows: the details of a wide file search crowd out the reasoning about what to do with them. Fusion keeps those apart. The lead sees a summarised answer rather than every file it took to get there, so its context stays about the decision.
Note
Fusion is most valuable on large, unfamiliar codebases where finding the relevant code is a substantial part of the work. On a small change in a file you already named, it adds coordination for no benefit.
| Role | Does |
|---|---|
| Lead | Holds the task, makes decisions, integrates results |
| Sidekick | Executes one bounded stream of work, or answers one evidence question |
| Advisor | Recommends when the lead should delegate rather than continue alone |
The advisor is a private recommendation to the lead, not an instruction — and it fails open. If it errors or times out, the turn continues with the lead deciding for itself.
A delegation is not "go look at this". The lead must state the architectural approach and execution boundary, the constraints and invariants to preserve, and the concrete deliverable that must exist when the sidekick is done. Discovery of how happens inside that boundary; decisions about what stay with the lead.
The same applies to evidence requests: one bounded question, the facts already established, and the scope that constrains the search.
Fusion runs more than one agent, so a turn costs more than an unfused one. Usage is tracked per
role, and /stats shows the split — lead, sidekick, advisor — rather than one combined
number, so you can see where the spend went.
Warning
Every delegation is an extra model call billed against your tier and budget. A task the lead could have finished alone is more expensive with Fusion, not less. Enable it for the work that benefits, not as a default for everything.
Fusion is stored as agent configuration, not session state, so it persists until changed. Use
Change fusion config from the command palette (ctrl+p) to adjust or disable it.
In the VS Code extension the same controls are settings: latentcode.fusion.enabled and
latentcode.fusion.sidekickModel.
| Use case | Effect | Why |
|---|---|---|
| Migration | Much better | Finding every call site is exactly the wide, context-hungry search worth delegating, while the lead keeps hold of the conversion rules. |
| Bug-Fixer | Better | Locating the defect is evidence work; deciding the fix is not. The split matches how the task actually divides. |
| Feature Development | Better | Pays off on an unfamiliar codebase where orientation is most of the effort; less so on code you already know. |
| Reviewer | Some | /review already fans out across aspects, so the two overlap — running both mostly duplicates cost. |
| Design / Architecture / Planning | Little | Planning is the lead's own reasoning. There is little to hand off and nothing to execute yet. |
| Testcase creation | Little | Writing tests is usually narrow enough that a handoff costs more coordination than it saves. |
The deciding question is whether finding things is a real part of the task. If it is, Fusion helps; if you can already name the files, it mostly adds cost.