Muse Code: Vem gör den, vad den kostar och vilken version som är aktuell

Muse Code är Metas kodningsagent för terminalen och CI, byggd för modellfamiljen Muse Spark, och de två versioner som spelar roll för alla som kommer hit är Muse Spark 1.3 – den nuvarande generationen, daterad 2 september 2026 – och Muse Spark 1.2, som är den version CLI:t fortfarande väljer om du inte anger något annat. Muse Code installeras som en nativ muse-binär, körs interaktivt eller huvudlöst och säljs på tre sätt: tre månadsplaner för 5,00 $, 15,00 $ och 50,00 $, samt fakturering per token efter förbrukning på Meta Model API för 1,25 $ per miljon indatatoken och 4,25 $ per miljon utdatatoken på Standard-nivån. Ännu en generation tillbaka, Muse Spark 1.1, tillhandahålls fortfarande på samma nivå till samma priser.

Läs detta som en referenssida, inte som nyheter. Muse Code i sig är inget nytt att rapportera: Meta släppte det som en beta den 5 augusti 2026 och tog det ur beta den 31 augusti 2026, och den här sidan använder dessa datum för att placera modellen i tiden snarare än för att annonsera den. Motiveringen för sidan är bestående sökefterfrågan som vi mätte på egen hand den 28 september 2026, där den rena frågan "muse code" fick 4 547 visningar under de senaste 28 dagarna med noll klick, och den kommersiella stavningen av samma intention – "muse code free", "muse code plan", "muse code plans", "muse code free tier", "muse code 1.3" – fick ytterligare 124 visningar, också med noll klick. Läsarna ställer fyra specifika frågor. Den här sidan besvarar dem i ordning, utifrån Metas egen dokumentation, och säger tydligt när en siffra kommer från Meta snarare än från en oberoende utvärderare.

Om det du faktiskt behöver är en granskning av agentens beteende, eller en direkt jämförelse mot ett annat kodningsramverk, är det inte den här sidan. De finns redan på den här bloggen, och de som är värda din tid är länkade i slutet.

Vad Muse Code är, och vem som gör det

Leverantörens definition är en enda mening: "Muse Code är Metas kodningsagent för terminalen och CI, byggd för Muse Spark." Det är inte ett bibliotek, inte ett chattgränssnitt och inte en modell – det är en harness. Du kör den i en projektkatalog; den planerar, redigerar filer och kör kommandon för att slutföra en uppgift, med godkännanden och en OS-sandbox aktiv från första körningen.

Meta framställer Muse Code och Meta Model API som två vägar till samma underliggande modell: anropa API:et direkt när du bygger din egen agent eller applikation, kör Muse Code när du vill ha en färdig kodagent på kommandoraden eller i en pipeline. Den skillnaden spelar roll för prissättningen, eftersom prenumerationen köper ramverket och API-nyckeln faktureras separat per token.

Installationen görs med en enradsinstallatör, och de två leverantörsytorna är inte helt eniga om strängen:

• macOS och Linux — curl -fsSL https://dev.meta.ai/install.sh | sh på dokumentationssidan, och samma kommando som avslutas med | bash på marknadsföringssidan och i båda forskningsblogginläggen

• Windows — irm https://dev.meta.ai/install.ps1 | iex, publicerad endast på dokumentationssidan

• Verifiering — muse --version, sedan muse i en projektkatalog för att starta en interaktiv session

• Första körningen – du ombeds lita på arbetsytan (det är den som läser in dess skills, regler och hooks) och autentisera antingen via inloggning i webbläsaren eller med en API-nyckel; i CI anger du META_API_KEY i stället

• Två gränssnitt — muse för det interaktiva terminalgränssnittet, muse exec "<prompt>" för en enda icke-interaktiv körning till slutförande

• Styr det från ditt eget program — muse serve kör ett versionerat sessionsprotokoll, muse schema skriver ut dess JSON-schema, och npm install @muse-code/sdk installerar TypeScript-omslaget

Den sista punkten är den del som de flesta sammanfattningar missar. Muse Code är inte bara ett CLI: sessionsprotokollet är ett dokumenterat, versionshanterat gränssnitt, och ändringsloggen visar att det utökas avsiktligt — sessioner kan döpas om via protokollet, klienter kan läsa en strukturerad diff-sammanfattning för varje ändring, och ett drivande program kan ange en sessionsövergripande standard för resonemangsansträngning.

