Muse Spark 1.3-handledning: En praktisk guide för utvecklare

Meta släppte Muse Spark 1.3 den 2 september 2026, och uppgraderingsinstruktionerna ryms på en rad: ändra modell-ID:t. Det betyder att den använder samma slutpunkter, samma SDK och samma prissättning.

Vad den där engångsändringen ger dig, enligt Meta, är en modell som slutför samma uppgift med cirka 20% färre verktygsanrop och 25% färre token än Muse Spark 1.2. De siffrorna kommer från jämförelser som körts av Metas egna ingenjörer, på uppgifter de inte namnger, utan metodbeskrivning.

Det är precis den sortens påstående jag vill kontrollera innan jag upprepar det. 

Så jag installerade Muse Code, saboterade medvetet ett riktigt open source-projekt och körde samma tre uppgifter på båda modellerna.

För att följa den här handledningen för Muse Code behöver du ett utvecklarkonto hos Meta, en terminal du är bekväm i och macOS eller Linux för Muse Code-agenten. Windows-användare har fortfarande otur i nuvarande beta.

Kort sammanfattning

• Muse Spark 1.3 är Metas flaggskeppsmodell för multimodalt resonemang, släppt 2 september 2026, med ett kontextfönster på 1M token.
• Muse Code startar dig på muse-spark-1.3-contributor som standard, vilket betyder att Meta tränar på din kod om du inte byter. Träning är opt-out, inte opt-in.
• Över 6 körningar på 3 koduppgifter var 1.3 billigare på 2 och 38% dyrare på den tredje, för en nettokostnadsökning på 12% över helheten.
• Modellslutföranden föll 23% och 32% på de 2 uppgifter där 1.3 vann, vilket stämmer med Metas påstående om färre verktygsanrop. Okachad input föll på alla 3, men aldrig med 25%.
• Resonemangsnivån ultra finns i CLI och i valvyn i sessionen, men backend nekar den med en namngiven feature gate.

Vad är Muse Spark 1.3?

Muse Spark 1.3 är Metas flaggskeppsmodell för multimodalt resonemang, släppt av Meta Superintelligence Labs den 2 september 2026 och byggd för långa agent-sessioner och kodning över stora kodbaser. Den rymmer 1 048 576 token kontext och tar emot text, bilder, video och filer.

Sex saker ändrades från Muse Spark 1.2:

• Effektivitet. Cirka 20% färre verktygsanrop och 25% färre token i Metas interna jämförelser.
• Samarbete. Den ställer förtydligande frågor vid vaga prompts och dubbelkollar före avgörande åtgärder.
• Multitasking inom en tråd, så att ett meddelande mitt i flödet fästs vid rätt uppgift.
• Bättre följsamhet till långa instruktioner, med färre tappade begränsningar över fler-stegsuppgifter.
• Bättre kalibrering vid irreversibla åtgärder.
• Renare kodstil. Färre onödiga turer, mindre ordrikhet.

Allt detta ser bra ut, men Metas publicerade scorecard kör Muse Spark 1.3 på max resonemang mot Muse Spark 1.2 på xhigh, och max var fortfarande spärrad vid lansering. 

Artificial Analysis gav den levererade xhigh-varianten Intelligence Index 61 och max 62. Alltså bara en poängs skillnad.

Matt Crabtree har redan täckt hela benchmark-tabellerna, prisbilden och hur detta står sig mot GPT-5.6 Sol och Claude Opus 5 i sin analys av Muse Spark 1.3-släppet. Jag upprepar inget av det. Det som följer är vad som händer när du installerar prylen och får den att fungera.

Så här får du tillgång till Muse Spark 1.3

Det finns tre vägar, och rätt val beror på vad du bygger. Välj i tabellen och hoppa sedan till matchande avsnitt.

Muse Code, terminalagenten

Muse Code är Metas terminalbaserade kodningsagent, i beta för macOS och Linux. Det är seleverket som kör Muse Spark, och de två versioneras oberoende, så muse --version säger ingenting om vilken modell du pratar med. Håll isär dem i huvudet.

curl -fsSL https://dev.meta.ai/install.sh | bash

Detta hämtar en 230 MB-binär och lägger den på ~/.local/bin/muse, som inte finns på allas PATH. 

Kontrollera sedan vad du fick:

muse --version

Den 4 september 2026 gav det mig Muse Code 1.0.2 (1.0.2-R2040.1). 

Lite märkligt för en beta att säga, eftersom tredjepartsverktyg dokumenterade Muse Code som 0.2.1 bara veckor tidigare. Pinna den version du får till datumet du fick den.

