Muse Spark 1.3-tutorial: een praktische gids voor developers

Meta bracht Muse Spark 1.3 uit op 2 september 2026, en de upgrade-instructies passen op één regel: wijzig de model-ID. Dat betekent dat het dezelfde endpoints, dezelfde software development kit (SDK) en dezelfde prijzen gebruikt.

Wat je volgens Meta met die éénregelaanpassing krijgt, is een model dat dezelfde taak afrondt met ongeveer 20% minder tool-calls en 25% minder tokens dan Muse Spark 1.2. Die cijfers komen uit vergelijkingen uitgevoerd door Meta’s eigen engineers, op taken die ze niet benoemen, zonder methodologiebeschrijving.

Precies zo’n claim wil ik checken vóór ik ’m herhaal. 

Dus ik installeerde Muse Code, brak expres een echt open source-project, en draaide dezelfde drie taken op beide modellen.

Om deze Muse Code-tutorial te volgen heb je een Meta-ontwikkelaarsaccount nodig, een terminal waarin je je prettig voelt, en macOS of Linux voor de Muse Code-agent. Windows-gebruikers hebben in de huidige bèta nog pech.

Kort samengevat

• Muse Spark 1.3 is Meta’s vlaggenschipmodel voor multimodale redenering, uitgebracht op 2 september 2026, met een contextvenster van 1M tokens.
• Muse Code start standaard op muse-spark-1.3-contributor, wat betekent dat Meta op jouw code traint tenzij je overschakelt. Training is opt-out, niet opt-in.
• Over 6 runs op 3 codetaken was 1.3 goedkoper op 2 en 38% duurder op de derde, voor een netto kostenstijging van 12% over het geheel.
• Modelcompletions daalden 23% en 32% op de 2 taken waarop 1.3 won, wat aansluit bij Meta’s tool-callclaim. Uncached input daalde op alle 3, maar nooit met 25%.
• Het ultra-redeneerniveau bestaat in de command-line interface (CLI) en de in-session picker, maar de backend weigert het met een benoemde feature gate.

Wat is Muse Spark 1.3?

Muse Spark 1.3 is Meta’s vlaggenschipmodel voor multimodale redenering, uitgebracht door Meta Superintelligence Labs op 2 september 2026 en gebouwd voor lange agent-sessies en coderen over grote repositories. Het houdt 1.048.576 tokens aan context vast en accepteert tekst, afbeeldingen, video en bestanden.

Zes dingen zijn veranderd ten opzichte van Muse Spark 1.2:

• Efficiëntie. Ongeveer 20% minder tool-calls en 25% minder tokens in Meta’s interne vergelijkingen.
• Samenwerking. Stelt verhelderende vragen bij vage prompts en checkt voordat het iets onomkeerbaars doet.
• Multitasken binnen één thread, zodat een bericht halverwege de flow aan de juiste taak wordt gekoppeld.
• Langere instructies volgen, met minder gemiste randvoorwaarden over meerstapswerk.
• Betere kalibratie bij onomkeerbare acties.
• Nettere codingstijl. Minder onnodige beurten, minder breedsprakigheid.

Dit ziet er allemaal goed uit, maar Meta’s gepubliceerde scorecard draait Muse Spark 1.3 op max reasoning tegenover Muse Spark 1.2 op xhigh, en max was bij lancering nog afgeschermd. 

Artificial Analysis gaf de leverbare xhigh-variant een Intelligence Index van 61 en max van 62. Dus slechts één punt verschil.

Matt Crabtree besprak al de volledige benchmarktabellen, de prijsopbouw en hoe dit zich verhoudt tot GPT-5.6 Sol en Claude Opus 5 in zijn analyse van de release van Muse Spark 1.3. Ik herhaal daar niets van. Wat volgt is wat er gebeurt als je het installeert en aan de praat krijgt.

Hoe krijg je toegang tot Muse Spark 1.3

Er zijn drie routes, en de juiste hangt af van wat je bouwt. Kies uit de tabel en spring dan naar de bijpassende sectie.

Muse Code, de terminalagent

Muse Code is Meta’s terminal-coderingsagent, in bèta voor macOS en Linux. Het is het harnas dat Muse Spark draait, en die twee versies ontwikkelen onafhankelijk, dus muse --version vertelt je niets over welk model je aanspreekt. Houd die twee los van elkaar in je hoofd.

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

Dat haalt een binaire van 230 MB op en zet die neer op ~/.local/bin/muse, en die staat niet bij iedereen op het PATH. 