Vad Muse Code kostar, och frågan om gratisnivån besvarad i klartext

Det finns ingen gratisnivå. Det är värt att säga rakt ut, eftersom det är den enskilt mest ställda kommersiella frågan i efterfrågedatan, och svaret är entydigt: Muse Code-produktsidan, prenumerationssidan och ändringsloggen innehåller tillsammans ingen gratisplan, ingen provperiod, ingen tilldelning av gratiskrediter och ingen hastighetsbegränsad kostnadsfri åtkomst.

En varning om den kontrollen. Metas prisdokumentation använder faktiskt orden "platform free-tier credits" en gång — i noten om Muse Voice Transcribe, som säger att transkribering med noll datalagring prissätts i paritet med Standard-nivån och att "platform free-tier credits" gäller. Muse Voice Transcribe är en separat produkt på Meta Model API med egen timbaserad fakturering; den meningen säger ingenting om Muse Code. Om du hittar den raden citerad som bevis för en gratisnivå för Muse Code, tas den ur sitt sammanhang.

Det Meta faktiskt publicerar är tre prenumerationsnivåer, som alla faktureras, plus tokenfakturering efter användning för allt utöver planens promptkvot:

• Vardagsanvändning — 5,00 USD/månad; tillgång till de senaste Muse-modellerna; 10–50 promptar var 5:e timme, inklusive uppladdning av bilder och videor; röstläge; webbsökning

High Usage — 15,00 USD/månad; allt i Everyday-planen; 5× mer användning än Everyday; fler prompter; fler multimodala indata

• Power Usage – 50,00 USD/månad; allt i High Usage-planen; 20× Everyday-användningsgränsen; utökade prompts; tidig åtkomst till nya funktioner; större filuppladdningar

• Standardpriser för tokens – 1,25 USD per miljon indatatokens, 4,25 USD per miljon utdatatokens, 0,15 USD per miljon cachade indatatokens, som gäller för muse-spark-1.3, muse-spark-1.2 och muse-spark-1.1 på samma sätt

• Tokenpriser för bidragsgivare — 0,10 $ / 0,20 $ / 0,002 $ per miljon indata, utdata och cachad indata, för muse-spark-1.3-contributor och muse-spark-1.2-contributor

Standard- och Contributor-nivåerna skiljer sig på exakt en väsentlig punkt, och Meta anger det både på modellsidan och i prislistan: på Standard används dina prompter och kompletteringar inte för att träna Metas modeller; på Contributor gör de det. Produktsidan märker Contributor-raderna med ”Används för att förbättra våra produkter” och Standard-raderna med ”Används inte för att förbättra våra produkter”. Contributor är ungefär tolv gånger billigare för indata och omkring tjugoen gånger billigare för utdata, vilket är en tillräckligt stor skillnad för att det är ett beslut om datastyrning snarare än ett budgetbeslut.

Tre prisdetaljer är lätta att missa och alla är värda att känna till innan du dimensionerar en arbetsbelastning:

• Ingen premie för lång kontext – Metas prislista säger detta uttryckligen: du betalar samma taxa oavsett om kontextfönstret är mestadels tomt eller nästan fullt, vilket är ovanligt och väsentligt förändrar ekonomin för långa agentkörningar

• Webbsökningsgrundning debiteras separat – 2,50 USD per 1 000 sökfrågor utöver förfrågans tokenkostnad, och det gäller textmodeller som Muse Spark

• Hastighetsbegränsningar gäller per team, inte per nyckel — 3 000 förfrågningar och 4 000 000 tokens per minut på Standard, 100 förfrågningar och 3 000 000 tokens per minut på Contributor; att använda flera nycklar inom ett team multiplicerar inte kvoten

Prenumerationsmekanismer dokumenteras på Metas prenumerationssida och är konventionella: en uppgradering proportioneras och är omedelbar, en nedgradering träder i kraft vid nästa faktureringscykel, avbokning kräver minst 24 timmar före faktureringsdatumet, och det finns inga återbetalningar för en avbokad prenumeration utom där lagen kräver en. Prenumerationer täcker specifikt inloggningsuppgifterna för Muse Code CLI; ytterligare API-nycklar faktureras enligt pay-as-you-go.

Vilken version är aktuell: 1.2.1, Muse Spark 1.3, och standardversionen som inte är någon av dem?