Skärmdump av författaren. Installerar Muse Code med enrads-skriptet och bekräftar version 1.0.2 på macOS.

Kör nu muse. Första gången skrev den ut Not logged in. Run muse again to log in. och avslutade. Så du kör den två gånger, vilket är en sån där liten sak som får dig att tro att installationen gick fel.

Andra körningen startar ett OAuth device-flöde. Den skriver ut en inloggnings-URL med en kort kod, visar samma kod separat och ber dig bekräfta att de matchar innan godkännande i webbläsaren.

Sign in at this page:
  https://auth.meta.com/oauth/device/?code=XXXX-XXXX
confirm this code matches:
  XXXX-XXXX

Waiting for approval…

Och sedan bör du se följande vy: 

Skärmdump av författaren. Metas Model API-inloggningsflöde, bekräftelse av kontouppgifter innan utfärdande av inloggningsuppgifter. 

Webbläsarsidan bekräftar ditt namn, accepterar villkoren och tar ett kort. Läs prispanelen på betalningsskärmen i stället för att klicka vidare, av skäl som blir tydliga om cirka trettio sekunder.

Standardnivån tränar på din kod

Tillbaka i terminalen berättar sessionshuvudet vad du kör:

Muse Code 1.0.2
You are logged in.
Model set to muse-spark-1.3-contributor
└ Discounted tokens: your content, including inter-session messages, may be
  used for product improvement.

Läs det modellnamnet igen. Contributor-varianten, satt som standard, vid en färsk installation, utan att någon frågar.

Meta döljer det inte. Informationen står under modellnamnet, betalningsskärmen märker contributor som DEFAULT och statusraden håller muse-spark-1.3-contributor synlig medan du arbetar. 

Men bördan är omvänd jämfört med vad de flesta utvecklare förväntar sig.

Om du öppnar Muse Code inne i ett kundrepo och börjar jobba, har du redan skickat den koden till en slutpunkt som är träningsberättigad. Kontrollera statusraden innan din första prompt, inte efter.

Skärmdump av författaren. En första Muse Code-session, med standardmodellen satt till muse-spark-1.3-contributor och meddelandet om produktförbättring under.

Statusraden visar också resonemangsinsats, som för mig låg på high. Inte xhigh, varianten Artificial Analysis benchmarkade. Värt att minnas när du jämför dina resultat mot publicerade siffror.

Välja och byta nivå

Kör /model och du får en interaktiv väljare med fyra alternativ och deras priser. Dessa siffror matchar Metas egen betalningsskärm:

Contributor är ungefär 12 gånger billigare på input och 21 gånger billigare på output.

Vad som köper den rabatten är din immateriella egendom (IP). Metas formulering är "your content, including inter-session messages, may be used for product improvement", vilket täcker mer än bara koden du lämnar in.

Båda varianterna av Muse Spark 1.2 finns fortfarande i väljaren till identiska priser, vilket är viktigt för jämförelsen senare: eftersom priserna inte rör sig mellan generationer är en tokenjämförelse en kostnadsjämförelse utan något att normalisera.

Skärmdump av författaren. /model-väljaren som visar alla fyra Muse Spark-varianter med priser för cache, input och output.

För att välja bort, peka upp till muse-spark-1.3 och tryck enter. Raden "Discounted tokens" försvinner från rubriken.

För klientarbete finns ett starkare alternativ som aldrig syns i terminalen. Meta säger att de har börjat acceptera förfrågningar om noll datalagring, hanterat via sälj i stället för med en omkopplare. 

Retention och träning är separata frågor, och byråavtal behöver vanligtvis svar på båda.

Hastighetsbegränsning fungerar olika mellan nivåerna, även om källor är oense om hur. Metas utvecklarblogg beskriver contributor-nivån som begränsad av token i ett rullande 5-timmarsfönster snarare än av antal förfrågningar. Pressbevakning vid 1.2-släppet rapporterade istället en gräns på 60 förfrågningar per minut, vilket är en helt annan mekanism. Jag stötte aldrig på någon av begränsningarna över cirka 90 modellslutföranden under en eftermiddag.

Meta Model API och OpenRouter

Meta Model API är kompatibelt med OpenAI SDK, så migrering innebär att byta modell-ID och behålla din klientkod. Modell-ID:n är muse-spark-1.3 och muse-spark-1.3-contributor.

OpenRouter har den under sluggen meta/muse-spark-1.3. Det kostar dig något: OpenRouter mätte genomströmning runt 81 token per sekund mot de 182 som Artificial Analysis noterade vid direktanrop, med tillgänglighet nära 92% under de tre första dagarna. Meta är enda leverantören, så det finns ingen andra leverantör att falla över till.