Controleer daarna wat je gekregen hebt:

muse --version

Op 4 september 2026 gaf dat bij mij Muse Code 1.0.2 (1.0.2-R2040.1). 

Een wat rare melding voor een bèta, aangezien tooling van derden Muse Code nog maar weken eerder als 0.2.1 documenteerde. Pin welke versie je hebt aan de datum waarop je ’m kreeg.

Screenshot door auteur. Muse Code installeren met het script op één regel, en daarna versie 1.0.2 bevestigen op macOS.

Draai nu muse. De eerste keer printte het Not logged in. Run muse again to log in. en sloot af. Dus je draait het twee keer, het soort klein ding dat je doet denken dat de installatie kapot is.

De tweede run start een OAuth device flow. Het print een aanmeld-URL met een korte code, toont diezelfde code apart, en vraagt je te bevestigen dat ze overeenkomen voordat je in de browser goedkeurt.

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

Waiting for approval…

En dan zou je het volgende scherm moeten zien: 

Screenshot door auteur. De inlogflow van de Meta Model API, die accountgegevens bevestigt voordat er credentials worden uitgegeven. 

Aan de browserskant bevestig je je naam, ga je akkoord met de voorwaarden en wordt een kaart geaccepteerd. Lees het prijsblok op dat betaal scherm in plaats van er doorheen te klikken, om redenen die over dertig seconden duidelijk worden.

De standaardlaag traint op je code

Terug in de terminal vertelt de sessiekop wat je draait:

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.

Lees die modelnaam nog eens. De contributor-variant, als standaard ingesteld, op een schone installatie, zonder dat iemand het vraagt.

Meta verbergt het niet. De melding staat onder de modelnaam, het betalscherm labelt contributor als DEFAULT, en de statusbalk houdt muse-spark-1.3-contributor zichtbaar terwijl je werkt. 

Maar de bewijslast is omgedraaid ten opzichte van wat de meeste developers verwachten.

Als je Muse Code in een klantrepo opent en begint te werken, heb je die code al naar een training-geschikte endpoint gestuurd. Check de statusbalk vóór je eerste prompt, niet erna.

Screenshot door auteur. Een eerste Muse Code-sessie, met het standaardmodel ingesteld op muse-spark-1.3-contributor en de productverbeteringsmelding eronder.

De statusbalk toont ook de redeneringsinspanning, die bij mij op high stond. Niet xhigh, de variant die Artificial Analysis benchmarkte. Dit is het onthouden waard wanneer je jouw resultaten met gepubliceerde cijfers vergelijkt.

Lagen kiezen en wijzigen

Draai /model en je krijgt een interactieve picker met vier opties en hun tarieven. Deze cijfers komen overeen met Meta’s eigen betalscherm:

Contributor is grofweg 12 keer goedkoper op input en 21 keer goedkoper op output.

Wat die korting koopt, is jouw intellectueel eigendom (IP). Meta’s formulering is "your content, including inter-session messages, may be used for product improvement," wat meer dekt dan alleen de code die je aanlevert.

Beide Muse Spark 1.2-varianten staan nog in de picker voor identieke prijzen, wat later voor de vergelijking telt: omdat de tarieven niet bewegen tussen generaties, is een tokenvergelijking tegelijk een kostenvergelijking zonder iets te normaliseren.

Screenshot door auteur. De /model-picker met alle vier Muse Spark-varianten en cached-, input- en outputtarieven.

Om je af te melden, navigeer omhoog naar muse-spark-1.3 en druk op enter. De regel "Discounted tokens" verdwijnt uit de header.

Voor klantwerk is er een sterkere optie die nooit in de terminal verschijnt. Meta zegt dat het is begonnen zero data retention-verzoeken te accepteren, afgehandeld via sales in plaats van via een toggle. 

Retention en training zijn aparte vragen, en agencycontracten willen meestal op beide een antwoord.

Rate limiting werkt anders tussen lagen, al verschillen bronnen over hoe. Meta’s developerblog beschrijft de contributor-laag als begrensd door tokens in een rollend 5-uurvenster, in plaats van door het aantal requests. Berichtgeving bij de 1.2-lancering meldde juist een cap van 60 requests per minuut, een totaal ander mechanisme. Ik raakte geen van beide limieten, over zo’n 90 modelcompletions op één middag.

De Meta Model API en OpenRouter

