Tutorial Muse Spark 1.3: Ghid practic pentru dezvoltatori

Meta a lansat Muse Spark 1.3 pe 2 septembrie 2026, iar instrucțiunile de upgrade încap într-o singură linie: schimbă ID-ul modelului. Asta înseamnă că folosește aceleași endpoint-uri, același SDK și aceleași prețuri.

Ce obții din acea editare de o linie, conform Meta, este un model care termină aceeași sarcină cu aproximativ 20% mai puține apeluri de tool și 25% mai puțini tokeni decât Muse Spark 1.2. Procentele vin din comparații rulate de inginerii Meta, pe sarcini neprecizate și fără descrierea metodologiei.

Exact genul de afirmație pe care vreau s-o verific înainte s-o repet. 

Așa că am instalat Muse Code, am stricat intenționat un proiect open source real și am rulat aceleași trei sarcini pe ambele modele.

Ca să parcurgi acest tutorial Muse Code, ai nevoie de un cont de dezvoltator Meta, un terminal în care te simți confortabil și macOS sau Linux pentru agentul Muse Code. Utilizatorii Windows încă nu au noroc în beta-ul actual.

Pe scurt

• Muse Spark 1.3 este modelul de raționare multimodal de vârf al Meta, lansat pe 2 septembrie 2026, cu o fereastră de context de 1M tokeni.
• Muse Code te pornește implicit pe muse-spark-1.3-contributor, ceea ce înseamnă că Meta îți folosește codul pentru antrenare dacă nu schimbi. Antrenarea e opt-out, nu opt-in.
• Pe 6 rulari în 3 sarcini de coding, 1.3 a fost mai ieftin în 2 și cu 38% mai scump în a treia, pentru un plus net de 12% la cost pe set.
• Completările modelului au scăzut cu 23% și 32% pe cele 2 sarcini unde 1.3 a câștigat, aliniat cu afirmația Meta privind apelurile de tool. Inputul necachuit a scăzut pe toate 3, dar niciodată cu 25%.
• Nivelul de raționare ultra există în CLI și în selectorul din sesiune, dar backend-ul îl refuză cu un feature gate numit.

Ce este Muse Spark 1.3?

Muse Spark 1.3 este modelul multimodal de raționare de vârf al Meta, lansat de Meta Superintelligence Labs pe 2 septembrie 2026 și construit pentru sesiuni agentice lungi și coding pe repo-uri mari. Suportă 1.048.576 tokeni de context și acceptă text, imagini, video și fișiere.

Șase lucruri s-au schimbat față de Muse Spark 1.2:

• Eficiență. Aproximativ 20% mai puține apeluri de tool și 25% mai puțini tokeni în comparațiile interne Meta.
• Colaborare. Pune întrebări de clarificare la prompturi vagi și verifică înainte de acțiuni consecvente.
• Multitasking în același fir, astfel că un mesaj trimis la mijlocul fluxului se atașează sarcinii intenționate.
• Urmărire mai bună a instrucțiunilor lungi, cu mai puține constrângeri pierdute în munca în mai mulți pași.
• Calibrare mai bună pentru acțiuni ireversibile.
• Stil de cod mai curat. Mai puține interacțiuni inutile, mai puțină verbositate.

Toate arată bine, dar raportul publicat de Meta rulează Muse Spark 1.3 la max raționare, față de Muse Spark 1.2 la xhigh, iar max era încă limitat la lansare. 

Artificial Analysis a punctat varianta xhigh livrată la un Intelligence Index de 61 și max la 62. Deci o singură unitate diferență.

Matt Crabtree a acoperit deja tabelele complete de benchmark, defalcarea prețurilor și comparația cu GPT-5.6 Sol și Claude Opus 5 în analiza lansării Muse Spark 1.3. Nu repet nimic din acelea. Mai jos este ce se întâmplă când instalezi lucrul și îl pui la treabă.

Cum accesezi Muse Spark 1.3

Există trei rute, iar alegerea depinde de ce construiești. Alege din tabel, apoi sari la secțiunea corespunzătoare.

Muse Code, agentul de terminal

Muse Code este agentul de coding în terminal al Meta, în beta pentru macOS și Linux. Este hamul care rulează Muse Spark, iar cele două au versiuni independente, deci muse --version nu-ți spune nimic despre ce model folosești. Ține-le separat în minte.

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

Asta descarcă un binar de 230 MB și îl plasează la ~/.local/bin/muse, care nu e în PATH pentru toată lumea. 