Detta är den fråga som efterfrågedata talar tydligast om — att sökningen "muse code 1.3" överhuvudtaget finns — och den är genuint förvirrande, eftersom "versionen" kan betyda tre olika saker och Muse Code publicerar alla tre.

• CLI-versionen – 1.2.1 är den aktuella. Metas ändringslogg listar dess versioner som 1.2.1, 1.1.1, 0.2.1 och 0.1.0, varav den sista är märkt "Lanseringsversion"

• Modellgenerationen — Muse Spark 1.3, tillkännagavs den 2 september 2026 och beskrevs på Metas modellsida som "den senaste versionen … Rekommenderas för nytt arbete"

• CLI:ns standardmodell — muse-spark-1.2, som anges i avsnittet om första körningen i dokumentationen och igen under modellval på konfigurationssidan

Så en nyinstallation av Muse Code 1.2.1 kör Muse Spark 1.2 om du inte anger --model muse-spark-1.3 eller byter mitt i sessionen med /models. Metas egna snabbstartsidor använder muse-spark-1.3 i varje API-exempel, vilket gör uppdelningen lättare att misstolka än den borde vara: API-exemplen och CLI-standardinställningen pekar inte på samma modell i dag.

Ändringsloggen för 1.2.1 beskriver vad som har ändrats i testramverket snarare än i modellen, och de viktigaste punkterna är:

• Röstinmatning påslagen som standard i macOS, bunden till Option+V och hanteras med /voice

• Ett /rewind-kommando som återställer konversationen till en tidigare inmatning och använder samma väljare som vid dubbeltryck på Esc