De Meta Model API is compatibel met de OpenAI SDK, dus migreren betekent de model-ID wijzigen en je clientcode behouden. Model-ID’s zijn muse-spark-1.3 en muse-spark-1.3-contributor.

OpenRouter voert het onder de slug meta/muse-spark-1.3. Dat kost je wat: OpenRouter mat een throughput van rond 81 tokens per seconde tegenover de 182 die Artificial Analysis noteerde bij direct gebruik, met beschikbaarheid rond 92% gedurende de eerste drie dagen. Meta is de enige provider, dus er is geen tweede provider om naar uit te wijken.

Je eerste Muse Spark 1.3-sessie

Alles hieronder draait tegen python-humanize/humanize, gepind op commit 823ad6096. Het is 1.676 regels broncode over 6 modules, de test suite draait in minder dan een seconde, en het domein behoeft geen uitleg. Niets hier wijzigt de repo. 

Dit zijn read-only vragen om te zien hoe de agent een codebase verkent vóór ik ’m iets laat schrijven.

Twee prompts om gevoel te krijgen voor hoe het code leest; laten we met de eerste beginnen: 

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

Het draaide twee commando’s, somde de projectstructuur op, en schreef daarna een AST-parser in plaats van te greppen op import. Antwoord: i18n met 4 inkomende imports, uitgesplitst als i18n 4, number 2, en filesize, lists, time en _version elk 1.

Ik checkte met mijn eigen script en kreeg andere aantallen, wat een catch leek. Mijn script zat fout. Het telde alleen relatieve imports (from ._version import ...) en miste de absolute vorm (from humanize.i18n import ...), wat is hoe het grootste deel van dit pakket importeert. Het model kon beide aan.

De tweede prompt is degene die de moeite waard is om te draaien, omdat je ’m kunt beoordelen:

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

Het antwoordde 20 totaal: filesize 1, i18n 5, lists 1, number 8, time 5. Allemaal correct. Het voegde er ongevraagd aan toe dat i18n.get_translation publiek is qua naam, maar ontbreekt in i18n.__all__, dat alleen de andere vier exporteert. Ook correct.

Die sessie kostte $0,01 over 8 beurten.

Het redeneerniveau waar Meta niet over praat

muse --help documenteert dit:

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

De in-session /effort-picker biedt zes van die zeven, met weglating van none. 

Screenshot door auteur. De /effort-picker met zes selecteerbare redeneerniveaus, met high als current.

Beide lijsten bevatten een niveau genaamd ultra, dat in geen enkele Meta-aankondiging voorkomt. Meta’s publieke standpunt is dat max reasoning "spoedig komt zodra we aanvullende veiligheidstests afronden."

Dus ik vroeg erom:

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

Er is een benoemde feature gate, ultra_reasoning_effort, en die is dicht. De mogelijkheid is gebouwd, en de schakelaar staat server-side uit. Dat is specifieker dan "pending safety testing," en het kwam in een waarschuwing die ook het woord "tbh" bevat.

Twee praktische punten. De client adverteert een niveau dat de backend niet serveert, zowel in de CLI als in de picker. En hij degradeert stilletjes naar xhigh met één regel stderr, die in een script of CI-log onopgemerkt voorbij scrolt. Je zou geloven dat je een configuratie draaide die je niet draaide.

Daarna probeerde ik een waarde die nergens in de documentatie staat:

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

Geen enkele waarschuwing. Het draaide en retourneerde ok. Dus een ongedocumenteerde waarde slaagt zonder commentaar terwijl een gedocumenteerde wordt afgeschermd, en je kunt niet aan de output zien welk effort-niveau je request daadwerkelijk heeft bediend.

Screenshot door auteur. Ultra aanvragen geeft een gesloten feature gate en een stille downgrade naar xhigh, terwijl de ongedocumenteerde max zonder commentaar doorloopt.

Als het je uitmaakt op welk redeneerniveau je draait, stel het expliciet in en lees stderr. Ga er niet van uit dat de flag die je meegaf ook is gebruikt.

Houdt de efficiëntieclaim van Muse Spark 1.3 stand?

Hier is de test. Neem één open source-repo, zet een echte bugfix-commit terug zodat een testsuite echt faalt, en draai dan drie codetaken op beide modellen met dezelfde prompts en dezelfde flags.

Deze staan los van de verkennende sessie hierboven. Elk ervan schrijft code.

Door de bronhelft van commit 823ad6096 terug te draaien maar de tests te laten staan, blijven er 6 falende tests over, en dat is de beginsituatie:

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

