GitHub julkaisi perjantaina Project HydraFusionin, tutkimusesikatselun, joka koostaa koodaustehtävän ratkaisun useasta tekoälymallista yhden sijaan. Kehittäjälle se näkyy tavallisena vaihtoehtona mallivalitsimessa. Kulissien takana järjestelmä päättää, montako mallia tehtävään kutsutaan ja mikä rooli kullekin annetaan.
Taustalla on GitHubin aiemmin tänä vuonna julkaisema Auto-mallivalinta, joka sovittaa tehtävän sopivimpaan malliin. HydraFusion menee askelen pidemmälle. Se ei valitse mallia vaan rakentaa koko suoritussuunnitelman.
Kolme suoritustapaa saman valitsimen takana
HydraFusion käsittelee työnkulun valintaa optimointiongelmana. Se lukee mallien kyvykkyyssignaaleja päättelyyn, koodin generointiin, virheenjäljitykseen ja työkalujen käyttöön. Niiden perusteella se valitsee kevyimmän suoritustavan, joka todennäköisesti yltää laatuvaatimukseen.
Vaihtoehtoja on toistaiseksi kolme. Single antaa tehtävän suoraan yhdelle mallille. Cascade aloittaa tehokkaammalla mallilla ja nostaa työn vahvemmalle mallille vasta, jos laatuportti hylkää luonnoksen. Critique puolestaan antaa yhden mallin luonnoksen toisen malliperheen tarkastajalle, jonka jälkeen alkuperäinen malli korjaa työnsä kerran.
Critique-malli jatkaa Copilot CLI:n Rubber Duck -agentin ideaa, jossa erillinen malli katselmoi suunnitelman tai toteutuksen. Tarkastajamallit ajetaan ilman työkaluja, eivätkä ne voi muuttaa koodivarastoa. Varsinaiset ratkaisijamallit säilyttävät yhteisen työtilan ja Copilotin oikeuksia kunnioittavan agenttisilmukan.
Mittaustulokset kolmesta vertailusta
GitHubin blogin mukaan kiinteät HydraFusion-käytännöt ajettiin kolmea agenttikoodauksen vertailua vastaan. Verrokkeina olivat Claude Opus 5 ja GPT-5.6 Sol. Kaikki mallit ajettiin samalla keskitason päättelyasetuksella, samoilla syötteillä, työkaluilla ja hinnoitteluoletuksilla.
TerminalBench 2.1 -testissä HydraFusion ylitti Opus 5:n laadussa 4,9 prosenttiyksiköllä ja maksoi arviolta 67 prosenttia vähemmän. DeepSWE-testissä se jäi 1,5 pistettä Opus 5:n taakse 36 prosenttia halvemmalla. CheckpointBenchissä, joka rakentuu oikeista anonymisoiduista Copilot-istunnoista, ero oli 0,1 pistettä ja säästö 65 prosenttia.
Kustannuslaskenta kattoi jokaisen kutsutun osan: luonnostelun, katselmoinnin, korjauksen, nostot vahvemmalle mallille sekä uudelleenyritykset. GitHub korostaa, että tulokset pätevät juuri testattuihin vertailuversioihin, työnkulkuasetuksiin ja mallivalikoimaan. Esikatselun tarkoitus on selvittää, siirtyvätkö luvut oikeisiin kehitystyökuormiin.
Laskutus kulkee jokaisen mallikutsun mukana
Kehittäjä maksaa edelleen käytetystä päättelystä. Laskutus lasketaan kaikista tokeneista, jotka työnkulun mallit kuluttavat, kunkin mallin tavallisella Copilot-hinnalla. Yksi kehotus voi siis tuottaa useita laskutettavia mallikutsuja.
Tämä asettaa reititykselle selkeän vaatimuksen. Sen on säästettävä kallista päättelyä tarpeeksi kattaakseen katselmointien ja korjauskierrosten oman kulun. Juuri siksi järjestelmä pyrkii valitsemaan yksinkertaisimman riittävän työnkulun eikä lisää kutsuja ilman odotettua hyötyä.
Turvarajat on vedetty muutoksiin. Jos työnkulku perutaan tai se ei läpäise validointia, HydraFusion ei tee koodimuutosta lainkaan. Ajonaikainen järjestelmä kirjaa jokaisesta osasta roolin, lopputuloksen, kustannuksen, viiveen ja diagnostiikan, mutta esittää kehittäjälle yhden vastauksen ja yhden muutosehdotuksen.
Käyttöönotto ja tunnetut rajat
Esikatselu on avoinna kaikilla Copilot-tilaustasoilla Copilot CLI:n kokeellisten ominaisuuksien kautta. Käyttöönotto vaatii kolme komentoa: päivityksen, kokeellisten ominaisuuksien kytkemisen päälle ja HydraFusionin valinnan mallivalitsimesta.
GitHub suosittelee aloittamaan laajahkoista, hyvin rajatuista tehtävistä, jotka voi antaa yhdellä kehotuksella. Monivuoroiset ja pitkät istunnot ovat vasta seuraava kehityskohde. Nykyisessä muodossaan järjestelmä on siis viritetty ensimmäisen vuoron työhön.
Yhtiö sanoo suoraan, että tulokset, mallit, työnkulut, saatavuus ja jopa nimi voivat vielä muuttua. Mallivalikoima on laajennettavissa, joten uudet mallit voidaan ottaa mukaan ja ohjata niille tehtäviin, joissa ne pärjäävät parhaiten. Kehittäjän ei tarvitse arvioida kutakin uutta mallia erikseen.
Yhteenveto
HydraFusion siirtää koodausagenttien kilpailun mallin valinnasta ajonaikaiseen orkestrointiin. Kolmessa vertailussa se ylsi käytännössä Opus 5:n tasolle selvästi pienemmillä kustannuksilla, joskin vain yhdessä kolmesta se myös voitti verrokin laadussa.
Kehittäjälle muutos on aluksi pieni: yksi uusi rivi mallivalitsimessa. Merkittävä valinta siirtyy kuitenkin kehotuksen lähettämishetken jälkeen reitittimelle. Esikatselun tulokset ratkaisevat, kestääkö lupaus myös oikeassa työssä.