Din första Muse Spark 1.3-session

Allt nedan körs mot python-humanize/humanize, pinnad till commit 823ad6096. Den är 1 676 rader källkod över 6 moduler, testsuiten kör på under en sekund och domänen kräver ingen förklaring. Inget här modifierar repot. 

Detta är läsfrågor för att se hur agenten utforskar en kodbas innan jag lämnar över något som skriver.

Två prompts för att känna av hur den läser kod, låt oss börja med den första: 

Map the dependency graph of this project and tell me which module has the most inbound imports.

Den körde två kommandon, listade projektstrukturen och skrev sedan en AST-parser i stället för att greppa efter import. Svar: i18n med 4 inkommande importer, uppdelat som i18n 4, number 2, samt filesize, lists, time och _version 1 vardera.

Jag kollade med mitt eget skript och fick andra siffror, vilket såg ut som en fälla. Mitt skript hade fel. Det räknade bara relativa importer (from ._version import ...) och missade den absoluta formen (from humanize.i18n import ...), vilket är hur större delen av paketet importerar. Modellen hanterade båda.

Den andra prompten är den värd att köra, för du kan rätta den:

List every public function in src/humanize, grouped by module, with a count per module.

Den svarade 20 totalt: filesize 1, i18n 5, lists 1, number 8, time 5. Allt korrekt. Den lade sedan till, utan att bli tillfrågad, att i18n.get_translation är publik till namnet men saknas i i18n.__all__, som bara exporterar de andra fyra. Också korrekt.

Den sessionen kostade $0.01 över 8 turer.

Resonemangsnivån Meta inte pratar om

muse --help dokumenterar detta:

--reasoning-effort <EFFORT>
    Meta reasoning effort: none|minimal|low|medium|high|xhigh|ultra
    (default: high)

Väljaren /effort i sessionen erbjuder sex av de sju, utan none. 

Skärmdump av författaren. /effort-väljaren listar sex valbara resonemangsnivåer, med high markerad som aktuell.

Båda listar en nivå kallad ultra, som inte förekommer i några Meta-annonseringar. Metas offentliga hållning är att max-resonemang "kommer strax efter att vi slutfört ytterligare säkerhetstester".

Så jag bad om det:

muse exec --model muse-spark-1.3-contributor --reasoning-effort ultra 'Reply with exactly: ok'

tbh: reasoning effort ultra is not available (gate ultra_reasoning_effort is closed); using xhigh

Det finns en namngiven feature gate, ultra_reasoning_effort, och den är stängd. Förmågan finns byggd, och strömbrytaren är av på serversidan. Det är en mer specifik bild än "pågående säkerhetstester", och den kom i ett varningsmeddelande som också innehåller ordet "tbh".

Två praktiska punkter. Klienten annonserar en nivå som backend inte serverar, både i CLI och väljaren. Och den nedgraderar tyst till xhigh med en enradig stderr, vilket i ett skript eller en CI-logg rullar förbi obemärkt. Du skulle tro att du körde en konfiguration du inte gjorde.

Sedan provade jag ett värde som inte finns någonstans i dokumentationen:

muse exec --model muse-spark-1.3-contributor --reasoning-effort max 'Reply with exactly: ok'

Ingen varning alls. Den körde och returnerade ok. Så ett odokumenterat värde passerar valideringen utan kommentar medan ett dokumenterat spärras, och du kan inte se på utdata vilken insatsnivå som faktiskt tjänade din förfrågan.

Skärmdump av författaren. Förfrågan om ultra returnerar en stängd feature gate och en tyst nedgradering till xhigh, medan det odokumenterade max passerar utan kommentar.

Om du bryr dig om vilken resonemangsnivå du kör, sätt den explicit och läs stderr. Anta inte att flaggan du skickade är flaggan som användes.

Håller Muse Spark 1.3:s effektivitetsanspråk?

Här är testet. Ta ett open source-repo, backa en riktig bugfix-commit så att testsuiten verkligen faller, och kör sedan tre koduppgifter på båda modellerna med samma prompts och samma flaggor.

Dessa är separata från den utforskande sessionen ovan. Var och en av dem skriver kod.

Att backa källkods-delen av commit 823ad6096 men behålla dess tester lämnar 6 fallande tester, och det är utgångsläget:

git checkout 823ad6096e1e5ba82ea876ce761fc2efebd76157
git show 823ad6096 -- src/humanize/filesize.py | git apply -R -
python -m pytest tests/test_filesize.py -q

