Back to all posts
Published on · by Renaud Deraison

Bromure Agentic Coding now includes Fusion mode

OpenRouter published a striking result: a panel of models, judged and synthesized, beats any single frontier model. We reimplemented that technique from scratch inside Bromure Agentic Coding — nothing routes through OpenRouter. Because the product already sits on the wire between your coding agent and the model APIs, version 3.0 puts our own Fusion right there. Flip the ⚡ in the title bar and up to three models answer every prompt at once. A judge reconciles them, a synthesizer writes the result, and Claude Code gets one answer back as if a single model wrote it. You bring your own keys or subscriptions, and the trace records every leg.

Last month OpenRouter published something we wanted right away: a panel of models, with one judging the panel and another writing up the verdict, beats the single best model on the board. It asks several models at once and synthesizes their answers into one. Their headline fusion landed at 69.0% on a deep-research benchmark where Fable 5 alone scored 65.3%. We didn't wire up their service — we reimplemented the technique ourselves, one layer down, in the proxy your coding agent already talks through. Bromure Agentic Coding 3.0 ships it as a single lightning bolt.

The mechanism is plain. You send the prompt to several models in parallel. A judge reads every answer and marks the agreements, the conflicts, what each model alone caught, and what all of them missed. A synthesizer then writes the final answer from that analysis rather than from eyeballing the drafts. OpenRouter's Fusion writeup lays out the mechanism we rebuilt, and the size of the gain surprised us: in one case, pairing a model with itself still lifted the score. Most of the gain comes from that synthesis step.

We knew where we wanted it. Bromure Agentic Coding runs your agent in a disposable Linux VM while a man-in-the-middle proxy on the host watches every byte it sends to api.anthropic.com. We already hold the wire, so the panel runs right there, where your code, prompts, and credentials never detour through anyone else's router. Fusion is a behavior of that proxy. It turns one outbound Claude request into a short committee meeting and returns a single answer in the wire shape the agent expected. Claude Code never learns that GPT-5.5 and Grok were in the room.

One lightning bolt.

Fusion has one control, in the title bar of the agent session window.

Agent session title bar with the Fusion lightning bolt in dark grey, disengaged
disengaged · grey bolt
Agent session title bar with the Fusion lightning bolt lit yellow, engaged
engaged · yellow bolt
The whole UI for Fusion: the ⚡ in the session title bar. On the left it sits disengaged, a filled bolt in dark grey, available this session but off. On the right it lights yellow, engaged. With fewer than two models configured the bolt goes hollow and disabled, since a panel of one is a model. The 192.168.64.2 in the address bar is the per-profile VM the agent runs inside, and that is the wire Fusion sits on.

Fusion runs on the Claude Code session, since it intercepts Claude's /v1/messages API, the request it knows how to fan out and reassemble. You configure two or three agents with credentials in the profile's Agents tab, pick which providers join the panel and which model judges, and from then on you touch only the bolt. Grey means off, plain Claude. Yellow means on, the committee convenes. The bolt is a runtime flag, so you can toggle it mid-session without a restart.

What happens on the wire.

With the bolt yellow, the proxy does more than forward the agent's request to Anthropic. It runs the sequence below.

ON THE WIRE · inside the per-profile VM's MITM proxyCLAUDE CODE (in VM)POST /v1/messages model: claude-opus-4-8 stream: true tools: [bash, edit, …] thinks: one modelLEG A · Claude · asked FIRST, tools intactapi.anthropic.com · non-streaming · the real requestif it's a TEXT turn → fuse · if a TOOL turn → passthroughTHE PANEL · same question, in parallelLeg A · Claudedraft (already in hand)Leg B · GPT-5.5api.openai.comLeg C · Grokapi.x.aiJUDGE · Opus 4.8analyzes the drafts, doesn't voteconsensus · conflictsunique · blind-spotsemits JSON analysis, not proseSYNTHESIZER · Opus 4.8writes ONE answer, groundedin the analysis aboveRE-WRAP · Claude's own id / model / usage envelope, content swapped for the fused textstreamed back as Anthropic SSE or a single JSON body, the shape the agent asked forSESSION TRACE · every leg is a named SubCall: anthropic · openai · x.ai · judge · synth (the agent issued one call)one answer back to the agent
Fusion's path for a turn that talks to you. The proxy asks Claude first, carrying the agent's real request with its tools. On a plain text answer, it puts the same question to the rest of the panel, hands every draft to a judge that returns a structured analysis, and lets a synthesizer write the single final answer from that analysis. The proxy then re-wraps the result in Claude's own message envelope and streams it back in whatever shape the agent asked for. Three models answer, and the agent reads one.

One detail separates this from a demo: the proxy asks Claude first, and asks it in full. Leg A carries the agent's real request, tools and full transcript intact, sent to Anthropic with the real credential. The proxy forces it non-streaming so it can read the whole answer before deciding what to do. The routing decision turns on that first answer.

A coding agent changes the problem.

Fusion inside a coding agent poses a different problem from Fusion inside a chat box, and this is the part I am proudest of.

In a chat product, most turns are prose for a human to read, which is what judge-and-synthesize is built for. In an agentic loop, most turns are actions: call bash with npm test, edit this file. Each one is a tool_use block with structured input the SDK is waiting to run. Fuse three models' opinions into a paragraph there and you have deleted the tool call, and the loop stalls. Fusion checks before it acts. It asks Claude first so it can inspect the turn, then routes on the shape of the answer:

