Fusion Harness V2: Three Models Debating Inside One Agent

Step-by-Step Breakdown

1. Pick a model stack, not a model

   The harness is configured with several models running side by side in one terminal session. In the demo that is Claude Fable 5, Gemini 3.7 Flash, and DeepSeek V4 Pro; a second configuration shown later runs five models. The stated principle is "combine compute, don't select compute" — the point of the setup is to get several independent perspectives on one question rather than to find the single best model.

2. Give every model an alias, never its real name

   Each model in the session is addressed by a codename — rune, flux, drift — rather than by its model ID. This is presented as a hard requirement, not a stylistic choice: when models can see which model produced a rival answer, they start emitting competitive behaviour and, in his words, begin sabotaging each other. The aliasing is what keeps a debate honest.

3. Run the cheap pass first — a parallel opinion poll

   The opinion command fans one prompt out to every model and returns the answers side by side, each annotated with performance, speed, and cost. In the demo the prompt asks which feature of the DuckDB V2 preview a developer building a local-first analytics app should test first. Two of three models converged on the same answer; the third drifted, which is itself the signal you were buying.

4. Escalate to a structured multi-round debate

   The debate command takes a single claim in quotes and runs the models through several rounds. Round one is independent positions. Between rounds, every agent's response is shared with every other agent, so round two shows each model explicitly reporting whether its position changed and what changed it ("position unchanged", "what changed my mind: nothing did"). The session ends with a forced closing statement from each model. All three rejected the claim, which he treats as a much stronger result than one model rejecting it.

5. Use collaborate for build work — many planners, one architect

   The collaborate command has every model read the project structure and produce its own full plan. Those plans are written to a shared template with task IDs (T1, T2, T3), explicit task dependencies, a proposed team split, a risk analysis, and a "collisions and safety concerns" section. One model is designated the architect — always exactly one, and always the most capable model you are willing to pay for — and it merges the competing plans into a single checklist, assigning an owner and a mode per task. The other models then execute against that checklist while the architect does final integration and validation.

6. Read the cost column every time

   Each run prints a per-model cost breakdown, and he treats that as the primary feedback loop rather than a footnote. His framing is not "cost per token" but effective agent-hour per token cost — a cheap model that loops inefficiently is not cheap. The collaborate run finished at $0.65 for Fable 5, $0.07 for Gemini 3.7 Flash, and $0.05 for DeepSeek V4 Pro; a single Fable 5 response in the debate run cost $0.15 on its own.

Commands & Code Shown

Command names are given as spoken in the video and prefixed here for readability. The fusion harness is a custom extension registered against the Pi coding agent, so the exact prefix depends on how you register it in your own harness — the orchestration patterns are the transferable part, not the literal strings.

fh opinion

fh opinion <prompt>

Purpose: Fans a single prompt out to every model in the stack in parallel and returns all answers side by side with per-model performance, speed, and cost.

When to use: First contact with an unfamiliar tool, library, or release, when you want to see whether independent models converge before you trust any single answer. This is the cheap pass — run it before escalating.

fh debate

fh debate "<claim to test, as a single quoted statement>"

Purpose: Runs multiple rounds in which every model states a position, then receives every other model's position and revises or holds. Ends with a forced closing statement from each participant.

When to use: Strategic or architectural decisions with a long commitment horizon — the ones he describes as month-long or year-long calls. Called out in the video as the most valuable of the three commands.

fh collaborate

fh collaborate <build instruction>

Purpose: Every model produces an independent plan; the single designated architect merges them into one task list with owners, modes, and dependencies; the remaining models build against it and the architect does final integration.

When to use: Actual build work where you want plan diversity before committing. The demo instruction was to build a working demo of the top three features from the DuckDB release as Astral uv single-file scripts.

System prompt configuration

append_system_prompt: <one or more system prompt files>
model: <model name>
thinking: <on/off>

Purpose: The per-agent config shown on screen is deliberately minimal — an appendable system prompt (multiple can be stacked), the model name, and a thinking toggle.

When to use: He reuses the same system prompt across every model in the stack so the plan templates come back in a comparable shape. His advice is explicit: keep it simple, don't over-complicate the config.

Commands mentioned but not demonstrated

fh auto-validate
fh fusion

Purpose: Both are flagged in passing as significant parts of the V2 harness and left as exploratory work.

When to use: Not shown in the video — noted here only so you know they exist.

Gotchas & Caveats

• Never reveal a model's identity to the other models. This is the single most actionable detail in the video. Use aliases. When models learn which competitor produced a rival answer, they begin behaving competitively and sabotaging each other — behaviour he describes as emerging naturally and without a clear cause.
• There must be exactly one architect. The collaborate pattern depends on a single merge point. That slot is where your expensive model goes; putting a cheap model there wastes the diversity the other agents produced.
• Watch for pricing cliffs, not just headline rates. He flags that on the GPT 5.6 series, crossing roughly 280K context doubles the input price and multiplies output by 1.5 — so the advertised rate is not the rate you pay on long agent sessions.
• Benchmarks mislead on local models. Qwen 3.8 27B benchmarks near the top tier, but in his hands the context window is the real constraint and the lack of a mixture-of-experts variant makes it think slowly on local hardware. His advice is to deploy a model against your own use case before believing a leaderboard.
• Running the API costs real money. He is upfront that this workflow is API spend, not subscription usage, and that a subscription plan insulates you from what these models actually cost. Budget for it before adopting the pattern.
• This is not a replacement for a mainstream harness. He continues using Claude Code for in-loop work, and cites the subscription as the reason. The fusion harness is a parallel tool for comparison, decision-making, and plan diversity.

Key Takeaways

• Multi-model orchestration is three distinct patterns, not one: parallel polling, adversarial debate, and architect-led collaboration. Each answers a different question and costs a different amount.
• Convergence across independently-run models is the actual product. When three models reach the same conclusion without seeing each other, that is worth far more than any one of them saying it confidently.
• Model aliasing is a functional requirement of multi-agent debate, not cosmetic — identity leakage changes model behaviour for the worse.
• Mid-tier models did the same job for roughly a tenth of the frontier cost in these runs, which is what makes running three of them at once affordable in the first place.
• The argument for owning your harness is flexibility under model churn: if you cannot swap models and rewire the agent loop, you cannot take advantage of a fast-moving model landscape.