Varje körning använde samma kommandostruktur, ändrade bara modell-ID och prompt:

muse exec \
  --model muse-spark-1.3-contributor \
  --reasoning-effort high \
  --no-parallel-tool-calls \
  --approval-mode never \
  'PROMPT GOES HERE'

Uppgift 1, buggfix. 

Framgång här är binär: de 6 testen passerar, eller inte. 

The test suite tests/test_filesize.py is failing. 
Fix the source code in src/humanize/ so that all tests pass. 
Do not modify any file in tests/.

Uppgift 2, liten funktion.

Tillräckligt öppen för att de två modellerna ska kunna vara oense om omfång, vilket visade sig spela roll.

Add a function called natural_list_with_limit to src/humanize/lists.py. 
It formats a list but truncates after a given number of items, appending "and N more". 
Export it from the package and add tests.

Uppgift 3, refaktorering.

Den tyngsta av de tre, berör flera filer.

src/humanize/number.py is 571 lines. 
Split it into two modules along a sensible boundary, 
update all imports across the package, and make sure the full test suite still passes.

De tre uppgifterna kördes i följd utan reset mellan, så uppgift 2 och 3 byggde på vad modellen producerade innan. Båda modellerna gick samma väg.

Tokensummor kommer från sessionsloggarna på ~/.local/share/muse/sessions/, räknat en gång per modellslutförande. Alla sex körningarna klarade sina tester.

Och skillnaderna, där negativt betyder att 1.3 använde mindre:

Att läsa resultatet ärligt

Två av tre uppgifter blev billigare, med 23% och 32% färre modellslutföranden. Det ligger i linje med Metas påstående om verktygsanrop. Sedan gick refaktoreringen åt andra hållet: 70% fler slutföranden och 38% högre kostnad.

Över alla tre kostade 1.3 totalt 12% mer än 1.2. Så effektivitetsanspråket är verkligt men uppgiftsberoende, och en enda rubriksiffra döljer det helt.

Okachad input föll på varje uppgift med 19%, 22% och 5%. Aldrig med 25%. 

Meta säger inte vilka token de räknade, och svaret ändras mycket beroende på om du menar input, output, okachad eller total.

Cacheträffar låg mellan 88% och 97% och steg med uppgiftslängd. Att rapportera råa input-token utan att skilja cache från okache är nära meningslöst, eftersom refaktorns 4,18M input i praktiken är 109k ny kontext plus 4,07M omläsningar som debiteras till en femtiondel av priset.

Varför refaktorn inte är en rak förlust

Titta på vad 1.3 faktiskt gjorde på den uppgiften innan du kallar den ineffektiv.

Den verifierade att varje flyttat block var byte-identiskt med originalet, programmatiskt. 

Den körde --doctest-modules på båda nya filerna. Den testade importupplösning från en tillfällig katalog i /tmp. Sedan flaggade den två saker ingen frågade om: att funktionen humanize.scientific skuggar den nya undermodulen, och att ett naturaldelta-doctest fallerar identiskt på det orörda trädet, så felet kan inte tillskrivas ändringen.

Muse Spark 1.2 duplicerade en hjälpfunktion för att kringgå en cirkulär import och gick vidare. 1.3 importerade den och förklarade varför det inte fanns någon cykel.

Du kan inte separera "brände fler token" från "gjorde ett grundligare jobb" med den här designen. Den ärliga utsagan är att 1.3 spenderade mer och levererade mer, och om det är en vinst beror på om du ville ha extra noggrannhet.

Funktionsuppgiften visar motsatt mönster och är den renaste illustrationen av Metas påstående om "mindre ordrik". Muse Spark 1.2 hittade på parameteralias max_items, n och max_len som ingen bad om och skrev 28 tester. 

Muse Spark 1.3 skrev en signatur med ett rimligt standardvärde och 20 tester, för 54% färre output-token.

Vad jag inte kunde kontrollera

Fyra saker, och artikeln vore oärlig utan dem.

1. Muse Code uppdaterade sig självt från 1.0.2 till 1.0.3 under resans gång, så seleverket var inte identiskt över alla sex körningar. 
2. Uppgift 2 och 3 startade från varje modells eget tidigare resultat i stället för ett byte-identiskt träd, eftersom sekvensen körs utan reset.
3. Varje cell är en enskild trial, så vanlig variation mellan körningar är omätt. 
4. Och jag körde allt på contributor-nivån, vilket är samma modell men inte samma datavillkor.

Inget av det ogiltigförklarar riktningen i resultaten. Det betyder däremot att en aggregerad skillnad på 12% är en svagare signal än tre matchande körningar per cell skulle ge.

