Valget af AI-model kan være på vej til at flytte fra brugeren og ind i selve arbejdsprocessen. GitHub tester nu Project HydraFusion, som kan sammensætte flere modeller omkring én kodeopgave i stedet for blot at sende hele opgaven til den model, udvikleren har valgt.

Det er et lille preview med en større idé: Den dyreste og kraftigste model behøver måske ikke udføre alle trin. En lettere model kan begynde, mens en anden vurderer resultatet, eller en stærkere model overtager, hvis første forsøg ikke holder. Dermed bliver orkestreringen mellem modeller lige så vigtig som navnet på den enkelte model.

Tre veje gennem samme opgave

HydraFusion kan vælge mellem tre grundforløb. I det enkleste løser én model opgaven direkte. I et eskaleringsforløb laver en billigere model første udkast, hvorefter en kvalitetskontrol afgør, om en stærkere model skal tage over. I den tredje variant undersøger en separat model udkastet uden adgang til at ændre projektet, før den oprindelige model får én mulighed for at revidere.

Det adskiller sig fra Copilots eksisterende automatiske modelvalg. Her analyserer en mindre router brugerens hensigt og vælger én passende model ved en naturlig grænse i samtalen. GitHubs dokumentation anbefaler den løsning som en måde at reservere dyr ræsonnementskraft til svære opgaver og undgå unødige modelskift, der kan ødelægge genbrug af tidligere beregnet kontekst.

HydraFusion går et skridt videre ved at vælge et helt forløb under opgaven. Brugeren ser et samlet resultat, mens udkast, kritik og eventuel eskalering foregår bagved. GitHub oplyser, at systemet registrerer forbrug og udfald for hvert trin, har tidsgrænser og ikke bør lægge en delvist valideret ændring ind i kodebasen, hvis processen afbrydes.

Prisbesparelsen afhænger af at vælge rigtigt

I GitHubs offline-test kostede HydraFusion-forløbet 67 procent mindre end Claude Opus 5 på TerminalBench 2.1, samtidig med at andelen af verificerede løsninger lå 4,9 procentpoint højere. På DeepSWE var den beregnede besparelse 36 procent, mens kvaliteten lå 1,5 procentpoint lavere. På GitHubs eget CheckpointBench var forskellen i kvalitet 0,1 procentpoint og den anslåede pris 65 procent lavere.

Tallene peger på, hvorfor sammensatte systemer er interessante: Hvis en billig model ofte kan løse første del, kan den dyre model gemmes til de tilfælde, hvor den faktisk gør en forskel. Men gevinsten forsvinder hurtigt, hvis routeren vælger forkert, hvis flere gennemløb øger ventetiden, eller hvis kvalitetskontrollen overser en fejl.

Et preview med snæver indgang

HydraFusion er tilgængelig på alle Copilot-planer, men kun som eksperiment i Copilot CLI. Brugeren skal opdatere kommandolinjeværktøjet, slå eksperimentelle funktioner til og vælge HydraFusion i modelmenuen. Forbruget afregnes efter de modeller, systemet faktisk kalder, så et komplekst forløb kan bestå af flere betalbare trin.

GitHub anbefaler foreløbig afgrænsede kodeopgaver, der kan beskrives i én første besked. Lange samtaler med mange rettelser er endnu ikke previewets stærkeste område. Det gør lanceringen mere til en prøve af en ny arkitektur end til en færdig erstatning for almindeligt modelvalg.

Modelnavnet kan blive mindre vigtigt

Hvis modellen bag en kodeagent kan skifte rolle fra opgave til opgave, bliver brugerens valg i højere grad et valg af metode. Man vælger ikke nødvendigvis en bestemt motor, men et system, der beslutter, hvornår hastighed, kritik eller ekstra regnekraft er vigtigst.

Det kan også gøre sammenligning vanskeligere. Kvalitet og pris kommer ikke længere fra ét modelkald, men fra en kæde af beslutninger, modeller og kontroller. GitHubs preview gør netop den afvejning synlig: Flere modeller er ikke automatisk bedre, men de kan være billigere end at bruge den stærkeste model overalt, hvis orkestreringen er præcis nok.



Der er benyttet AI til at skrive denne artikel.