• [Bild #N]-etiketter på inklistrade och släppta bilder så att modellen kan tillfrågas om en specifik bild via numret, med etiketter och källsökvägar som bevaras vid återupptagning, tillbakaspolning och förgreningar

• En medföljande migrate-skill som importerar minnesanteckningar och MCP-serverdefinitioner från Claude Code eller Codex till Muse Code

• /mcp för en aktuell inventering av anslutna MCP-servrar och deras verktyg

• Nya sessioner öppnas i behörighetsprofilen Auto-review, som ger samma åtkomst som ”Fråga mig” men dirigerar berättigade godkännandeförfrågningar till en automatiserad granskare och faller tillbaka till att fråga dig när granskaren inte är tillgänglig

• Säkerhetsfixar, varav tre är beteendemässiga snarare än kosmetiska: kommandon som startas via omslag som env och setsid granskas nu som det kommando de faktiskt startar; en ändring av behörighetsläget mitt i en session tillämpas på redan körande verktyg vid deras nästa åtgärd; och behörighetsprofilen Obegränsad beter sig nu exakt som --yolo

På modellsidan säger tillkännagivandet den 2 september uttryckligen att Muse Spark 1.3 tränades över en mångfald av harnessar, och att det var resonemangsnivån – "Muse Spark 1.3 med max reasoning finns nu tillgänglig på Muse Code och Meta Model API" – snarare än enbart basmodellen som Meta marknadsförde. Lanseringsinlägget för Muse Spark 1.2 från den 5 augusti lägger till den andra halvan av historien: Muse Spark 1.2 samtränades med själva Muse Code, med hjälp av rejection-samplade harness-trajektorier plus receptarbete kring mål, kompaktering och subagenter, med Muse Code-verktygsuppsättningen integrerad för att maximera harness-kompatibilitet. Modellen och harnessen utvecklades mot varandra.

Enveloppen: kontext, modaliteter, plattformar

Muse Spark 1.3, Muse Spark 1.2 och Muse Spark 1.1 delar alla en och samma ram, och Meta anger det i en enda tabellrad: 1 048 576 tokens i kontext, med text, bild, video, ljud och PDF som indata och text som enda utdata, i alla nivåer och alla versioner.

Modalitetsparitet kommer med en varning som Meta publicerar som en fotnot och som är värd att upprepa snarare än att begrava: ljudförståelse i Muse Spark 1.3 stöds inte fullt ut och svarskvaliteten för förfrågningar som innehåller ljudinnehåll kan försämras; Metas egen vägledning är att använda Muse Spark 1.2 för ljud, eller Muse Voice Transcribe för dedikerad tal-till-text. I CLI:t är det genomförbart — --model muse-spark-1.2 är en dokumenterad åsidosättning, och standardvärdet pekar redan dit.

Reasoning effort är en inställning på harness-nivå med åtta nivåer, och Metas konfigurationssida namnger dem i ordning: none, minimal, low, medium, high (standard), xhigh, max och ultra. Tre detaljer i den listan är bärande:

• max är den djupaste resonemangsnivån, beskriven som utökat resonemang bortom xhigh, och Muse Code erbjuder den på både Standard- och Contributor-nivåerna

• ultra är en klientsidig inställning snarare än en modellnivå: den mappas till varje leverantörs högsta stödda resonemangsnivå och kan få Muse Code att delegera mer aggressivt, och om en leverantör inte stöder den körs en begäran om ultra på xhigh

• Meta-providern accepterar inte none, så den lägsta nivån är endast tillgänglig via andra leverantörer som konfigurerats i testramverket

Plattformsstöd är där Metas två ytor inte stämmer överens, och oenigheten är liten men verklig. Dokumentationssidan säger att Muse Code körs på macOS, Linux och Windows från en och samma kodbas, och listar tre Windows-specifika beteenden: PowerShell ersätter Bash, så agentkörda kommandon använder PowerShell-syntax och Windows-kommandoradsverktyg; sandlådan kan begära administratörsgodkännande, och Windows kan visa en User Account Control-fråga första gången sandlådan initieras, även om normal användning inte kräver att man kör som administratör; och två funktioner är otillgängliga på Windows – röstinmatning och sessionsmeddelanden, vilka båda fungerar på macOS och Linux. Produktsidan säger däremot bara ”Tillgängligt för MacOS och Windows”. Båda påståendena kommer från Metas egen webbplats i dag; lästa tillsammans innebär de att Windows stöds med dokumenterade luckor, och att Linux stöds även om marknadsföringssidan inte nämner det.

En ytterligare nyans om tillgänglighet kommer från dokumentationen snarare än från marknadsföringstexten: Workflows – den parallella och stegvisa agentorkestreringen – samordnar arbete endast när det installerade bygget innehåller arbetsflödesmotorn och utrullningen är aktiverad, och Meta säger rent ut att de "inte är tillgängliga i varje bygge eller på varje plattform". Om en arbetsflödesfunktion är anledningen till att du installerar, kontrollera att ditt bygge har den i stället för att anta att den finns.

Vad Meta påstår, med testramverket och insatsen namngivna

Meta publicerar benchmarkmaterial, så den ärliga inramningen här är inte ”inga leverantörsbenchmarkar” – det är ”det här är leverantörsbenchmarkar, med jämförelsevillkoren angivna där Meta anger dem.”

Det enda kvantitativa påståendet som Meta gör i löpande text finns i tillkännagivandet av Muse Spark 1.3, och det tillskrivs en intern jämförelse snarare än en tredjepartsutvärdering: "I jämförelser som utförts av Metas ingenjörer visade den sig vara betydligt snabbare och effektivare, med ~20 % färre verktygsanrop och ~25 % färre tokens." Baslinjen anges – relativt Muse Spark 1.2 – och ansträngningsnivån ligger i tillkännagivandets egen inramning, eftersom releasen har titeln Muse Spark 1.3 med max reasoning. Det som inte anges är uppgiftsuppsättningen, antalet körningar eller harness-konfigurationen, utöver att det är Muse Code. Betrakta de två procenttalen som en leverantörsrapporterad färdriktning, inte som ett uppmätt benchmarkresultat.

Det andra publicerade resultatet är en fallstudie snarare än en poäng, och det är det mer intressanta av de två. Meta rapporterar att de testade Muse Spark 1.2:s förmåga att iterativt optimera GPU-kärnor över 1 000+ verktygsanrop och upp till 24 timmar, med hjälp av Muse Codes agentiska kodningsmiljö för att skriva, kompilera, profilera och successivt förbättra kärnprestanda mot en tillhandahållen baslinje. Arbetsbelastningen är namngiven – KDA- och MLA-kärnor på NVIDIA Hopper-GPU:er – och det är även begränsningen: tredjepartskärnbibliotek såsom FLA var förbjudna, och baslinjen var en Triton FLA KDA-implementering. En 24-timmars körning med tusen verktygsanrop är en annan typ av bevis än en benchmarkprocent. Det säger något om uthållighet under ett långsiktigt mål och väldigt lite om jämförande kvalitet.

Lanseringsdiagrammen för både Muse Spark 1.2 och Muse Spark 1.3 ställer dessa modeller mot en liten uppsättning namngivna konkurrenter över agent-, kodnings-, instruktionsföljnings- och långkontextutvärderingar — DeepSWE v1.1, SWE-Atlas-QnA, Terminal-Bench 2.1 och 4.0, tau2-bench, GDPval, SciCode, IFBench, MultiChallenge och AA-LCR v1.1 finns bland axlarna. Dessa diagram är producerade och plottade av leverantören, och konkurrentkonfigurationerna i dem är Metas val, inte en neutral panel. Vi återger inte stapelvärdena här av den anledningen: ett leverantörsdiagram som läses som en resultattavla är precis det felläge som den här sidan är avsedd att undvika.

Två ärliga luckor är värda att nämna snarare än att skyla över:

• Meta publicerar inte någon direkt jämförelse av Muse Code mot Muse Spark 1.2 vid matchad ansträngning på en namngiven uppgiftsuppsättning; siffran ~20 %/~25 % är det närmaste man kommer, och det är en intern jämförelse med angivna effektivitetsdeltan snarare än poäng.

• Meta publicerar ingen utvärdering av live-latensen för CLI:t, och ingen av de publicerade siffrorna beskriver hur en session känns under verklig redigeringsbelastning

Vad Artificial Analysis mäter oberoende

Artificial Analysis är den oberoende utvärderaren som för närvarande publicerar en mätning av kodningsagenter som omfattar Muse Code, och det är en annan typ av siffra än allt ovanstående: raderna är harness- och modellpar, utvärderade av AA i stället för av leverantören.

På Artificial Analysis Coding Agent Index — sidan identifierar sig i sin egen strukturerade data som v1.5 — Muse Code-raderna lyder:

• Muse Code kör Muse Spark 1.3 med maximal resonemangsnivå — 54.3

• Muse Code kör Muse Spark 1.3 med xhigh-resonemang — 48.3

• Toppen av samma resultattavla — Claude Code som kör Claude Opus 5.5 med maximalt resonemang, på 66,0

Två saker med de där siffrorna spelar större roll än siffrorna själva. För det första: gapet på 5,0 punkter mellan raderna max och xhigh gäller samma modell i samma harness med en enda inställning ändrad, vilket är en användbar påminnelse om att en "Muse Code-poäng" är underbestämd om inte effort-nivån anges. För det andra är den här resultattavlan en annan mätning än den som vår egen septemberbevakning av Muse Spark 1.3 citerade: den tidigare artikeln angav 68 för Muse Spark 1.3 vid max, 64 vid xhigh och 68 för Claude Opus 5 vid xhigh. De siffrorna finns inte längre på den aktuella resultattavlan – den nuvarande översta raden är Claude Opus 5.5 vid max med 66,0, och Muse Code-raderna visar 54,3 och 48,3. Indexet har reviderats och fältets sammansättning har ändrats. Om du bär runt på de äldre siffrorna är de ersatta, och de två uppsättningarna bör aldrig citeras sida vid sida som om de vore samma mätning utförd två gånger.

AA-modellsidan för Muse Spark 1.3 är återigen en separat yta, och dess egna siffror är AA-mätta i stället för leverantörsrapporterade: ett Intelligence Index på 48,09, Terminal-Bench 2.1 på 84,3 %, GPQA Diamond på 93,5 %, HLE på 48,7 %, SciCode på 58,8 % och långkontextsåterkallelse på 83 %, med ett releasedatum på 2026-09-02, ett kontextfönster på 1 000 000 token och klassificering som proprietär, stängd vikt. Observera att detta är en indexrevision på en modellsida — AA publicerar index per modell som revideras enligt sitt eget schema, så att blanda en siffra från den här sidan med en siffra från en annan modells sida ger dig inte en jämförelse av samma ögonblicksbild.

Vad inget av detta ger dig är en matchad jämförelse. AA:s kodningsrader korsar testramar per konstruktion – Muse Code mot Codex, mot Claude Code, mot Grok Build, mot Kimi Code CLI – så en rad-mot-rad-läsning jämför ett testrams-modellpar med ett annat testrams-modellpar, inte två modeller under en och samma testram. Där Meta inte har kört den matchade jämförelsen och AA:s resultattavla inte är byggd för att besvara den, är den ärliga hållningen att den direkta jämförelsen inte existerar vid matchad ansträngning och testram, snarare än att konstruera en från närliggande siffror.

Vad OrcaRouter dirigerar, och vad det inte gör

OrcaRouter är en enda slutpunkt som täcker 200+ modeller till varje leverantörs listpris utan påslag, vilket innebär att tillgänglighetssvaret för den här familjen är kontrollerbart snarare än en policyfråga. Kontrollerat mot vår aktuella publika modellista idag:

• meta/muse-code — finns inte i katalogen. Muse Code är ett ramverk, inte en routbar modell, och vi serverar den inte

• meta/muse-spark-1.3 — finns inte i katalogen

• meta/muse-spark-1.2 — routbar, med ett kontextfönster på 1 048 576 token och prissättning på 1,25 USD per miljon indatatoken, 4,25 USD per miljon utdatatoken och 0,15 USD per miljon cachad läsning, samma priser som Meta publicerar

• meta/muse-spark-1.1 — går även att dirigera, till samma tre priser

Så här ser det i praktiken ut på OrcaRouter: du kan nå de levererade Muse Spark-generationerna via samma slutpunkt som du använder för allt annat, och du kan inte nå Muse Code eller den aktuella 1.3-generationen via den. Läs det som en beskrivning av dagens katalog och inget mer; tillgängligheten ändras och modellistan är stället att kontrollera det på.

Det som gör att en router är värd sitt pris för en arbetsbelastning som denna är de två saker som en prenumeration inte kan ge dig. Det första är att en enda API-nyckel är ett routinglager som automatiskt växlar över en begäran när en leverantör försämras, vilket spelar roll när en agentkörning är tusentals verktygsanrop djup och du helst inte vill förlora den på att en uppströmsleverantör har en dålig eftermiddag. Det andra är att begäran beskrivs i stället för att hårdkodas – du kan sätta Muse Spark 1.2 bakom samma routing-DSL som vilken annan modell som helst och ändra vad som betjänar den utan att ändra din klient.

Vanliga frågor

Är CLI:ets standardmodell den aktuella modellen? Nej. Muse Codes standard är muse-spark-1.2; den aktuella generationen är Muse Spark 1.3, som tillkännagavs den 2 september 2026, och du når den med --model muse-spark-1.3 eller /models-kommandot.

Vilken formulering är rätt — "Muse Code 1.3" eller "Muse Spark 1.3"? Muse Spark 1.3. Muse Code-versioner är harness-utgåvor och den aktuella är 1.2.1; de två numreringsserierna är orelaterade, vilket är hela anledningen till att sökfrågan "muse code 1.3" ger förvirrade resultat.

Om jag bara behöver ljudinmatning, vilken modell ska jag konfigurera? Muse Spark 1.2. Metas egen fotnot säger att ljudförståelse i 1.3 inte stöds fullt ut och kan försämra svarskvaliteten, och hänvisar ljudarbete till 1.2 eller till Muse Voice Transcribe.

Är Contributor-nivån en gratisnivå eller testnivå? Nej, och det är inte en rabatt som du får automatiskt. Det är en lägre prissatt variant i alla Muse Spark-versioner från och med 1.2 i utbyte mot tillåtelse att träna på dina promptar och slutföranden; 1.1-generationen har ingen Contributor-variant.

Slutsats

Muse Code är Metas terminal- och CI-kodagent, skapad av Meta för dess Muse Spark-modeller, och säljs som tre månadsplaner för 5,00 $, 15,00 $ och 50,00 $ utan gratisnivå, med stöd av Standard-priser för betala-per-användning på 1,25 $ in och 4,25 $ ut per miljon tokens samt Contributor-priser på 0,10 $ och 0,20 $ för samma tokens om du låter Meta träna på dem. Den aktuella CLI-versionen är 1.2.1, den aktuella modellgenerationen är Muse Spark 1.3, och CLI:t använder fortfarande Muse Spark 1.2 som standard — ange versionen och resonemangsansträngningen när du citerar en poäng, eftersom Muse Code som kör Muse Spark 1.3 på max och på xhigh inte är samma mätning, och leverantörens främsta effektivitetsanspråk är en intern jämförelse snarare än ett oberoende resultat.

För en praktisk titt på själva ramverket, se vår genomgång av terminalkodningsagenten Muse Code.