Elke run gebruikte dezelfde commandovorm, alleen de model-ID en de prompt verschilden:

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

Taak 1, bugfix. 

Succes is hier binair: de 6 tests slagen, of niet. 

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/.

Taak 2, kleine feature.

Open genoeg dat de twee modellen van mening konden verschillen over de scope, wat uiteindelijk uitmaakte.

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.

Taak 3, refactor.

De zwaarste van de drie, die meerdere bestanden raakt.

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 drie taken draaiden achter elkaar zonder reset ertussen, dus taken 2 en 3 bouwden voort op wat het model eerder had geproduceerd. Beide modellen liepen hetzelfde pad.

Tokentellingen komen uit de sessielogs op ~/.local/share/muse/sessions/, eenmaal geteld per modelcompletion. Alle zes runs slaagden voor hun tests.

En de delta’s, waar negatief betekent dat 1.3 minder gebruikte:

De uitkomst eerlijk lezen

Twee van de drie taken waren goedkoper, met 23% en 32% minder modelcompletions. Dat zit precies op Meta’s tool-callclaim. Daarna ging de refactor de andere kant op: 70% meer completions en 38% meer kosten.

Over alle drie kostte 1.3 in totaal 12% meer dan 1.2. Dus de efficiëntieclaim is echt maar taakafhankelijk, en één headlinepercentage verbergt dat volledig.

Uncached input daalde op elke taak met 19%, 22% en 5%. Nooit met 25%. 

Meta zegt niet welke tokens het telde, en het antwoord verandert flink afhankelijk van of je input, output, uncached of totaal bedoelt.

Cache-hitratios lagen tussen 88% en 97% en stegen met de taaklengte. Rauwe inputtokens rapporteren zonder cached en uncached te scheiden is bijna betekenisloos, aangezien de 4,18M input van de refactor in feite 109k nieuwe context is plus 4,07M herlezingen die tegen een vijftigste tarief worden gefactureerd.

Waarom de refactor geen zuivere verliespost is

Kijk naar wat 1.3 feitelijk deed op die taak vóór je het inefficiënt noemt.

Het verifieerde dat elk verplaatst blok byte-identiek was aan het origineel, programmatisch. 

Het draaide --doctest-modules op beide nieuwe bestanden. Het testte importresolutie vanuit een wegwerpmappenstructuur in /tmp. Daarna markeerde het twee dingen waar niemand om vroeg: dat de functie humanize.scientific de nieuwe submodule overschaduwt, en dat een naturaldelta-doctest identiek faalt op de ongerepte tree, dus dat de failure niet aan de wijziging te wijten is.

Muse Spark 1.2 dupliceerde een helperfunctie om een circulaire import te ontwijken en ging verder. 1.3 importeerde ’m en legde uit waarom er geen cyclus was.

Je kunt "verbruikte meer tokens" niet los zien van "deed grondiger werk" met dit ontwerp. De eerlijke uitspraak is dat 1.3 meer besteedde en meer leverde, en of dat winst is hangt af van of je die extra grondigheid wilde.

De feature-taak laat het omgekeerde patroon zien en is de duidelijkste illustratie van Meta’s claim "minder breedsprakig". Muse Spark 1.2 verzon parameteraliassen max_items, n en max_len waar niemand om vroeg en schreef 28 tests. 

Muse Spark 1.3 schreef één signature met een zinnige default en 20 tests, voor 54% minder outputtokens.

Wat ik niet kon beheersen

Vier dingen, en het artikel zou oneerlijk zijn zonder ze te noemen.

1. Muse Code werkte zichzelf halverwege bij van 1.0.2 naar 1.0.3, dus het harnas was niet identiek over alle zes runs. 
2. Taken 2 en 3 startten vanaf de eigen eerdere output van elk model in plaats van een byte-identieke tree, omdat de reeks zonder resets draait.
3. Elke cel is één trial, dus normale run-tot-run-variatie is ongemeten. 
4. En ik draaide alles op de contributor-laag, wat hetzelfde model is maar niet dezelfde datavoorwaarden.

Niets daarvan maakt de richting van de resultaten ongeldig. Het betekent wel dat een verschil van 12% in totaal een zwakker signaal is dan drie overeenkomende runs per cel zouden geven.

Mose Spark 1.3 best practices en troubleshooting

Een paar dingen die ik graag op dag één had geweten.

Prompten voor de samenwerkingsgedragingen

