GitHub avasi 4. syyskuuta Project HydraFusionin tutkimusesikatseluna GitHub Copilotissa. Työkalu ei ohjaa kehotetta yhdelle valitulle mallille, vaan rakentaa jokaiselle pyynnölle oman ajosuunnitelman. Suunnitelma voi käyttää useaa mallia eri toimittajilta saman tehtävän aikana.
Kehittäjän näkökulmasta muutos on pieni. HydraFusion näkyy mallivalitsimessa kuten mikä tahansa muu malli. Kaikki päätökset mallien määrästä ja niiden rooleista tehdään vasta sen jälkeen, kun kehote on lähetetty. GitHubin mukaan monimutkaisuus jää kulisseihin, ja kehittäjä keskittyy itse tehtävään.
Ratkaisu jatkaa Auto-mallivalinnan linjaa, jonka GitHub julkaisi aiemmin tänä vuonna. Auto arvioi tehtävän ja valitsi sille sopivimman mallin kerran, tehtävän alussa. HydraFusion rakentaa pidemmän suunnitelman ja voi vaihtaa suuntaa kesken tehtävän.
Kolme suoritusmallia yhden valinnan takana
HydraFusion valitsee kullekin pyynnölle yhden kolmesta suoritusmallista. Single ohjaa tehtävän suoraan yhdelle mallille. Cascade antaa tehokkaan mallin laatia luonnoksen, minkä jälkeen laatuportti päättää, hyväksytäänkö tulos vai nostetaanko tehtävä vahvemmalle mallille.
Critique-kuvio tuo mukaan toisen malliperheen. Yksi malli kirjoittaa luonnoksen, toisen perheen lukuoikeudellinen tarkastaja arvioi sen, ja alkuperäinen malli korjaa työnsä kerran. Tarkastajamalli ei saa käyttöönsä työkaluja eikä voi muuttaa koodivarastoa. Ratkaisumallit sen sijaan säilyttävät jaetun työtilan ja Copilotin oikeustietoisen agenttisilmukan.
Kuvio ei ole täysin uusi. Se noudattaa samaa katselmointitapaa kuin Copilot CLI:n aiempi rubber duck -agentti, jossa erillinen malli tarkastaa suunnitelman, toteutuksen tai testausstrategian. HydraFusion tekee tuosta toisesta mielipiteestä yhden vaihtoehdon reitittimen sisällä, joka punnitsee myös kustannusta ja tehtävän vaikeutta.
Valinta tehdään kyvykkyyssignaalien perusteella. HydraFusion arvioi päättelyn, koodin generoinnin, virheenjäljityksen ja työkalujen käytön ja valitsee kevyimmän työnkulun, joka todennäköisesti riittää laatutavoitteeseen. Lisäkutsuja tehdään vain silloin, kun ne parantavat tulosta todennäköisesti.
Vertailu Opus 5:tä vastaan kolmella testillä
GitHub ajoi kiinteitä HydraFusion-käytäntöjä kolmea agenttikoodauksen vertailutestiä vastaan. Verrokkeina olivat Claude Opus 5 ja GPT-5.6 Sol. Kaikki mallit ajettiin samalla keskitasoisella päättelyasetuksella, samoilla syötteillä, työkaluilla ja suoritusrajoilla.
TerminalBench 2.1 -testissä HydraFusion nosti varmennetun tehtävälaadun 4,9 prosenttiyksikköä Opus 5:n yli, ja arvioitu kustannus jäi 67 prosenttia matalammaksi. DeepSWE-testissä tulos jäi 1,5 pistettä Opus 5:stä, mutta kustannus laski 36 prosenttia.
DeepSWE on kolmikosta vaativin. Se tuo eteen koodivarastotason tehtäviä, jotka edellyttävät laajassa koodipohjassa liikkumista ja tiedostojen välisten riippuvuuksien seuraamista. Juuri siinä reitittimen on vaikeinta arvata etukäteen, riittääkö halvempi malli.
CheckpointBench on GitHubin oma vertailu, joka on rakennettu anonymisoiduista Copilot-istunnoista ja ankkuroitu julkisiin commiteihin. Siinä ero Opus 5:een oli 0,1 pistettä ja kustannus 65 prosenttia matalampi. Vertailu on siis lähempänä todellista käyttöä kuin synteettinen testijoukko.
Laskutus kattaa jokaisen kutsutun mallin
Käyttäjä maksaa edelleen taustalla kuluvasta päättelystä. GitHubin mukaan HydraFusionin käyttö lasketaan kaikista työnkulun mallien kuluttamista tokeneista, kunkin mallin tavallisella Copilot-hinnalla. Reititin ei siis ole alennus vaan tapa kohdentaa kulut tarkemmin.
Yksi kehote voi synnyttää useita laskutettavia mallikutsuja. Kritiikkikierros tai nosto vahvemmalle mallille lisää kutsuja, joten reitityskerroksen on säästettävä kalliissa päättelyssä enemmän kuin se kuluttaa lisäkierroksiin. Väärin arvioitu tehtävä maksaa siis kahdesti.
GitHub kertoo neljästä suunnitteluperiaatteesta: täysi kustannuslaskenta, rajattu suoritus, eristetty tarkastusvaihe ja turvallinen muutosten soveltaminen. Jos työnkulku perutaan tai se ei läpäise validointia, muutosta ei sovelleta lainkaan. Puolivalmista korjausta ei siis päädy koodivarastoon.
Ajonaikainen tieto kirjataan jokaisesta osasta erikseen. Rooli, lopputulos, kustannus, viive ja diagnostiikka tallennetaan, vaikka kehittäjälle näytetään vain yksi vastaus ja yksi muutosehdotus. Läpinäkyvyys on esikatselussa olennaista, koska ilman sitä reitittimen päätöksiä on mahdotonta arvioida.
Reitittimestä tulee strateginen kerros
Etu ei koske vain kehittäjää. Toimiva reititin antaa GitHubille mahdollisuuden varata kalliit huippumallit niihin kehotteisiin, jotka niitä oikeasti tarvitsevat, ja siirtää rutiinityö halvemmille malleille. Sama liike keventää katetta syöviä päättelykustannuksia.
Malliluettelo on laajennettavissa. Kun Copilotiin tulee uusia malleja, GitHub voi arvioida ne ja liittää ne HydraFusionin valikoimaan ilman että kehittäjän tarvitsee muuttaa työtapaansa. Uusi malli ohjataan niihin tehtäviin, joissa se on hyvä, sen sijaan että se kilpailisi kaikessa.
Copilot on avannut ovensa usealle mallitoimittajalle vuodesta 2024 alkaen. Jokainen lisäys on kuitenkin siirtänyt saman päätöksen kehittäjälle: valitse oikea työkalu ja kanna väärän arvauksen kustannus. HydraFusion kääntää asetelman toisin päin.
Mallivalitsin pysyy näkyvissä, mutta merkityksellinen valinta siirtyy sen taakse. Kilpailu siirtyy yksittäisen huippumallin valinnasta reitittimeen, joka jakaa tehtävät, päättelybudjetin ja toimittajaliikenteen.
Yhteenveto
GitHub korostaa, että tulokset ovat offline-ajoja tietyillä vertailuversioilla ja hinnoitteluoletuksilla. Kustannuslaskenta sisälsi jokaisen kutsutun osan: luonnoksen, kritiikin, korjauksen, nostot, uudelleenyritykset ja varajärjestelyt. Yhtiö sanoo esikatselun tarkoituksen olevan juuri se, että näiden lukujen siirtyminen oikeisiin työkuormiin todennetaan.
HydraFusion on saatavilla kaikilla GitHub Copilot -tilauksilla Copilot CLI:n experimental-valikon kautta, ja käyttöönotto vaatii kolme komentoa. GitHub suosittelee aloittamaan laajoista ja hyvin rajatuista ensimmäisen kierroksen tehtävistä. Monikierroksinen käyttö pidemmissä istunnoissa on vasta työn alla.
GitHubin blogin mukaan seuraava todellinen edistysaskel koodausagenteissa ei tule isommasta mallista vaan älykkäämmistä ajonaikaisista päätöksistä. Tutkimusesikatselu on tapa selvittää, pitääkö väite kutsua myös oikeissa työkuormissa.