Project HydraFusion: Frontier quality via multi-model orchestration
github.blog
github.blog
Multiple model vendors is key here, the cascade pattern doesn't need it, but the critique pattern does.
Last Nov, my team wrote a paper ("Team of Rivals") on the difference between using an OpenAI model to Critique an Anthropic model's output vs running a self-review agent loop on the same vendor.
The ablations [1] proved that neither company alone was better than using both.
The paper was a general response to "What does your company do that Anthropic can't?" but more so a demonstration of how to make something 90%+ good with models which eval at 60% or so (& Gas Town post unblocked our "this is a trade secret" argument about the paper).
Different inputs are one point, but there is another problem: lack of diversity
Models from the same maker, share the same training and the same implicit bias. It is like if both reviewers had the same gender, race, and studied at the same university, and just got different book day before. Add fresh immigrant from rural asia, you get VERY different opinions, even with the same input book...
Plus practical aspects, Opus 5 is sometimes way too creative which is good for writting. GPT Sol is complete oposite, it is obsessed with crossing every T and verifying every dot. It complements Opus as reviewer!
If opus gets security sensitive questions, gets downgraded to sonnet and againdown to haiku, the same model will hit the same security block, and will not catch the issue. Model from another lab will very likely catch this.
Plus anthropic models love to smell their own farts, load bearing seems are fantastic...
I do notice that there is no mention of effort levels in the comparisons. 5.6 Luna Max is really good and really cheap. A 5.6 Sol high orchestrator with 5.6 Luna max is cheap, has frontier level performance, and is faster than Sol alone. This can be accomplished with simple agent instructions. Looking forward to running my own benchmarks on HydraFusion to see how it fares. Gone are the days of a single model doing all of the work it seems, unless the work requires no tool calls.
This is also a reason why comparing "naked models" for which weights are available and frontier where providers can do whatever they want behind the scenes is unfair.
Specifically, all it took to boost Qwen3.8-27B to get 10% more points on SWEbench Pro and Terminal Bench 2.0 with a proxy that has just these basics: - tweaks few decode settings like slightly higher temperature - detects when model gets stuck and tells it to "go on" - detects responses cut in the middle, empty responses that contain only reasoning, formats not passing verification etc and tells the model to "try better"
And that is it. 10% more. I admit on a subset of tasks, but results are results, even on a subset.
It's a lot of information to ingest, but it gives me some idea of which part of the system is doing which part of the work, how well different harnesses and models interoperate, and more insight into the part of the equation under my direct control as a software developer.
Currently if my hypothesis about frontier labs doing creative tricks between the model and the client is true (and the results seem to favour it so far) the benchmarks are giving us an artificially lowered results for open weights models.
I have yet to test opus/sonet via my proxy. If Qwen gets 10% better and Opus stays the same that suggests one if two things: - either opus doesn't need it - or it's already done behind the scenes.
I think the benchmarks should be trying to use realistic harnesses for both proprietary and open weight models.
Do you have a link/paper for this you could share?
In fact that is how I got the idea. There is a 4 month old post on SWEbench github that claimed 20 point boost (beating opus as well) for another small Qwen model when it's traffic was sent via a similar proxy and claude code was used as the harness.
The author didn't post their full code, but he did post all sorts of logs showing which features of his proxy were activated during which run.
I wanted to exclude the harness and validate his claims regarding only the proxy's impact so I reimplemplemented a subset of his features that seemed to give me the biggest "wins" with the smallest amount of work. These are the ones I list in the parent.
It took one afternoon last week plus the runs that took few days.
I saw about 10% better results.
As I mentioned, it is a subset of tasks, not the entire set, but results so far are very encouraging.
Since then I implemented many more features in the proxy (best of N for example), but i haven't had time to measure the impact yet. His proxy also had best of N, but that feature wasn't activated in on the runs he reports.
It's so effective and helps catching so many design flaws, implementations misses etc ... that i'm wondering how people manage to build complex/large projects with agents without this kind of process. Well, i actually built this thing because i couldn't get good results so i had to find a way.
I'm gonna open source the whole thing but it needs some cleanup, there's a basic landing page here https://kodfactory.com if anyone wants to be notified when it's released on github. Yeah i know, the world really needs another software factory :-)
> Hydra (sometimes stylized as HYDRA) is a fictional terrorist organization appearing in American comic books published by Marvel Comics.[…] Hydra is taken over and turned into a neo-fascist international crime syndicate by Baron Wolfgang von Strucker.
HyDRA: Hybrid Dynamic Routing Architecture for Heterogeneous LLM Pools : https://arxiv.org/pdf/2605.17106
But could be your thing too obviously.
Oh well, can't wait to be harassed by management to try and use it anyways...
It is explicitly not a foreman, task routing, or an orchestrator agent. It has a bias toward direct action and is instructed to only delegate when necessary.
I've found that this approach yields significantly faster results, without much of a quality trade-off, than an agent whose primary impulse is to delegate.
In contrast, HydraFusion starts with a task routing step, then sequential planning, execution, and review stages. My guess is that this workflow is best for people who are prioritizing cost over speed for the same level of quality.
> In controlled offline evaluations, HydraFusion’s selective coding workflows matched or exceeded the evaluated Opus 5 baseline
Opus 5 (in practice) is not a good baseline to compare against.
I'm shocked that they chose to primarily compare against Opus 5 in all the article's charts. It's pretty disingenuous that they're claiming "frontier" quality, but didn't compare against Fable or Sol.