Apoi verifică ce ai obținut:

muse --version

Pe 4 septembrie 2026 mi-a dat Muse Code 1.0.2 (1.0.2-R2040.1). 

Un lucru ușor ciudat pentru un beta, din moment ce tool-uri terțe documentau Muse Code ca 0.2.1 cu doar câteva săptămâni înainte. Leagă orice versiune primești de data la care ai primit-o.

Captură de ecran de autor. Instalarea Muse Code cu scriptul de o linie, apoi confirmarea versiunii 1.0.2 pe macOS.

Acum rulează muse. Prima dată, a afișat Not logged in. Run muse again to log in. și a ieșit. Deci îl rulezi de două ori, genul acela de detaliu mic care te face să crezi că instalarea a eșuat.

A doua rulare pornește un flux OAuth device. Afișează un URL de logare care conține un cod scurt, arată același cod separat și îți cere să confirmi că se potrivesc înainte de aprobare în browser.

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

Waiting for approval…

Și apoi ar trebui să vezi următoarea vizualizare: 

Captură de ecran de autor. Fluxul de logare Meta Model API, confirmarea detaliilor contului înainte de emiterea credențialelor. 

Partea din browser îți confirmă numele, acceptă termenii și ia un card. Citește panoul de prețuri în acel ecran de plată în loc să dai click rapid mai departe, din motive care devin clare în cam treizeci de secunde.

Nivelul implicit îți antrenează codul

Înapoi în terminal, antetul sesiunii îți spune ce rulezi:

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.

Citește încă o dată numele modelului. Varianta contributor, setată ca implicită, pe o instalare proaspătă, fără să te întrebe nimeni.

Meta nu ascunde asta. Declarația stă sub numele modelului, ecranul de plată etichetează contributor ca DEFAULT, iar bara de stare păstrează muse-spark-1.3-contributor vizibil în timp ce lucrezi. 

Dar povara e inversată față de ce se așteaptă majoritatea dezvoltatorilor.

Dacă deschizi Muse Code într-un repo de client și începi să lucrezi, ai trimis deja acel cod către un endpoint eligibil pentru antrenare. Verifică bara de stare înainte de primul prompt, nu după.

Captură de ecran de autor. O primă sesiune Muse Code, cu modelul implicit setat la muse-spark-1.3-contributor și declarația privind îmbunătățirea produsului dedesubt.

Bara de stare afișează și efortul de raționare, care la mine era high. Nu xhigh, varianta pe care a făcut benchmark Artificial Analysis. Merită ținut minte când îți compari rezultatele cu orice număr publicat.

Alegerea și schimbarea nivelurilor

Rulează /model și primești un selector interactiv cu patru opțiuni și tarifele lor. Aceste cifre se potrivesc cu ecranul de plată Meta:

Contributor e cam de 12 ori mai ieftin la input și de 21 de ori la output.

Ce cumpără acel discount este proprietatea ta intelectuală (IP). Formularea Meta este „conținutul tău, inclusiv mesajele între sesiuni, poate fi folosit pentru îmbunătățirea produsului”, ceea ce acoperă mai mult decât codul pe care îl predai.

Ambele variante Muse Spark 1.2 sunt încă în selector la prețuri identice, ceea ce contează pentru comparația de mai târziu: cum tarifele nu se mișcă între generații, o comparație de tokeni este o comparație de cost fără nimic de normalizat.

Captură de ecran de autor. Selectorul /model afișând toate cele patru variante Muse Spark cu tarife cached, input și output.

Pentru a renunța, mută săgeata pe muse-spark-1.3 și apasă Enter. Linia „Discounted tokens” dispare din antet.

Pentru lucrul cu clienți, există o opțiune mai puternică ce nu apare în terminal. Meta spune că a început să accepte cereri de retenție zero de date, gestionate prin vânzări, nu printr-un comutator. 

Retenția și antrenarea sunt chestiuni separate, iar contractele de agenție au de obicei nevoie de răspuns la ambele.

Limitarea ratei funcționează diferit între niveluri, deși sursele nu cad de acord cum. Blogul pentru dezvoltatori Meta descrie nivelul contributor ca fiind limitat de tokeni într-o fereastră rulantă de 5 ore, nu de numărul de cereri. Presa la lansarea 1.2 a raportat în schimb o limită de 60 de cereri pe minut, un mecanism cu totul diferit. Eu nu am atins niciuna dintre limite în aproximativ 90 de completări de model într-o după-amiază.

Meta Model API și OpenRouter