Claude answers firstnon-streaming · tools intactinspect the turnwhat shape?TOOL TURN → passthroughstop_reason: tool_use (or any tool_use block)replay Claude's real response, verbatimno GPT · no judge · no synth · loop intactTEXT TURN → fusestop_reason: end_turn, plain text answerrun the panel · judge · synthesizethe turn that talks to you
The turn router reads Claude's first answer. A tool turn, anything with a tool_use block or a tool_use stop reason, is an action, so Fusion replays Claude's real response verbatim and skips the panel: no GPT call, no judge, no synthesis, no risk of stripping the command. A plain text turn, the kind that talks to you, gets the full committee. The router keeps the agentic loop intact.

Through most of a session Fusion stays quiet. The long stretch of run-tests, read-failure, patch-file is all tool turns, handed straight through at full speed. The committee convenes when Claude explains rather than acts: the architecture question, the final write-up of what it found. A second and third opinion pay off on those turns.

The judge analyzes instead of voting.

The naïve version of "use three models" is a majority vote, or asking a model "which is best?" and forwarding the winner. Both throw away most of the signal. A panel beats one model because the models go wrong in different places, and a vote only counts them.

The judge produces no answer. Given the question and every labelled draft, it returns a structured analysis and nothing else:

{
  "consensus":   [ "points the answers agree on" ],
  "conflicts":   [ { "topic": "...", "positions": "who says what" } ],
  "unique":      [ { "source": "provider name", "insight": "..." } ],
  "blind_spots": [ "things the answers missed or got wrong" ],
  "verdict":     "one sentence on which answer is strongest and why"
}

That JSON is the panel's real output. The synthesizer takes the question and that JSON and writes the final answer: it resolves the conflicts toward correctness, folds in the unique insights, covers the blind spots, and says nothing about the panel. It writes to you as if it had known the answer all along.

Fusion pins both the judge and the synthesizer to Opus by default. The analysis and the write-up are the quality-critical steps, so Fusion runs them on the strong model rather than on whatever the agent requested. You can change the judge in the Fusion pane. We default it to the strong model on purpose.

Fable without Fable.

For a coding agent, the honest demo is a build. We handed the same prompt to a single strong model and to the panel, bolt grey then bolt yellow, and shipped whatever each one produced:

Write a website in node that echoes back the user agent in a beautifully designed WebGL page inspired by Tron, fast and dynamic, that should wow the visitor.

⚡ grey · single model (Opus 4.8)
⚡ yellow · Fusion panel
Same prompt, same agent, one toggle. On the left, the bolt grey: a single model, Opus 4.8. On the right, the bolt yellow: a Claude + GPT-5.5 + Grok panel, judged and synthesized by Opus. Fusion leaves the file edits alone, since those are tool turns passed straight through, and works only the turns where the agent reasons out loud. The panel's page is the one that wows the visitor.

One prompt proves nothing on its own. OpenRouter ran the real measurement: a hundred deep-research tasks, dozens of weighted criteria, a panel landing several points above the best single model, Fable 5 among them. The mechanism is the same, pointed at your own models. A Claude + GPT-5.5 + Grok panel, judged and synthesized by Opus, beats any one of them answering alone on the prose turns of a coding session, Fable included. You get Fable-class output with no Fable in the room.

Models are famous for fumbling simple riddles. The panel catches the obvious mistakes before they reach you.

A Claude Code session with Fusion engaged: it correctly counts three r's in 'strawberry' and gives a measured answer about whether to walk or drive to a car wash 50 meters away
Fusion on the two questions that launched a thousand 'LLMs can't actually reason' threads. The letter-counting gotcha comes back correct, three r's at positions 3, 8, 9, and the walk-or-drive question gets a measured answer in place of a confident wrong one. Three models cross-check each other, so the weak answers do not survive.

It's all in the trace.

This is the part only Bromure can claim, and it comes from where Fusion lives. The agent sits in a VM and every outbound call goes through the host proxy, so Fusion's side calls stay visible even when the agent cannot see them. The host records every leg, the Claude draft, the GPT draft, the Grok draft, the judge pass, the synthesis pass, into the same session trace as everything else the agent did.

ONE FUSED TURN · as recordedleghostrolewireA · Claudeapi.anthropic.comdraft200 · 2.1 KBB · GPT-5.5api.openai.comdraft200 · 1.8 KBC · Grokapi.x.aidraft200 · 1.6 KBjudgeapi.anthropic.comJSON analysis200 · 0.9 KBsynthapi.anthropic.comfinal answer200 · 2.4 KBagent's view: 1 request to Anthropic · trace's view: 5 upstream calls, all attributed
An admin's view of a single fused turn. The agent believes it made one call to Anthropic. The trace records five: a Claude draft, a GPT draft at api.openai.com, a Grok draft at api.x.ai, then a judge pass and a synthesis pass. Fusion stays transparent to the agent and legible to whoever reviews the session, the house style our enterprise posts keep coming back to.

A model-fusing router that hid its side calls would hand an enterprise an unaudited copy of its prompts and code, fanned out to two more vendors with no record. Fusion fans out and writes every call down. Your security team can ask why api.openai.com received a prompt and read the answer off a row in the trace: the bolt was yellow.

The price of Fusion.

Fusion costs you time. A fused text turn runs the panel and then makes two extra calls to Opus, one for the judge's analysis and one for the synthesis. They run in sequence, after Claude's own answer, since the proxy has to read that answer before it decides to fuse. A fused turn is slower than a plain one. The trade is narrow: on the turns that explain things to you, you wait a bit longer for a better answer. That is why Fusion is a bolt you flip rather than a default, and why it touches the prose turns and leaves the tool loop alone.

Flip the bolt.

Bromure Agentic Coding 3.0 puts Fusion in the title bar of every agent session. Configure two or three agents, pick a judge, and the ⚡ moves from hollow to grey, then to yellow when you want the committee. Your coding agent keeps behaving as if it talks to one model, since as far as it can tell, it does. The trace shows the five calls behind each answer.