Innhold Vis
Meta Muse Code er bygget for problemet som dukker opp når en kodeagent skal gjøre mer enn å fikse én funksjon: Hvordan holder den retningen gjennom en stor jobb uten å miste kontekst, gjenta research eller velte når noe krasjer? Metas svar er en terminalagent med vedvarende bakgrunnsagenter, lokal hendelseslogg og en modell som er trent sammen med selve agentmiljøet.
Hvis du arbeider i en stor kodebase, er dette en mer interessant nyhet enn enda en modell som kan fullføre kode. Muse Code skal planlegge endringer, skrive kode og kontrollere resultatet på tvers av store repoer. Meta prøver altså ikke bare å konkurrere med en ny motor. Selskapet bygger hele bilen rundt den.
Det er også her skepsisen bør begynne. Muse Code er i beta, og de mest imponerende resultatene kommer fra Meta selv. Men arkitekturen angriper ekte problemer i dagens kodeagenter. Det gjør lanseringen verdt å se nærmere på, selv før uavhengige utviklere har fått kjørt den gjennom gamle avhengigheter, skjøre tester og den ene mappen ingen tør å åpne.
Hva er Meta Muse Code?
Meta Muse Code er en terminalbasert AI-agent for komplekse utvikleroppgaver i store kodebaser. Den ble lansert i beta 5. august 2026 og drives av Muse Spark 1.2. Ifølge Metas tekniske lansering kan agenten planlegge endringer, skrive kode, bruke flere underagenter og validere resultatet.
Dette plasserer Muse Code i samme verktøykategori som Claude Code og Codex. Du jobber fra terminalen, gir agenten et mål og lar den lese filer, kjøre verktøy og endre prosjektet. Forskjellen Meta vil framheve, er hvordan agenten håndterer lange og sammensatte oppgaver. Den skal ikke bare svare på neste prompt, men holde et arbeid i gang over tid.
Meta har allerede beveget seg i denne retningen med Muse Spark 1.1 og Meta Model API. Den modellen ble presentert som sterkere på debugging, store migreringer og agentiske arbeidsflyter. Muse Code gjør satsingen mer konkret: Nå leverer Meta også agentmiljøet som modellen skal arbeide i.
Installasjonen er oppgitt for macOS og Linux med én terminalkommando. Det er greit, men det er ikke hovedsaken. Den virkelige testen begynner etter installasjonen, når agenten skal forstå arkitekturen, endre flere deler av systemet og kontrollere at den ikke har løst ett problem ved å lage tre nye.
Hvorfor bruker Muse Code vedvarende bakgrunnsagenter?
Vedvarende bakgrunnsagenter skal hindre at hver deloppgave begynner på bar bakke. Meta beskriver en hovedagent med flere spesialiserte agenter som forblir aktive gjennom hele økten. De undersøker neste steg og melder tilbake når de har noe relevant, i stedet for å bli opprettet på nytt for hver lille jobb.
Det høres ut som en teknisk detalj, men gjentatt informasjonsinnhenting er en av de store tidstyvene i agentarbeid. En agent leser arkitekturfilene. Den neste leser de samme filene. En tredje oppdager den samme avhengigheten ti minutter senere. Resultatet kan bli mye aktivitet uten tilsvarende framdrift.
Muse Code prøver å dele opp arbeidet uten å kaste bort det agentene allerede har funnet. Mark Zuckerberg skrev at store jobber kan fordeles til parallelle underagenter i isolerte worktrees. I en test skal systemet ha bygget seks spillfunksjoner samtidig uten kollisjoner, ifølge TechCrunchs omtale av lanseringen.
Isolerte worktrees er et fornuftig grep fordi flere agenter ellers kan endre de samme filene samtidig. Men seks parallelle funksjoner i en kontrollert demonstrasjon er ikke det samme som seks endringer i et produksjonssystem med database, CI, skjulte koblinger og kunder på innsiden. Parallelisering gjør en god plan raskere. Den gjør også en dårlig plan raskere.
Hva skjer hvis agenten krasjer midt i jobben?
Muse Code lagrer alle modellkall, verktøykjøringer, godkjenninger og endringer i en lokal, append-only hendelseslogg. Denne loggen er systemets eneste sannhetskilde under kjøringen. Meta sier at agenten dermed kan rekonstruere tilstanden og fortsette fra nøyaktig samme punkt etter et krasj.
Dette er kanskje den minst prangende og mest nyttige delen av lanseringen. Lange agentjobber feiler. En prosess stopper, nettverket forsvinner, et verktøy returnerer noe uventet eller maskinen må startes på nytt. Jeg har tidligere sett hvor fort en AI-agent kan miste retningen når konteksten kollapser. Hvis hele jobben bare eksisterer i modellens løpende samtalekontekst, kan mange timers arbeid bli redusert til et halvgodt sammendrag og et håp om at neste forsøk husker resten.
En hendelseslogg gir også bedre grunnlag for å forstå hva agenten faktisk gjorde. Du kan i prinsippet følge beslutningene fra godkjent plan til verktøykall og filendring. Det er viktig når agenten får mer ansvar. Et ferdig diff er ikke alltid nok. Noen ganger må du vite hvorfor den slettet en sjekk, hvilke testresultater den så, og hvilket steg som sendte den ut på viddene.
Meta kaller kjøremiljøet omstartssikkert og nøyaktig reproduserbart. Det er selskapets egen beskrivelse, og betaen må vise hvor godt dette holder når eksterne verktøy endrer tilstand underveis. Et API-svar, en oppdatert branch eller en pakke som forsvinner, kan ikke nødvendigvis spilles av på nytt bare fordi den lokale loggen er ryddig.
Hva tilfører Muse Spark 1.2?
Muse Spark 1.2 er en kodefokusert oppdatering av modellen Meta lanserte som versjon 1.1 den 9. juli 2026. Meta sier at den nye versjonen er forbedret på kodegenerering, vanskelig debugging, forståelse av hele kodebaser og komplette utviklerløp. Modellens produktside oppgir dessuten et kontekstvindu på 1 million tokens.
Det mest interessante er likevel at modellen og agentmiljøet er trent sammen. Meta brukte treningsforløp fra Muse Code og optimaliserte for blant annet mål, kontekstkomprimering og underagenter. Verktøyene i Muse Code ble også tatt inn i treningen. En modell som kjenner arbeidsmiljøet sitt, bør i teorien bruke færre forsøk på å finne ut hvordan verktøyene virker.
Meta brukte dessuten Muse Spark 1.1 til å lage krevende kodemiljøer og instruksjonsmaler. Den eldre modellen vurderte så kandidatbesvarelser, og materialet ble brukt til å trene etterfølgeren. Det er en skalerbar måte å lage flere vanskelige oppgaver på, men kvaliteten på læreren setter naturligvis grenser for kvaliteten på undervisningen.
Dette er en tydelig videreføring av den første Muse Spark-modellen fra Meta Superintelligence Labs. Den opprinnelige lanseringen handlet om Metas nye modellfamilie. Versjon 1.1 gjorde koding og API-tilgang viktigere. Med 1.2 og Muse Code prøver Meta å samle modell, verktøy og langtidsarbeid i ett produkt.
Kan Muse Code virkelig arbeide i 24 timer?
Meta testet Muse Code på GPU-kjerneoptimalisering med mer enn 1 000 verktøykall og kjøringer på opptil 24 timer. Agenten skrev, kompilerte, profilerte og forbedret Triton-kode for Nvidia Hopper-maskinvare. Det viser at systemet er laget for langt mer enn noen få raske kodeforslag.
Testen er samtidig spesialisert. Meta målte KDA- og MLA-kjerner mot oppgitte referanseimplementasjoner, og oppgaven ga agenten tydelige mål på ytelse. I MLA-oppsettet brukte Meta blant annet batchstørrelse 1, 64 hoder, sekvenslengde 8 192 og latent dimensjon 512. Dette er konkrete målinger, men det er ikke en kopi av hverdagen i et vanlig norsk utviklingsteam.
En gammel forretningsapplikasjon har sjelden ett pent tall som forteller om endringen er god. Krav kan være ufullstendige, testene kan dekke feil ting, og en teknisk forbedring kan være dårlig for brukeren. Det er enklere for en agent å optimalisere mot en målt GPU-baseline enn å tolke hva kunden egentlig mente med «gjør fakturasiden litt enklere».
Derfor er 24-timerskjøringen best forstått som en kapasitetstest. Den dokumenterer at Meta har bygget for lange løp, mange verktøykall og gradvis forbedring. Den dokumenterer ikke at Muse Code kan få stå alene i et hvilket som helst repo i et døgn. Det skillet er ganske viktig.
Hvordan skal planen kontrolleres før agenten slipper løs?
Muse Code leveres med tre innebygde ferdigheter for styring: /plan lager en plan som må godkjennes, /grill prøver å finne svakheter i planen, og /goal arbeider mot et definert sluttmål. Samlet viser de at Meta ser plan og kontroll som en del av produktet, ikke som noe brukeren skal lime inn i prompten hver gang.
Jeg liker særlig tanken bak /grill. Kodeagenter er ofte flinkere til å produsere en overbevisende plan enn til å oppdage hva planen mangler. En egen runde som leter etter svake antakelser, manglende tester og farlige avhengigheter kan spare mye opprydding senere.
Men en godkjenningsport har bare verdi hvis planen er forståelig og konsekvensene er synlige. Brukeren må kunne se hvilke områder agenten vil endre, hvilke tester den vil kjøre og hva den ikke vet ennå. En lang punktliste med grønt lys er ikke kontroll. Det er pynt.
Det samme gjelder valideringen etterpå. Meta sier at Muse Code både skriver kode og kontrollerer resultatet. Det er et nødvendig skritt, og jeg har tidligere sett på hvorfor egen kontroll av AI-generert kode har blitt en viktig del av kodeverktøyene. Agenten som skrev endringen, bør likevel ikke være den eneste som bestemmer om den er god.
Hva koster det, og hvem får tilgang?
Muse Code er tilgjengelig i beta, mens Muse Spark 1.2 er tilgjengelig gjennom Muse Code og Meta Model API med utvidet global tilgang. Meta oppgir installasjon for macOS og Linux, men den korte lanseringsposten gir ingen egen abonnementspris for terminalagenten.
Meta sier at kostnad skal være et konkurransefortrinn. AI-sjef Alexandr Wang beskrev Muse Code som et særlig godt alternativ for mange arbeidsflyter fra et kostnadsperspektiv, ifølge TechCrunch. Men uten et tydelig totalregnestykke for lange agentøkter er det for tidlig å slå fast hvor billig en 24-timers jobb faktisk blir.
Tokenpris er bare én del av regnestykket. Lange oppgaver kan bruke store kontekster, mange modellrunder og flere parallelle agenter. I tillegg kommer tiden til gjennomgang, CI og eventuell opprydding. Den billigste agenten er ikke billig hvis en utvikler må bruke resten av dagen på å finne ut hvilken av seks parallelle endringer som knakk bygget.
For interesserte utviklere er betaen likevel en lav terskel for å undersøke om Meta har fått samspillet mellom modell og verktøy til å sitte. For bedrifter bør starten være mer kontrollert: et avgrenset repo, tydelige tester, begrensede rettigheter og konkrete mål for kvalitet og tidsbruk.
Er dette en reell utfordrer til Claude Code og Codex?
Muse Code er en reell utfordrer fordi Meta nå stiller med mer enn en API-modell. Selskapet har en terminalagent, en kodefokusert modell, persistent koordinering, innebygd planarbeid og en runtime som skal tåle avbrudd. Det er de delene som må fungere sammen når en agent skal gjøre ordentlig arbeid.
Det betyr ikke at løpet er avgjort. Muse Code er i beta, og Meta viser først og fremst egne tester og demoer. Vi mangler fortsatt bred erfaring med vanlige produksjonsrepoer, ulike språk, dårlige testpakker og oppgaver der riktig svar ikke kan måles med én benchmark.
Den viktigste utviklingen er derfor ikke om Muse Spark 1.2 ligger noen poeng foran eller bak en konkurrent. Det er at kodeagenter nå blir bygget som varige arbeidsmiljøer med hukommelse, koordinering, godkjenning og gjenoppretting. Chatvinduet er ikke lenger hele produktet.
Meta har forstått hva som må bygges rundt modellen. Nå gjenstår den kjedelige, avgjørende testen: om Muse Code fortsatt er presis etter time nummer seks, om loggen faktisk redder jobben etter et krasj, og om de parallelle agentene skaper mer framdrift enn støy. Det er der en lovende beta blir et arbeidsverktøy.
Ofte stilte spørsmål
Kan Muse Code brukes på Windows?
Meta oppgir installasjon for macOS og Linux i den offisielle lanseringen. Windows er ikke oppført som en egen støttet plattform der. Windows-brukere bør derfor kontrollere oppdatert dokumentasjon og eventuell WSL-støtte før de planlegger et prosjekt rundt betaen.
Er Muse Code gratis å bruke?
Meta omtaler Muse Code som en beta og Muse Spark 1.2 som tilgjengelig via Meta Model API, men lanseringsposten oppgir ingen egen abonnementspris for agenten. Ikke legg til grunn at lange jobber er gratis. Kontroller gjeldende API-priser og vilkår på Meta Developer før bruk.
Kan Muse Code fortsette etter et krasj?
Ja, det er i hvert fall designmålet. Muse Code skriver modellkall, verktøykjøringer, godkjenninger og endringer til en lokal append-only logg. Meta sier at denne gjør kjøringen omstartssikker, slik at agenten kan rekonstruere tilstanden og fortsette fra punktet der den stoppet.
Bør en kodeagent få arbeide alene i et døgn?
Ikke uten tydelige grenser. Metas 24-timerstest viser kapasitet for lange løp, men ikke generell pålitelighet i produksjon. Bruk isolert arbeidsområde, begrensede rettigheter, godkjent plan, automatiske tester og menneskelig gjennomgang før endringer får påvirke hovedbranch eller produksjonsmiljø.
1 kommentar