AesCode 32B vs Muse Code: En affischmotor och en terminalagent är inte rivaler

AesCode 32B och Muse Code jämförs eftersom båda namnen innehåller ordet "code", och det är ungefär det enda de har gemensamt. AesCode 32B är Microsofts forskningscheckpoint för att generera redigerbar HTML och CSS — presentationer, affischer, dashboards, rapporter — publicerad under Apache 2.0 på Hugging Face, med repositoryt skapat den 29 september 2026 och committen som bär namnet "Release AesCode-32B" daterad den 7 oktober 2026. Microsoft har inte meddelat något om det: det finns inget lanseringsinlägg, inget pressmeddelande, och själva modellkortet anger inget releasedatum. Muse Code är inte ens en modell. Det är Metas terminalbaserade kodningsagent, i beta sedan början av augusti 2026, som tillbringar sin tid med att köra shellkommandon mot ett repository. Den ena av dem producerar en fil som du öppnar i en webbläsare. Den andra kör kommandon tills testerna går igenom. Att välja mellan dem är inte ett modellbeslut, och det användbara den här sidan kan göra är att hindra dig från att fatta det som om det vore det.

Vad var och en egentligen är till för

AesCode 32B utgår från Qwen3-VL-32B-Instruct och tränas, enligt sitt modellkort, med kallstartad övervakad finjustering på 3 000 demonstrationer följt av GDPO-baserad förstärkningsinlärning över sju belöningskanaler — exekvering, text, gräns, tabell/diagram, layout, tomrum och design. Sex av dessa kanaler är deterministiska verifierare; den sjunde är en vision-språk-domare som arbetar utifrån en bedömningsmall per sampel kopplad till en ”designgraf” över målsidan. Varje kandidatutdata renderas i en sandlådad Playwright-webbläsare med externa förfrågningar blockerade och poängsätts sedan utifrån DOM, beräknade stilar, avgränsningsrutor och en skärmbild. De avsedda utdata anges uttryckligen på kortet: redigerbara bildspel, affischer, instrumentpaneler och rapporter, plus forskning om multimodal kodgenerering. Modellen genererar ett komplett HTML-dokument och tränas att använda riktiga HTML-tabellstrukturer och ECharts-specifikationer så att dess utdata förblir inspekterbara.

Muse Code gör något strukturellt annorlunda. Det är en nativ binär för macOS och Linux med en huvudsaklig agentloop, asynkrona bakgrundsagenter som fortsätter samla kontext under en session, isolerade Git-arbetsträd så att underagenter inte kolliderar, och en lokal händelselogg som gör att en kraschad session kan spelas upp igen eller återupptas. Metas egen rapportering visar att den gör tusentals verktygsanrop under perioder som mäts i timmar. Det som säljs är loopen, inte artefakten.

Ställ de två sida vid sida och verben matchar inte. AesCode 32B renderar. Muse Code exekverar. Om ditt problem är "vår kvartalspresentation tar en designer tre dagar", är Muse Code irrelevant och AesCode 32B riktar sig rakt mot det. Om ditt problem är "ingen vill lägga en helg på att uppgradera det här beroendeträdet", har AesCode 32B inget att säga och Muse Code är verktyget.

Bevisningen på vardera sidan är inte samma typ av bevisning

Det här är delen som varje jämförelsesida får fel, så det är värt att ta sig tid med den.

AesCode 32B:s siffror kommer från en infografikutvärdering med 300 prover, tre genereringar per prompt utan urval, och de är imponerande på sina egna villkor: en Overall-poäng på 85,89 mot 81,28 för GPT-5.5 och 80,39 för Claude Opus 4.8, där båda dessa mättes med samma referensbildsupplägg av Microsofts egen testrigg. Kortet rapporterar också att ett allvarligt canvasgränsfel återkommer i 4,3 % av proverna mot 34,7 % för GPT-5.5, och att AesCode 32B slår sin egen Qwen3-VL-32B-basmodell med 22,4 poäng på Visual-dimensionen och 24,8 på Overall.

Läs allt detta som leverantörsrapporterat och oreproducerat. Benchmarken, belöningskanalerna som tränade modellen och mätvärdena som poängsätter den är samma labbs arbete, och de 300 exemplen är Microsofts. Det är inte ett skäl att avfärda resultatet – utvärderingen är ovanligt transparent, verifieringsstacken är öppen, och att kortet publicerar en dimension där ingen modell kommer över 60 ("stil", där inget får högre än 55,99) är mer ärlighet än vad de flesta leverantörstabeller uppvisar. Det är ett skäl att inte ställa 85,89 bredvid en siffra som tagits fram av ett annat labb för en annan uppgift och låtsas att en jämförelse har ägt rum.

Muse Codes siffror rapporteras av Meta, i ännu en annan bemärkelse: de mäter en modell plus ett testramverk tillsammans. Meta rapporterar 82,9 % på Terminal-Bench 2.1 för Muse Code, näst bäst efter Claude Opus 5 parad med Claude Code på 86,7 %, plus 59,3 % på DeepSWE 1.1 och 70,6 % på en intern kodningsbenchmark. Eftersom olika testramverk parades med olika modeller i den tabellen kan man inte utläsa modellens bidrag ur systemets poäng. Och det finns ingen som helst överlappning mellan vad Muse Code mäts på och vad AesCode 32B mäts på – den ena poängsätts utifrån terminaluppgifter och mjukvaruteknik, den andra utifrån huruvida texten i en infografik är läsbar och layouten inte flödar över.

Vad en ”32B-checkpoint” döljer