Muse Spark 1.3 stelt verhelderende vragen bij dubbelzinnige prompts, dus een overgespecificeerde prompt schakelt een feature uit waar je voor betaalt. Contra-intuïtief als je twee jaar hebt geleerd om elke instructie vooraf te laden.

Scope blijft wel belangrijk. "Split number.py op" laat het model gissen naar de grens, de importupdates en wat telt als klaar. De versie die ik daadwerkelijk gebruikte, benoemt alle drie:

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.

Nog iets om te weten. Mijn refactorprompt zei number.py is 571 lines. Het is 567. Beide modellen corrigeerden me zonder dat ik erom vroeg, en 1.3 deed dat in de openingszin. Mijn aantal kwam doordat ik de repo-tip mat in plaats van de gepinde commit.

Kosten laag houden

Zet het stabiele deel van je prompt vooraan zodat het cachebaar blijft. Bij 88% tot 97% hitrates bepaalt je cachegedrag de rekening veel meer dan je modelkeuze.

De drie taken kostten in totaal $0,034 op contributor. Hetzelfde werk op standaard zou $0,91 zijn geweest, een verschil van 27x. Dat is de laagnorm in geld: drie cent tegenover negentig.

Als je via OpenRouter gaat, wordt web search afzonderlijk afgerekend tegen $2,50 per 1.000 calls.

Wanneer Muse Spark 1.3 de verkeerde keuze is

• Geen blootgelegde redeneertraces. Je ziet wat het besloot, niet waarom, wat een slechte refactor moeilijker te debuggen maakt.
• Max reasoning is afgeschermd, dus de configuratie achter elk headline-benchmarkcijfer ligt buiten bereik.
• Gesloten weights. Geen self-hosting, geen fine-tuning. Meta’s roadmap noemt een "Muse Spark open weights release" zonder versie, datum of licentie.
• Eén provider. Als Meta’s endpoint degradeert, is er nergens heen te routen.

Veelvoorkomende problemen en fixes

• muse: command not found na een schone installatie. Het script installeert naar ~/.local/bin/muse, wat niet in elke shell op PATH staat.
• Not logged in. Run muse again to log in. Precies wat er staat. De eerste muse sluit af, de tweede start de aanmelding.
• Je zit op de contributor-laag en hebt niet gekozen. Dat is de standaard. Check de statusbalk en draai /model voordat je iets eigendomsrechtelijks opent.
• ultra reasoning wordt stilzwijgend xhigh. De gate is dicht. Lees stderr in plaats van te vertrouwen op de meegegeven flag.
• Muse Code werkt zichzelf bij midden in een sessie. Bij mij ging het van 1.0.2 naar 1.0.3 tussen runs. Als je iets meet, pin en noteer de versie.

Eén ding dat niet reproduceerde

Er gingen berichten rond dat EU-gebruikers nog Muse Spark 1.1 kregen na de 1.3-release. Ik draaide dit allemaal vanuit Nederland en kreeg overal 1.3. Die berichten betroffen Meta.ai, de consumentenassistent, en lijken niet te gelden voor Muse Code of de Model API. Twee verschillende uitroltrajecten.

Slotgedachten

Meta’s efficiëntieclaim hield stand op twee van mijn drie taken en draaide om op de derde, voor een netto kostenstijging van 12% over het geheel. De tool-callkant van de claim lijkt solide met reducties van 23% en 32% waar 1.3 won. De tokenkant hangt volledig af van welke tokens je telt.

Als je al op de Meta Model API of in Muse Code zit, kost het wisselen van model-ID een minuut, en kom je waarschijnlijk beter uit op routinetaken. Als je vers kiest voor productieagents, zijn de afgeschermde max-variant en de ontbrekende redeneertraces concrete redenen om een paar weken te wachten.

Waar ik in de praktijk iets mee zou doen, is niet het efficiëntiecijfer. Het is dat Muse Code je standaard op een trainingsgeschikte laag zet, en dat een gedocumenteerd redeneerniveau stilzwijgend degradeert als je erom vraagt. Beide zijn één regel om te checken en makkelijk te missen.

Draai de vergelijking op je eigen workload. Mijn drie taken zijn de jouwe niet, en de spreiding ertussen was groter dan het verschil tussen de modellen.

Voor het volledige benchmarkbeeld heeft Matt’s analyse van de release van Muse Spark 1.3 de tabellen. Wil je de skills bouwen om dit soort modellen zelf te beoordelen, begin dan met onze AI Agent Fundamentals skill track.