Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Openrouter Fusion API

openrouter.ai

Post reply on HN
Print view View original

81–90 of 98 posts

Re: Openrouter Fusion API

#81

Post by daheza »

all2 wrote: post #74

I had a prompt I used for this just using Claude Code: Let's review for architectural issues. Spawn 10 agents, create personas for them, have them review the _api.go and write their review to reviews/ -review.md, then have each agent do a round robin response to 3 of the reviews of their choosing (based on the abstract at the beginning of each review) and write the response to response/ - -response.md. Then we do reb…

I'm new to using more than one agent in a flow so forgive my ignorance here but I have a few questions.

Do you review all the files that are generated to ensure there's no hallucinations? Do you just review the last file of concise findings instead?

Is the intent here that the hallucinations will be countered by running through multiple agents that you end up with only the truth? Have you seen anything in the last version that was egregiously wrong?

I was worried about the cost but if you are using local hosted models, then I suppose you don't need to deal with that as much. Locally hosted models still have issues running commands locally and reaching out to the internet right? So this is all just them running with the context of the file, without reference tot he rest of the project?

Thanks for any responses to this.

Re: Openrouter Fusion API

#82

Post by kristjansson »

all2 wrote: post #74

I had a prompt I used for this just using Claude Code: Let's review for architectural issues. Spawn 10 agents, create personas for them, have them review the _api.go and write their review to reviews/ -review.md, then have each agent do a round robin response to 3 of the reviews of their choosing (based on the abstract at the beginning of each review) and write the response to response/ - -response.md. Then we do reb…

Seems like a lot of machinery over-and-above running the same review n times + aggregating the result. What led you to the design?

Re: Openrouter Fusion API

#83

Post by all2 »

kristjansson wrote: post #82
all2 wrote: post #74

I had a prompt I used for this just using Claude Code: Let's review for architectural issues. Spawn 10 agents, create personas for them, have them review the _api.go and write their review to reviews/ -review.md, then have each agent do a round robin response to 3 of the reviews of their choosing (based on the abstract at the beginning of each review) and write the response to response/ - -response.md. Then we do reb…

Seems like a lot of machinery over-and-above running the same review n times + aggregating the result. What led you to the design?

The idea is pretty simple, identity drives focus and outcomes of each of the 'agents'. The review/rebuttal stage filters stuff that likely doesn't matter in the grand scheme (you'll find reviewers get pedantic and take hard lines on things that ultimately don't matter very much).

This is based on earlier work from late '25 where people were doing similar things. My added bit is the 'unique identities'. What I found was that the root agent typically picks identities relevant to the project, and so you get relevant 'data' or 'views' from a variety of angles.

Re: Openrouter Fusion API

#84

Post by all2 »

daheza wrote: post #81
all2 wrote: post #74

I had a prompt I used for this just using Claude Code: Let's review for architectural issues. Spawn 10 agents, create personas for them, have them review the _api.go and write their review to reviews/ -review.md, then have each agent do a round robin response to 3 of the reviews of their choosing (based on the abstract at the beginning of each review) and write the response to response/ - -response.md. Then we do reb…

I'm new to using more than one agent in a flow so forgive my ignorance here but I have a few questions. Do you review all the files that are generated to ensure there's no hallucinations? Do you just review the last file of concise findings instead? Is the intent here that the hallucinations will be countered by running through multiple agents that you end up with only the truth? Have you seen anything in the last ve…

> Do you review all the files that are generated to ensure there's no hallucinations? Do you just review the last file of concise findings instead?

Sometimes, yes. Typically I'll read the final fusion doc, and then trace backwards if there is something that looks relevant. Sometimes I'll read all the abstracts as they come through.

> Is the intent here that the hallucinations will be countered by running through multiple agents that you end up with only the truth? Have you seen anything in the last version that was egregiously wrong?

The intent isn't so much avoiding hallucinations, rather I was attempting to acquire unique, domain specific insight. My read-through of the final doc is a 'pick and choose', where I weed out what isn't relevant, and keep what is. I haven't seen anything way out of whack, as agents will typically check each other and call each other out in the review/rebuttal stage.

> So this is all just them running with the context of the file, without reference tot he rest of the project?

This is run in an agent harness locally, so each reviewer has access to the whole project. The review rebuttal stage rarely sees agents re-read files, though, unless one of them is particularly aggressive and is going deep on something (GPT 5 series will do this to make a point, sometimes).

> Thanks for any responses to this.

No worries. This is pretty easy to try, even with something you don't own. You can run it in any harness that allows spawning sub-agents.

If there's a lot of interest, I could spin up a simple web app that does this just so folks can see it churn on a target git repo or project files or whatever.

Re: Openrouter Fusion API

#86

Post by kgeist »

I wonder if regenerating the same prompt with the same model multiple times at a higher temperature would be equivalent to running different models. I suspect the perceived variance among different frontier models may be largely due to randomness associated with non-zero temperatures.

Models seem to be trained to return nice, round numbers of items, like 5, 10, or 15 (because of interference from training on marketing materials?) Plus, recall is far from 100% on large contexts. So if your code has 27 bugs, each run may find a different set of 10 issues out of the 27, whether you use several models or call the same one repeatedly.

Re: Openrouter Fusion API

#87

Post by rektlessness »

SteveMorin wrote: post #78
maccam912 wrote: post #22

Earlier quoted context omitted.

Same for me! I bet they use opus to synthesize the final answer somehow? Regardless, it was unexpected.

Yes believe opus is the default judge

Perhaps, but shouldn't be at my own cost if not disclosed before hand.

Re: Openrouter Fusion API

#89

Post by chrisss395 »

Is there any formal research in this space? I too have tried flavors of this approach, but I can't confidently say my results were better.

I worry its kind of like asking 2-3 different consultants what the optimal strategy is for your business...and I'm not sure merging the answers produces anything material better.

Re: Openrouter Fusion API

#90

Post by awllau »

andai wrote: post #2

Context: Surpassing Frontier Performance with Fusion https://news.ycombinator.com/item?id=48525392 And a slightly better UI here: https://openrouter.ai/fusion On OpenRouter's fusion API your request is routed to several models simultaneously and a judge model combines their answers into a final response. This significantly boosts performance, at the cost of time (at least on the one benchmark they tested, a deep rese…

One of the things they neglected to discuss was how much longer it takes given the synthesis step. I guess for a deep research benchmark, it doesn't matter much, but will be interesting to see how it applies to coding tasks.
Post reply on HN