What happens when the sidekick can’t satisfy the spec?

The main agent escalates on a ladder: feedback naming the specific miss, then — after two misses — it authors the exact patch itself (file, line range, verbatim code) and hands it over to apply. A verbatim patch needs no judgment, so the loop cannot deadlock; you lose the cost saving on that one task only. If even the dictated patch fails verification, the plan is wrong, not the sidekick — the main agent revises the plan.

What if agents ignore the prompts or never load the skills?

You lose quality, not guarantees. Delegation is not a behavior the main agent chooses: its edit and search tools are removed from its tool schema, so handing work to the sidekick is the only path to changing a file. The fusion-audit plugin and OpenCode’s session DB record what every agent actually did.

How is this different from superpowers or other orchestration?

Different layer. Skill libraries like superpowers teach agents how to work — process knowledge the model can still ignore. Fusion configures what agents can do at the permission layer, and adds per-role model routing for cost with cross-vendor review as a side effect. No framework, no code — just configuration on a normal session. The two compose: superpowers supports OpenCode, so its skills can run inside a Fusion setup.

Docs — opencode Fusion

Overview

opencode Fusion is a configuration project, not an app. It implements the Devin Fusion sidekick pattern: a main agent that plans and reviews but cannot edit files, and a cheaper sidekick that executes every change.

The main agent’s file editing is denied at the permission layer. Its only way to change a file is to hand a spec to the sidekick. Frontier intelligence stays on the plan and the review; mechanical work stays cheap.

Built for OpenCode. The v1 reference implementation with mechanical edit deny, multi-provider models, and a setup skill.

How it works

One cycle: main explores (via helpers), plans, hands the sidekick a spec, reviews the diff, loops until it passes, then delivers.

Agent	Role	Required
`build`	Main: plan, delegate, review	Core
`plan`	Plan mode — same brain, no execute	Core
`sidekick`	Execute edits and commands	Core
`explore`	Fast read-only search	Core
`research`	Read-only web / docs research	Optional
`design`	Frontend / UI implementation	Optional
`reviewer`	Critique a plan before implementation; audit a diff before commit	Optional
`vision`	Transcribe images if main cannot	Optional

Pick main and sidekick from different model families when you can. The main agent’s review of every sidekick diff becomes cross-vendor for free.

Enforced vs. advised

The pattern’s guarantees live in two layers. Knowing which is which answers most “what if the model just ignores the instructions?” questions.

Enforced — the permission layer

OpenCode checks these on every tool call, regardless of what the model reads or intends. The main agent’s edit, grep, glob, and list are denied — denied tools are removed from the model’s tool schema entirely, so there is no edit tool for it to decline to use. Bash is deny-by-default with a short verify/git allowlist, and delegation is bounded by an explicit task allowlist. If the main agent “won’t delegate,” the result is visible inaction — never a silent bypass.

Advised — the prompt layer

Spec precision, diff-review rigor, cost discipline, and skill usage are instructions in the agent prompts. Skills load at the model’s discretion in OpenCode — nothing can force an agent to read or apply one — which is exactly why no guarantee depends on them; the skill in this repo is just the installer. Slacking here costs quality or tokens, never an unauthorized edit.

Auditable

The optional fusion-audit plugin logs the delegation tree, and OpenCode’s session DB records every agent’s actual tool calls — “did it really delegate?” is checkable ground truth.

Install OpenCode

Fusion lives in your global OpenCode config. No build step; nothing to clone into each project.

Offline / manual fallback

From a clone of this repo, copy .opencode/skills/fusion-setup into ~/.config/opencode/skills/ (Windows: %USERPROFILE%\.config\opencode\skills\), then run the setup flow as above — skills are discovered on demand, no restart needed.

After setup

The skill writes ~/.config/opencode/opencode.json, installs agent prompts under ~/.config/opencode/agent/, and asks you to restart. To change models later, say “reconfigure fusion” or edit the config directly.

Verify

Open any project that has some lint errors and ask:

Prompt

fix the lint errors in this project

Main delegates via task; sidekick edits; main runs the project’s own lint or test command (for example npm run lint) itself to verify.
Main must not edit files directly — edits and freeform shell are denied at the OpenCode permission layer.
An occasional struck-through command with a permission error is expected — bash is deny-by-default, and the agent recovers by reading the file or delegating. A denied command is the guardrail working, not the setup failing.

Customize

Swap models

Edit ~/.config/opencode/opencode.json under agent.<role>.model. Restart after changes. Keep the sidekick cheaper and faster than main when you can. OpenCode’s multi-provider setup makes cross-family main/sidekick pairs easy.

Role behavior

Agent prompts live under ~/.config/opencode/agent/ after setup (and under agent/ in this repo). Edit those role files when you want different behavior, then restart OpenCode so config reloads.

Bash allowlist (OpenCode main)

Main agent bash is allowlisted for verify and git. Keep "*": "deny" first. Do not chain commands with &&, ||, ;, or | — each call is matched alone.

Troubleshooting

If you installed the optional /fusion-status command, run it first — it checks the usual suspects in one shot: live enforcement in the running session, the config on disk, and the installed agent files. It only reports; it changes nothing.

Main agent edits files directly: Config was not loaded. Fully quit and restart OpenCode. Confirm edit: deny for the build agent in permission frontmatter.
Sidekick is never invoked: Ensure task: allow on the build agent so main can delegate to sidekick.
Model returns 404 or 400: Check exact provider-id/model-id, provider baseURL, and credentials. Some local proxies omit models from /v1/models even when the id works.
Bash command blocked unexpectedly: Denials of non-allowlisted commands are expected and self-recovering. If an allowlisted command is blocked: the allowlist matches whole commands, so chaining or wrapping breaks the match. Run each allowed command as its own call.

Limitations

No dynamic mid-session routing. Model per role is fixed at startup. Devin’s mid-task model swap needs a closed product runtime and is an explicit non-goal here.
Config loads at startup. Any change to config or agent prompts needs a full restart.
Loop protection is permission-based. Nested delegation is bounded by the task graph (sidekick may spawn only read-only searchers), not numeric depth caps.

FAQ

What happens when the sidekick can’t satisfy the spec?: The main agent escalates on a ladder: feedback naming the specific miss, then — after two misses — it authors the exact patch itself (file, line range, verbatim code) and hands it over to apply. A verbatim patch needs no judgment, so the loop cannot deadlock; you lose the cost saving on that one task only. If even the dictated patch fails verification, the plan is wrong, not the sidekick — the main agent revises the plan.
What if agents ignore the prompts or never load the skills?: You lose quality, not guarantees — see Enforced vs. advised. Delegation is not a behavior the main agent chooses: its edit and search tools are removed from its tool schema, so handing work to the sidekick is the only path to changing a file. The fusion-audit plugin and OpenCode’s session DB record what every agent actually did.
How is this different from superpowers or other orchestration?: Different layer. Skill libraries like superpowers teach agents how to work — process knowledge the model can still ignore. Fusion configures what agents can do at the permission layer, and adds per-role model routing for cost with cross-vendor review as a side effect. No framework, no code — just configuration on a normal session. The two compose: superpowers supports OpenCode, so its skills can run inside a Fusion setup.