Driftsättning är där de två produkterna skiljer sig mest, och den korta versionen ryms i en punktlista.

• Vad det är — AesCode 32B: en modellcheckpoint med 33B parametrar som du laddar ner. Muse Code: en installerbar terminalagentprodukt.

• Licens — AesCode 32B: Apache 2.0, vikter ingår. Muse Code: proprietär; modellen bakom den är stängd.

• Vad du tillhandahåller – AesCode 32B: en GPU och en serveringsstack. Muse Code: en API-nyckel eller en prenumeration.

• Hårdvarugolv — AesCode 32B: kortet rekommenderar att planera ungefär 65 GB acceleratorminne enbart för bf16-parametrarna, och dess eget serveringsexempel använder fyrvägs tensor-parallellism. Muse Code: en laptop.

• Kontext — AesCode 32B: 24 576 tokens i den rapporterade konfigurationen, med prompter och svar begränsade till 8 192 under RL-träning. Muse Code: ett fönster på 1M tokens via den underliggande Muse Spark-modellen.

• Pris — AesCode 32B: vikterna är gratis; kostnaden är hårdvara. Muse Code: debiteras per token, eller via en månadsplan.

• Underlag — AesCode 32B: en utvärdering genomförd av leverantören på deras egna 300 sampel, med testramverket publicerat. Muse Code: Meta-rapporterade benchmarkresultat på systemnivå för en kopplad agent-plus-modell-stack.

Den där raden om "hårdvarugolv" är den folk hoppar över. En 32B-checkpoint i bf16 är inte en laptopmodell, och AesCode 32B är dessutom en visionsspråkmodell, så serveringsvägen hanterar även bildindata. Muse Code är en binärfil du installerar på en eftermiddag.

Där de genuint överlappar

Det finns exakt en verklig överlappning, och den är smal: båda kan riktas mot en designnära artefakt och ombes producera något som en människa kommer att förfina. Om ditt team genererar interna dashboards som kod och också vill ha en agent som kan öppna en pull request mot dashboard-repot, berör båda produkterna det arbetsflödet.

Även där är uppdelningen ren. AesCode 32B producerar artefakten. Muse Code producerar ändringen. En pipeline som gör båda skulle anropa AesCode 32B för att rendera, och sedan lämna den resulterande filen till en agent för att placera, koppla upp och testa — och inget hos någon av produkterna hindrar det, eftersom de aldrig konkurrerade om samma plats.

Halvan av den här matchen som du kan tippa idag

Här är en praktisk asymmetri som är värd att säga rakt ut. AesCode 32B driftsätts inte av någon inferensleverantör. Hugging Face-kortet listar ingen hostad slutpunkt, ingen partner och inget API; om du vill använda det laddar du ner 65 GB vikter och bygger serveringsvägen själv. Det är ett normaltillstånd för en forskningsrelease och det är också det enskilt största hindret mellan modellen och alla som inte äger åtta GPU:er.

Muse Codes underliggande modell har inte det problemet. Muse Spark-familjen tillhandahålls som en vanlig API-modell, och Muse Spark 1.2 finns i OrcaRouter-katalogen där den faktureras enligt Metas listpriser på 1,25 USD per miljon indatatokens och 4,25 USD per miljon utdatatokens – leverantörens listpris förs vidare, inget påslag från vår sida, så en prisändring från Meta landar här samma dag som den landar där. En nyckel täcker den tillsammans med över 200 andra modeller, med automatisk failover om en leverantör krånglar, vilket är skillnaden mellan "vi kan prova det här" och "vi kan sätta det här på en produktionsväg". Om det du faktiskt ville ha från den här sidan var ett sätt att använda intelligensen inuti Muse Code utan att adoptera Muse Code-produkten, är det vägen, och den finns. Om det du ville ha var AesCode 32B, är vägen en nedladdning.

Vilken ska man välja?

Välj AesCode 32B om artefakten är poängen. Du producerar presentationer, rapporter, affischer eller dashboards i stor volym, du har hårdvaran eller viljan att hyra den, och lockelsen med en modell som genererar strukturerad, redigerbar HTML — tabeller som tabeller, diagram som ECharts-specifikationer, allt diffbart i Git — är värd en serveringslösning av forskningsklass. Acceptera att du är en tidig användare av en oannonserad modell med få nedladdningar, att inget oberoende labb har reproducerat dess resultat, och att dess 24K-kontext är en verklig begränsning för långa dokument.

Välj Muse Code om processen är själva poängen. Du vill ha en agent som körs i terminalen, överlever en krasch mitt i en session och kan hålla igång flera arbetsströmmar samtidigt i isolerade worktrees, och du är bekväm med att betala per token eller per månad för det.

Välj ingen av dem, och routa direkt till Muse Spark 1.2, om det du behövde var en kapabel resonemangsmodell bakom en API-nyckel och terminalharneset aldrig var den del du ville ha.

Vad skulle ändra den här sidan

Tre saker. Om en inferensleverantör plockar upp AesCode 32B – eller Microsoft publicerar en hostad slutpunkt – kollapsar driftsättningskolumnen och modellen blir något man kan utvärdera på en eftermiddag, vilket skulle göra detta till en mycket jämnare fråga för designtunga team. Om en oberoende utvärdering reproducerar 85,89 Overall och gränsfelsfrekvensen på 4,3 %, minskar bevisasymmetrin avsevärt. Och om Meta öppnar vikterna för Muse Spark, försvinner inramningen "du kan ladda ner den ena men inte den andra" helt. Tills något av detta inträffar är den ärliga sammanfattningen att dessa två produkter delar ett ord, inte ett jobb.