Meta Model API este compatibil cu SDK-ul OpenAI, deci migrarea înseamnă schimbarea ID-ului de model și păstrarea codului client. ID-urile de model sunt muse-spark-1.3 și muse-spark-1.3-contributor.

OpenRouter îl are sub slug-ul meta/muse-spark-1.3. Asta are un cost: OpenRouter a măsurat un throughput de aproximativ 81 tokeni pe secundă față de 182 înregistrat de Artificial Analysis la acces direct, cu disponibilitate de circa 92% în primele trei zile. Meta e singurul furnizor, deci nu există un al doilea furnizor pentru failover.

Prima ta sesiune Muse Spark 1.3

Tot ce urmează rulează pe python-humanize/humanize, fixat la commit-ul 823ad6096. Are 1.676 linii de sursă în 6 module, testele rulează sub o secundă, iar domeniul nu necesită explicații. Nimic de aici nu modifică repo-ul. 

Acestea sunt întrebări read-only ca să văd cum explorează agentul o bază de cod înainte să-i dau ceva care scrie.

Două prompturi ca să-ți faci o idee despre cum citește codul; începem cu primul: 

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

A rulat două comenzi, a listat structura proiectului, apoi a scris un parser AST în loc să caute cu grep după import. Răspuns: i18n cu 4 importuri inbound, defalcate ca i18n 4, number 2, iar filesize, lists, time și _version câte 1.

Am verificat cu propriul script și am obținut alte numere, părea să fie o hibă. Scriptul meu era greșit. Număra doar importurile relative (from ._version import ...) și le rata pe cele absolute (from humanize.i18n import ...), forma predominantă în acest pachet. Modelul le-a gestionat pe ambele.

Al doilea prompt merită rulat pentru că îl poți nota:

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

A răspuns 20 în total: filesize 1, i18n 5, lists 1, number 8, time 5. Toate corecte. A adăugat apoi, necerut, că i18n.get_translation este publică după nume dar absentă din i18n.__all__, care exportă doar celelalte patru. De asemenea corect.

Acea sesiune a costat 0,01 $ pe 8 ture.

Nivelul de raționare despre care Meta nu vorbește

muse --help documentează asta:

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

Selectorul din sesiune /effort oferă șase din cele șapte, fără none. 

Captură de ecran de autor. Selectorul /effort cu șase niveluri de raționare selectabile, cu high marcat curent.

Ambele liste includ un nivel numit ultra, care nu apare în nicio comunicare Meta. Poziția publică a Meta este că max reasoning „vine la scurt timp după ce terminăm testarea suplimentară de siguranță”.

Așa că am cerut-o:

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

Există un feature gate numit, ultra_reasoning_effort, și este închis. Capabilitatea e construită, iar întrerupătorul e oprit server-side. E o imagine mai specifică decât „în așteptarea testelor de siguranță” și a venit într-un avertisment care conține și „tbh”.

Două puncte practice. Clientul face reclamă unui nivel pe care backend-ul nu îl servește, atât în CLI cât și în selector. Și face downgrade în tăcere la xhigh cu o singură linie pe stderr, care într-un script sau într-un log CI trece neobservată. Ai crede că rulezi o configurație pe care n-o rulezi.

Apoi am încercat o valoare care nu apare nicăieri în documentație:

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

Fără niciun avertisment. A rulat și a returnat ok. Deci o valoare nedocumentată trece validarea fără comentarii, în timp ce una documentată este blocată, și nu poți spune din output ce nivel de efort ți-a servit de fapt cererea.

Captură de ecran de autor. Cererea pentru ultra returnează un feature gate închis și un downgrade silențios la xhigh, în timp ce max, nedocumentat, trece fără comentarii.

Dacă îți pasă ce nivel de raționare rulezi, setează-l explicit și citește stderr. Nu presupune că flagul pe care l-ai trecut este flagul folosit.

Rezistă afirmația de eficiență a Muse Spark 1.3?

Iată testul. Ieia un repo open source, revine un commit real de bugfix ca să pice sincer o suită de teste, apoi rulezi trei sarcini de coding pe ambele modele cu aceleași prompturi și aceleași flaguri.

Acestea sunt separate de sesiunea exploratorie de mai sus. Fiecare dintre ele scrie cod.

Revenirea părții de sursă a commit-ului 823ad6096 păstrând testele lasă 6 teste picate, și acesta e stadiul de pornire:

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

Fiecare rulare a folosit aceeași formă de comandă, schimbând doar ID-ul modelului și promptul:

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

