HydraFusion slår Opus 5 med 4,9 poeng på TerminalBench til 67 prosent lavere kostnad

67 prosent lavere estimert kostnad og 4,9 prosentpoeng høyere verifisert oppgavekvalitet enn Claude Opus 5. Det er tallet GitHub la fram 4. september, da Project HydraFusion ble sluppet som research preview i GitHub Copilot. Du velger HydraFusion som en hvilken som helst annen modell i modellvelgeren, og kjøretiden bestemmer resten.

Under panseret behandler HydraFusion valg av arbeidsflyt som et optimeringsproblem. Kapabilitetssignaler for resonnement, kodegenerering, feilsøking og verktøybruk avgjør hvilket av tre utførelsesmønstre som tas i bruk: single, der én modell løser oppgaven direkte, cascade, der en effektiv modell får første forsøk og en sterkere modell overtar hvis kandidaten ikke passerer akseptporten, og critique, der en uavhengig modell vurderer arbeidet før revisjon. Terskelverdiene er ikke satt for hånd. GitHub brukte beam search til å bygge beslutningspolicyen og målte hver kandidat mot en frossen baseline på kvalitet, kostnad og feilmodus.

Tallene er ikke like flatterende overalt, og GitHub publiserer begge sider av regnestykket.

«Så langt er resonnement og oppgaveløsning på nivå med eller bedre enn Opus.» — Principal Software Engineer i Microsoft, sitert anonymt i GitHubs innlegg

Forbeholdene er verdt å lese. Dette er kontrollerte offline-evalueringer, bundet til bestemte benchmark-revisjoner, en gitt modellpool og egne prisantakelser, med alle modeller kjørt på medium tenkenivå. GitHub skriver selv at TerminalBench 2.1 er relativt mettet, og at to driftsfeil mellom 11. og 25. august ga ugyldige kjøringer som ble ekskludert fra trenden. CheckpointBench er GitHubs interne sett, kuratert fra ekte Copilot-økter og låst til offentlige repoer på bestemte commits.

Mønsteret er kjent for alle som allerede lar én modell skrive og en annen vurdere. Det nye er at akseptporten flyttes inn i kjøretiden, slik at du får ett sammenhengende svar og ett endringssett i stedet for å orkestrere modellene manuelt.

Hva bør du gjøre?

1. Start med store, godt avgrensede oppgaver i én prompt. Forhåndsvisningen er tunet for første tur, ikke lange iterative økter.
2. Regn din egen kostnad, ikke GitHubs. Tallene er estimater fra offline-kjøringer med leverandørens egne prisantakelser.
3. Mål latensen i dine egne økter. Kritikk- og eskaleringsledd legger til modellkall, og GitHub oppgir latens som noe de skal optimere videre i forhåndsvisningen.