opencode-fusion

A minimal, working multi-model team for opencode: a main agent that plans and reviews but cannot edit files, delegating every change to a cheaper, faster sidekick. Inspired by the Devin Fusion "sidekick" pattern from Cognition.

The main agent's file editing is mechanically denied. Its only way to change a file is to hand a spec to the sidekick. That keeps frontier intelligence on the decisions that matter (the plan, the interpretation of ambiguity, the review) while a cheap model does the mechanical work. Cognition reports the pattern holds frontier-level quality at roughly 35% lower cost on their own FrontierCode benchmark, and in a July 2026 follow-up measured a Fable 5-led setup at 54% below pure Fable 5 with near-identical quality: cheaper in absolute dollars than an Opus 4.8-led setup, despite Fable's 2x per-token price.

The main pair is backed by read-only helpers (explore, research) and optional specialists (design, reviewer, vision), each on a model you choose. See the full team.

Quick start • How it works • Setup • Customize • FAQ • Troubleshooting

Demo

https://github.com/user-attachments/assets/6d9e96e2-654a-4bc4-82af-3c3f1a8bde91

One full delegation cycle in 38 seconds: the main agent plans, hands a spec to the sidekick, reviews the returned diff, and verifies the result, without ever touching a file itself.

Quick start

Install the setup skill globally, then let opencode configure everything conversationally:

npx skills add mihneaptu/opencode-fusion --skill fusion-setup -g -a opencode -y

set up fusion

The installer needs Node 20.12 or newer. On older Node (including Ubuntu's apt default) it crashes with a styleText error; Troubleshooting has three workarounds. The skill interviews you for a model per role, writes the global config, installs the agent prompts, and tells you when to restart. On a subscription (OpenCode Go/Zen, ChatGPT, or GitHub Copilot)? Name it and the skill starts from a ready-made profile instead of asking per role. Manual setup and provider examples live in Setup.

Why it works

From Cognition's blog post:

We've found that the main agent should take minimal actions, and only read what is absolutely necessary. By default it should delegate and monitor, while making the significant decisions: the plan, the interpretation of ambiguity, the final review.

This repo turns that into a hard constraint: the main agent's edit, search, and freeform bash tools are denied at the permission layer, so delegating to the sidekick is its only way to change a file. Two payoffs fall out of the split:

Lower cost. Implementation mechanics are most of a session's tokens. A cheaper sidekick handles them at near-parity while the expensive main model spends its tokens only on judgment: the plan, the spec, the review. The main agent's prompt enforces this discipline: emit judgment not volume, keep context lean, reason once then hand off. Cognition's follow-up study bears this out: in 81% of Fable-led Fusion runs, the lead model never made a single code edit. That is the behavior this repo makes mechanical rather than advisory.

Cross-vendor review, for free. When the main agent and sidekick are different model families (for example Opus reviewing Grok), every diff gets an independent second-family read before it lands. Models from one family share blind spots; a reviewer from a different lineage catches what same-family review misses. You get this just by picking a main and sidekick from different vendors.

How it works

The diagram shows one delegation cycle: the main agent delegates exploration, plans from what comes back, hands the sidekick a spec, reviews the returned diff, loops until it passes, then delivers the result.

Models move fast. Treat these as 2026 starting points, not requirements. Use any provider you like; in config each model is written as provider/model-id (for example openai/gpt-5.6-sol), and the sidekick should stay cheaper and faster than the main agent. The mix above spans several vendors on purpose, so the main agent's review of each sidekick diff is cross-vendor. If a subscription covers your models, a profile fills this table in for you.

Enforced vs. advised

The pattern's guarantees live in two different layers, and being precise about 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, no matter what the model reads, remembers, or intends:

• The main agent's edit, grep, glob, and list are denied. Denied tools are removed from the model's tool schema entirely; there is no edit tool for it to decline to use.
• Its bash is deny-by-default with a short verification and git allowlist, so file-writing commands are blocked. git commit and git push additionally require per-command user approval; common direct force/mirror/delete/prune forms are denied by later rules.
• Direct git commit and git push invocations plus common Git wrapper forms are denied for the sidekick and design agents, making review-then-commit the normal enforced path.
• Delegation is bounded by an explicit task allowlist: the main agent reaches only its named specialists, and the sidekick can spawn only read-only searchers.

If the main agent "won't delegate," the result is visible inaction: nothing on disk changes. The failure mode is never a silent bypass.

Advised: the prompt layer. Spec precision, diff-review rigor, cost discipline, parallelization, and skill usage are instructions in the agent prompts. opencode loads skills at the model's discretion (nothing can force an agent to read or apply one), which is exactly why no guarantee here depends on them; the skill in this repo is just the installer. If the model slacks at this layer, the cost is quality or wasted tokens, never an unauthorized edit.

Not guaranteed: the threat model. The permission layer bounds which tools each agent can call. It is not a sandbox, and it is worth being precise about what it does not protect:

• The .env denies on the executors stop the common accidental read (cat .env landing a key in a transcript), not a determined one. An agent with broad bash has many equivalent ways to read a file or the process environment, so treat those rules as accidental-leak prevention, not secret isolation. The {env:VAR} config syntax keeps keys out of plaintext config and out of the chat; it does not hide them from the environment agents run in.
• Git command rules match command text and are defense-in-depth, not a shell sandbox: wrappers, alternate executables, or obfuscation can bypass a finite pattern list when an executor has broad bash. They protect against common accidental commits and destructive pushes, not a hostile process. Editing files is the sidekick's job, and catching a wrong edit is what the main agent's diff review (and the optional reviewer) are for.
• The design agent's path-aware opencode tools are fenced to the workspace (external_directory: deny), but processes launched through broad bash are not OS-sandboxed by that rule. The sidekick keeps opencode's default ask for paths outside the project, because setup and reconfigure legitimately write the global config. Note that --auto mode auto-approves ask rules, so use external sandboxing too if an executor must never leave the repo.

Auditable: verify instead of trusting. The optional fusion-audit plugin logs the delegation tree, and opencode's session DB records every agent's actual tool calls (opencode db path prints its location, typically ~/.local/share/opencode/opencode.db). "Did it really delegate?" is checkable ground truth, not vibes.

Setup

Fusion lives entirely in your global opencode config at ~/.config/opencode/ (Windows: %USERPROFILE%\.config\opencode\). There is no build step and nothing to clone into your projects.

Recommended: let opencode set it up

This repo ships a skill, fusion-setup, that configures everything conversationally. Install it globally (Node 20.12+):

npx skills add mihneaptu/opencode-fusion --skill fusion-setup -g -a opencode -y

Or copy the fusion-setup folder from this repo's .opencode/skills/ into `~/