Sarcina 1, bug fix. 

Succesul e binar: cele 6 teste trec sau nu. 

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

Sarcina 2, funcționalitate mică.

Destul de deschisă încât cele două modele să nu fie de acord pe scope, ceea ce s-a dovedit important.

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.

Sarcina 3, refactor.

Cea mai grea dintre cele trei, atinge mai multe fișiere.

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.

Cele trei sarcini au rulat în secvență fără reset între ele, deci sarcinile 2 și 3 au construit peste ce a produs modelul anterior. Ambele modele au mers pe același traseu.

Numărătorile de tokeni vin din jurnalele de sesiune de la ~/.local/share/muse/sessions/, numărate o dată per completare de model. Toate cele șase rulari și-au trecut testele.

Și diferențele, unde negativ înseamnă că 1.3 a folosit mai puțin:

O lectură onestă a rezultatului

Două din trei sarcini au ieșit mai ieftin, cu 23% și 32% mai puține completări de model. Asta bate cu afirmația Meta despre apeluri de tool. Apoi refactorul a mers invers: cu 70% mai multe completări și 38% mai mult cost.

Pe toate trei, 1.3 a costat cu 12% mai mult decât 1.2. Deci afirmația de eficiență este reală, dar dependentă de sarcină, iar un singur procent din titlu ascunde complet acest lucru.

Inputul necachuit a scăzut la fiecare sarcină cu 19%, 22% și 5%. Niciodată cu 25%. 

Meta nu spune ce tokeni a numărat, iar răspunsul se schimbă mult în funcție de faptul că te referi la input, output, necachuit sau total.

Ratele de hit în cache au fost între 88% și 97% și au crescut cu lungimea sarcinii. Raportarea brută a tokenilor de input fără a separa cached de necachuit ar fi aproape lipsită de sens, din moment ce cei 4,18M input ai refactorului sunt de fapt 109k context nou plus 4,07M recitiri taxate la o cincizecime din tarif.

De ce refactorul nu e o pierdere curată

Uită-te la ce a făcut de fapt 1.3 pe acea sarcină înainte să-l numești ineficient.

A verificat programatic că fiecare bloc mutat este identic la nivel de byte cu originalul. 

A rulat --doctest-modules pe ambele fișiere noi. A testat rezolvarea importurilor dintr-un director temporar în /tmp. Apoi a semnalat două lucruri pe care nu le-a cerut nimeni: că funcția humanize.scientific umbrește noul submodul și că un doctest naturaldelta pică identic pe arborele neatins, deci eșecul nu e atribuibil schimbării.

Muse Spark 1.2 a duplicat o funcție helper ca să evite un import circular și a mers mai departe. 1.3 a importat-o și a explicat de ce nu există ciclu.

Nu poți separa „a ars mai mulți tokeni” de „a făcut o treabă mai riguroasă” cu acest design. Afirmația onestă este că 1.3 a cheltuit mai mult și a livrat mai mult, iar dacă e un câștig depinde dacă voiai rigoarea în plus.

Sarcina de funcționalitate arată modelul opus și este cea mai clară ilustrare a afirmației Meta „mai puțin verbos”. Muse Spark 1.2 a inventat aliasuri de parametri max_items, n și max_len pe care nu le-a cerut nimeni și a scris 28 de teste. 

Muse Spark 1.3 a scris o singură semnătură cu un default rezonabil și 20 de teste, cu 54% mai puțini tokeni de output.

Ce n-am putut controla

Patru lucruri, iar articolul ar fi necinstit fără ele.

1. Muse Code s-a actualizat singur de la 1.0.2 la 1.0.3 pe parcurs, deci hamul nu a fost identic în toate cele șase rulari. 
2. Sarcinile 2 și 3 au pornit de la outputul propriu al fiecărui model, nu de la un arbore identic la byte, deoarece secvența rulează fără reseturi.
3. Fiecare celulă este un singur trial, deci variația normală între rulări nu e măsurată. 
4. Și am rulat totul pe nivelul contributor, care e același model dar nu aceiași termeni de date.

Nimic din acestea nu invalidează direcția rezultatelor. Înseamnă însă că o diferență agregată de 12% e un semnal mai slab decât ar da trei rulari potrivite pe celulă.

Cele mai bune practici și depanare pentru Mose Spark 1.3

Câteva lucruri pe care aș fi vrut să le știu din prima zi.

Prompturi pentru comportamentele de colaborare