Mose Spark 1.3 bästa praxis och felsökning

Några saker jag hade velat veta dag ett.

Prompta för samarbetsbeteendena

Muse Spark 1.3 ställer förtydligande frågor vid tvetydiga prompts, så en överspecificerad prompt stänger av en funktion du betalar för. Kontraintuitivt om du lagt två år på att lära dig front-loada varje instruktion.

Omfång spelar fortfarande roll. "Dela upp number.py" lämnar modellen gissande om gränsdragningen, importuppdateringar och vad som räknas som klart. Versionen jag faktiskt använde stavar ut alla tre:

src/humanize/number.py is 571 lines. Split it into two modules along a sensible boundary, update all imports across the package, and make sure the full test suite still passes.

En sak till värd att veta. Min refaktor-prompt sa number.py is 571 lines. Den är 567. Båda modellerna korrigerade mig utan att bli tillfrågade, och 1.3 gjorde det i sin öppningsmening. Mitt tal kom från att mäta repo-tippen i stället för den pinnade commiten.

Hålla nere kostnaderna

Lägg den stabila delen av din prompt först så att den förblir cachningsbar. Vid 88% till 97% träfffrekvens påverkar ditt cachebeteende notan mycket mer än ditt modellval gör.

De tre uppgifterna kostade totalt $0.034 på contributor. Samma arbete på standard hade gått på $0.91, en 27x-skillnad. Det är nivåbeslutet uttryckt i pengar: trettio öre mot nittio.

Går du via OpenRouter debiteras webbsök separat med $2.50 per 1 000 anrop.

När Muse Spark 1.3 är fel val

• Inga exponerade resonemangsspår. Du ser vad den beslutade, inte varför, vilket gör en dålig refaktor svårare att felsöka.
• Max-resonemang är spärrat, så konfigurationen bakom varje rubriksiffras benchmark är inte tillgänglig.
• Stängda vikter. Ingen självhostning, ingen finjustering. Metas roadmap nämner ett "Muse Spark open weights release" utan version, datum eller licens.
• En leverantör. När Metas slutpunkt degraderas finns ingenstans att routa.

Vanliga problem och lösningar

• muse: command not found efter en ren installation. Skriptet installerar till ~/.local/bin/muse, som inte ligger på PATH i varje shell.
• Not logged in. Run muse again to log in. Exakt vad det säger. Första muse avslutar, andra startar inloggningen.
• Du är på contributor-nivån och valde den inte. Det är standard. Kontrollera statusraden och kör /model innan du öppnar något proprietärt.
• ultra resonemang blir tyst xhigh. Grinden är stängd. Läs stderr i stället för att lita på flaggan du skickade.
• Muse Code uppdaterar sig mitt i sessionen. Min gick från 1.0.2 till 1.0.3 mellan körningar. Om du mäter något, pinna och notera versionen.

En sak som inte reproducerade

Det cirkulerade rapporter om att EU-användare fortfarande fick Muse Spark 1.1 efter att 1.3 släppts. Jag körde allt detta från Nederländerna och fick 1.3 hela tiden. De rapporterna gällde Meta.ai, konsumentassistenten, och tycks inte gälla Muse Code eller Model API. Två olika utrullningar.

Avslutande tankar

Metas effektivitetsanspråk stod sig på två av mina tre uppgifter och vände på den tredje, för en nettoökning på 12% i kostnad över helheten. Sidan om verktygsanrop ser solid ut med 23% och 32% minskning där 1.3 vann. Tokensidan beror helt på vilka token du räknar.

Om du redan är på Meta Model API eller i Muse Code kostar det en minut att byta modell-ID, och du kommer troligen ut före på rutinjobb. Väljer du färskt för produktionsagenter är den spärrade max-varianten och avsaknaden av resonemangsspår konkreta skäl att vänta några veckor.

Det jag faktiskt skulle agera på är inte effektivitetsnumret. Det är att Muse Code sätter dig på en träningsberättigad nivå som standard, och att en dokumenterad resonemangsnivå nedgraderas tyst när du ber om den. Båda är en rad att kontrollera och lätta att missa.

Kör jämförelsen på din egen arbetslast. Mina tre uppgifter är inte dina tre uppgifter, och spridningen mellan dem var större än skillnaden mellan modellerna.

För hela benchmark-bilden har Matts analys av Muse Spark 1.3-släppet tabellerna. För att bygga färdigheter att utvärdera modeller som detta själv, börja med vår AI Agent Fundamentals-kursspår.