GitHub gjorde onsdag den 28. oktober Copilot Fusion generelt tilgængelig på sin udviklerkonference Universe. I stedet for at din udvikler vælger en model til hver opgave, vælger udvikleren nu et niveau af effort, og Copilot afgør selv, hvilke modeller der skal løse opgaven, og hvordan de arbejder sammen. Uafhængige målinger fra Artificial Analysis viser, at den øverste indstilling rammer næsten samme kodekvalitet som Claude Code med Opus 5.5 til cirka halvdelen af prisen pr. opgave. Regningen er bare ikke så enkel som den overskrift.
Vi har læst GitHubs changelog og dokumentation, de uafhængige tal refereret af VentureBeat og dækningen i The New Stack. Herunder skiller vi GitHubs egne påstande fra de uafhængige målinger, forklarer hvordan orkestreringen fungerer i praksis, og viser hvor både pengene og kontrollen kan løbe fra jer, hvis I slår Fusion til uden en politik først.
Copilot Fusion er et lag, der vælger og koordinerer modeller for dig, mens opgaven kører. Når du vælger Fusion i modelvælgeren, vælger du ikke en bestemt model, men et system, der router og orkestrerer flere modeller for hver prompt. Ifølge GitHubs annoncering af Copilot Fusion har selskabet bygget det oven på to tidligere dele: orkestreringen fra forskningsprojektet HydraFusion og den automatiske modelvalgsfunktion, Copilot allerede havde. HydraFusion kom som research preview i september, så det her er den brede udgave af en funktion, GitHub har testet i et par måneder.
GitHubs produktchef Mario Rodriguez er tydelig om, hvad det ikke er. Det er ikke en model, men en orkestreringsmotor, der kører i realtid, sagde han til VentureBeat. Det er en vigtig skelnen, fordi Fusion ikke selv ræsonnerer. Den vurderer opgaven og sender den videre til de modeller, den mener er bedst, inden for de grænser din organisation har sat. Du kan stadig se, hvad der skete: holder du musen over effort-niveauet under et svar, viser Copilot hvilke modeller, der blev brugt.
Fusion er en del af en bredere bevægelse mod orkestrering som standardlag. Mistral lancerede tidligere på året et orkestreringslag til enterprise-AI, og ifølge The New Stack har både Ramp og Replit gjort intelligent modelrouting til standard i deres egne værktøjer i løbet af 2026. Pointen er den samme overalt: udvikleren skal bruge mindre tid på at vælge model og mere tid på resultatet.
Du styrer Fusion med tre niveauer af effort. Fusion Standard balancerer pris, kvalitet og hastighed og bruger typisk én model til hver opgave. Fusion High er til større, velafgrænsede opgaver som en kompleks fejl eller en ændring på tværs af flere filer, hvor ekstra modelkald kan være tiden og forbruget værd. Fusion Max er til de opgaver, der kræver den dybeste analyse. Et fjerde niveau, Fusion Fast, kan du ikke selv vælge. Det bruges kun i inline-chat i Visual Studio Code.
Under motorhjelmen vælger Fusion mellem tre mønstre for, hvordan modellerne arbejder sammen. I det enkle mønster løser én model opgaven direkte. I kaskade-mønsteret laver en effektiv model et udkast, og en dommermodel afgør, om udkastet godkendes eller sendes videre til en stærkere model. I kritik-mønsteret laver én model et udkast, flere modeller kritiserer det uafhængigt og parallelt, og den oprindelige model retter sit svar ud fra den samlede feedback. Kaskade og kritik tager længere tid, fordi de indeholder ekstra modelkald til review. Det er dér, de kan koste mere end et simpelt svar. GitHubs dokumentation beskriver mønstrene i detaljer.
To ting er værd at huske om, hvordan Fusion arbejder. Den har ikke sit eget kontekstvindue, men kører inden for grænserne for den model, der løser hvert trin, og viser et forsigtigt tal baseret på den mindste af de modeller, den bruger. Og den kan køre lokale modeller i Standard, i øjeblikket Microsofts MAI Code 1.1 Flash på Windows og Qwen3.8 Flash Next via Ollama, begge i offentlig preview. Hvis du vil forstå, hvad de forskellige niveauer af effort reelt køber, har vi tidligere målt hvad mere effort giver i Claude Opus 4.8.
Her er det afgørende at holde to slags tal adskilt. Artificial Analysis testede Fusion på Max gennem Copilot CLI og offentliggjorde resultaterne på lanceringsdagen. På deres Coding Agent Index, der vægter tre kodetests lige, scorede Fusion Max 60 point. Claude Code med Opus 5.5 Max lå omkring 62, og Devin Fusion ramte 62. Fusion endte altså to point bag den bedste. Det interessante er prisen: ifølge Artificial Analysis kostede Fusion i gennemsnit 5,59 dollar pr. opgave mod 11,42 dollar for Claude Code med Opus 5.5. Det er omkring 51 procent lavere, og Fusion brugte cirka 7,2 millioner tokens pr. opgave. Tallene er refereret af VentureBeat.
Den samlede score skjuler dog, at Fusion ikke er bedst til alt. På Terminal-Bench 4.0 førte den med 71. På FrontierCode, der måler ændringer i rigtige kodebaser, scorede Fusion 51 mod 56 for Claude Code med Opus 5.5 og 54 for Devin Fusion. På den test ligger Fusion altså bagest af de tre. Artificial Analysis identificerede desuden, at Fusions modelpulje trak på Claude Opus 5.5, Claude Sonnet 5.5, GPT-6 Astra og GPT-6 Sol, og at de konkrete modeller varierer fra kald til kald og med de politikker, din organisation sætter. Vi så det samme indeks i spil, da vi gennemgik Googles Gemini 4 Carbon, hvor Claude Code med Opus 5.5 også lå øverst med 62.
GitHubs egne tal peger samme vej, men hviler på selskabets egne målinger. GitHub skriver, at Fusion Max nåede sit resultat på cirka halvdelen af omkostningen pr. opgave, med cirka halvt så mange tokens og på cirka 40 procent kortere tid. Vær opmærksom på det sidste tal. VentureBeat bemærker, at Artificial Analysis ikke offentliggjorde data om tidsforbrug, så de 40 procent står alene på GitHubs egen måling. Et endnu større tal, en besparelse på op til 77 procent, stammer fra GitHubs egne tests på DeepSWE-benchmarken og er blevet fremhævet af Microsofts topchef. Det er ikke de uafhængige 51 procent, og de to tal bør ikke blandes sammen.
Hvis I plejer at vælge model efter en sammenligningstabel, er pointen her, at Fusion flytter valget fra en fast tabel til et system, der vælger per opgave. Det kan være en fordel, men det gør det sværere at forudsige både kvalitet og pris. Vi har tidligere skrevet om, hvordan man vælger den rette model manuelt, og den øvelse forsvinder ikke, den flytter bare ind i en politik.
Prismodellen er enkel på papiret og farlig i praksis.
Du betaler for hver model, Fusion bruger, til modellens almindelige takst, og der er ikke noget separat gebyr for Fusion i sig selv. Frem til den 30. november 2026 giver GitHub 30 procent rabat på modelomkostningerne for brugere på betalte Copilot-planer, der kører Fusion. Rabatten er en god anledning til at måle forbruget, men den udløber.
Fælden ligger i, at Fusion High og Fusion Max kan bruge mere end én model til en opgave. Hver gang kaskade- eller kritik-mønsteret træder i kraft, kommer der ekstra modelkald til review, og en enkelt opgave kan derfor koste flere credits end i Standard. Benchmark-prisen på 5,59 dollar pr. opgave er heller ikke det samme som jeres regning, fordi den afhænger af jeres opgavetyper, hvor meget der kan caches, og hvilke modeller jeres politik tillader.
Det er den samme logik, vi beskrev, da OpenAI sænkede prisen 80 procent, uden at regningen faldt 80 procent. Hvis du vil forstå, hvordan forbruget hænger sammen med værdien, er tokenøkonomi det rigtige sted at starte.
For en dansk virksomhed er det her den vigtigste del. Fusion vælger kun mellem de modeller, din organisation har slået til. Enterprise-administratorer kan se præcis, hvilke modeller Fusion kan vælge fra, sætte hver models politik hver for sig og slå enkelte modeller fra for Fusion uden at fjerne dem for resten af udviklerteamet. De kan også bestemme, om Fusion skal være standardmodellen. Fusion udelader automatisk modeller, der ikke er i jeres plan, modeller udelukket af administratorpolitik og modeller, der er spærret af krav til dataresidens eller FedRAMP.
Det sidste er afgørende, hvis I har kode, der ikke må forlade bestemte regioner. Fordi Fusion router per opgave, kan den samme kodebase i princippet blive sendt til flere forskellige modeludbydere i løbet af en arbejdsdag. Derfor hører en Fusion-politik sammen med en beslutning om, hvilke udbydere og regioner I accepterer, og den beslutning skal ligge, før I gør Fusion til standard. The New Stack noterer, at GitHubs dækning af governance ikke rækker ud over, hvilke modeller admins kan vælge fra. Deres gennemgang siger intet om audit, databehandling eller sikkerhed omkring selve orkestreringen, så det skal I selv få på plads.
GitHub nævner selv et par ting, der er lette at overse. Fusion starter ikke subagenter og arbejder uafhængigt af dem. Hvis Fusion kasserer et udkast undervejs, bliver de ændringer, udkastet allerede nåede at lave i dit workspace, som filredigeringer, ikke fortrudt automatisk. Du skal med andre ord gennemgå ændringerne, før du committer, præcis som når en menneskelig kollega efterlader et halvfærdigt stykke arbejde. Endelig kan både mønstrene og modelpuljen ændre sig over tid, så den opgave, der i dag løses af én model, i morgen kan gå gennem tre. Det er grunden til at logge forbruget løbende frem for at måle det én gang og antage, det holder.
Fusion er tilgængelig på alle Copilot-planer i Visual Studio Code, Copilot-appen, Copilot CLI og JetBrains-værktøjerne, og flere klienter er på vej. Det betyder, at jeres udviklere kan slå det til med det samme. Det er netop derfor, rækkefølgen er vigtig: sæt rammerne, før funktionen bliver standard. En AT&T-ingeniør, Hari Pokhrel, beskriver i en udtalelse til GitHub, at udviklere ofte valgte en kraftig model til en svær opgave og glemte at skifte tilbage til hverdagsarbejdet. Det er lige præcis det spild, Fusion kan fjerne, men kun hvis forbruget er under kontrol.
Det kan I gøre nu:
Hvis I allerede arbejder med agentbaseret kodning, passer Fusion ind som et lag oven på det, I har. Hvis I ikke gør endnu, er det et godt sted at mærke, hvad det koster at lade en sprogmodel træffe flere af valgene selv.
Orkestrering er ved at blive det lag, de fleste kodeværktøjer samler sig om, og Copilot Fusion er GitHubs bud. For jer flytter det spørgsmålet fra hvilken model, I skal vælge, til hvilken politik og hvilket budget, I vil give systemet at vælge indenfor. Den gode nyhed er, at valget af model holder op med at være en daglig irritation. Den mindre gode er, at ansvaret for pris og datakontrol ikke forsvinder, det flytter bare fra den enkelte udvikler op til dem, der sætter rammerne.