Muse Spark 1.3 pune întrebări de clarificare la prompturi ambigue, deci un prompt supra-specific oprește o funcție pentru care plătești. Contraintuitiv dacă ai petrecut doi ani învățând să pui toate instrucțiunile în față.

Totuși, scope-ul contează. „Împarte number.py” lasă modelului de ghicit granița, update-urile de import și ce înseamnă „gata”. Versiunea pe care am folosit-o eu explică toate trei:

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.

Încă un detaliu util. Promptul meu de refactor spunea number.py is 571 lines. Are 567. Ambele modele m-au corectat fără să fie întrebate, iar 1.3 a făcut-o în prima propoziție. Numărul meu venea din măsurarea vârfului repo-ului în locul commit-ului fixat.

Cum ții costurile jos

Pune partea stabilă a promptului la început ca să rămână cacheabilă. La rate de hit de 88% până la 97%, comportamentul cache-ului îți mută factura mult mai mult decât alegerea modelului.

Cele trei sarcini au costat în total 0,034 $ pe contributor. Aceeași muncă pe standard ar fi fost 0,91 $, adică de 27 de ori mai mult. Asta e decizia de nivel exprimată în bani: trei cenți față de nouăzeci.

Dacă treci prin OpenRouter, căutarea pe web se facturează separat la 2,50 $ per 1.000 de apeluri.

Când Muse Spark 1.3 nu e alegerea potrivită

• Fără urme de raționare expuse. Vezi ce a decis, nu de ce, ceea ce face un refactor greșit mai greu de depănat.
• Max reasoning e limitat, deci configurația din spatele fiecărui număr de benchmark din titlu nu e disponibilă.
• Greutăți închise. Fără self-hosting, fără fine-tuning. Roadmap-ul Meta menționează un „Muse Spark open weights release” fără versiune, dată sau licență.
• Un singur furnizor. Când endpoint-ul Meta se degradează, nu ai unde să redirecționezi.

Probleme comune și remedii

• muse: command not found după o instalare curată. Scriptul instalează la ~/.local/bin/muse, care nu e pe PATH în orice shell.
• Not logged in. Run muse again to log in. Exact ce spune. Primul muse iese, al doilea pornește logarea.
• Ești pe nivelul contributor și nu l-ai ales. E implicitul. Verifică bara de stare și rulează /model înainte să deschizi ceva proprietar.
• ultra devine în tăcere xhigh. Gate-ul e închis. Citește stderr, nu te baza pe flagul pe care l-ai trecut.
• Muse Code se actualizează singur în mijlocul sesiunii. La mine a trecut de la 1.0.2 la 1.0.3 între rulari. Dacă măsori ceva, fixează și notează versiunea.

Un lucru care nu s-a reprodus

Au circulat rapoarte că utilizatorii din UE erau încă serviți cu Muse Spark 1.1 după ce 1.3 a fost lansat. Eu am rulat totul din Țările de Jos și am avut 1.3 peste tot. Acele rapoarte vizau Meta.ai, asistentul pentru consumatori, și nu par să se aplice la Muse Code sau Model API. Două rollout-uri diferite.

Gânduri finale

Afirmația de eficiență a Meta s-a susținut pe două din cele trei sarcini ale mele și s-a inversat pe a treia, pentru un plus net de 12% la cost pe set. Partea cu apelurile de tool pare solidă, cu reduceri de 23% și 32%, acolo unde 1.3 a câștigat. Partea cu tokenii depinde complet de ce tokeni numeri.

Dacă deja ești pe Meta Model API sau în Muse Code, schimbarea ID-ului modelului te costă un minut și probabil vei ieși în față pe munca de rutină. Dacă alegi de la zero pentru agenți de producție, varianta max blocată și lipsa urmelor de raționare sunt motive concrete să aștepți câteva săptămâni.

Lucrul pe care chiar l-aș aplica nu e procentul de eficiență. E faptul că Muse Code te pune implicit pe un nivel eligibil pentru antrenare și că un nivel de raționare documentat face downgrade în tăcere când îl ceri. Ambele sunt o linie de verificat și ușor de ratat.

Rulează comparația pe propriul tău workload. Cele trei sarcini ale mele nu sunt cele trei ale tale, iar variația dintre ele a fost mai mare decât diferența dintre modele.

Pentru imaginea completă a benchmark-urilor, articolul lui Matt, analiza lansării Muse Spark 1.3, are tabelele. Ca să-ți construiești abilitățile de a evalua singur modele ca acesta, începe cu AI Agent Fundamentals.