Tutorial Muse Spark 1.3: guida pratica per sviluppatori

Meta ha rilasciato Muse Spark 1.3 il 2 settembre 2026 e le istruzioni di upgrade stanno in una riga: cambia l’ID del modello. Significa che usa gli stessi endpoint, lo stesso software development kit (SDK) e gli stessi prezzi.

Secondo Meta, quella modifica in una riga ti dà un modello che completa lo stesso task con circa il 20% di chiamate agli strumenti in meno e il 25% di token in meno rispetto a Muse Spark 1.2. Queste cifre provengono da confronti eseguiti da gli stessi ingegneri di Meta, su task non specificati e senza descrizione della metodologia.

Questo è esattamente il tipo di affermazione che voglio verificare prima di ripeterla. 

Quindi ho installato Muse Code, ho rotto di proposito un vero progetto open source e ho eseguito gli stessi tre task su entrambi i modelli.

Per seguire questo tutorial su Muse Code, ti serviranno un account sviluppatore Meta, un terminale in cui ti trovi a tuo agio e macOS o Linux per l’agente Muse Code. Gli utenti Windows, nella beta attuale, non sono ancora coperti.

In breve

• Muse Spark 1.3 è il modello di ragionamento multimodale di punta di Meta, rilasciato il 2 settembre 2026, con una finestra di contesto da 1M di token.
• Muse Code ti avvia di default su muse-spark-1.3-contributor, il che significa che Meta addestra sul tuo codice a meno che tu non cambi. L’addestramento è opt-out, non opt-in.
• Su 6 esecuzioni di 3 task di coding, la 1.3 è stata più economica su 2 e il 38% più costosa sul terzo, per un aumento netto del 12% sul set.
• Le completion del modello sono diminuite del 23% e del 32% sui 2 task in cui 1.3 ha vinto, in linea con l’affermazione di Meta sulle tool-call. L’input non in cache è sceso su tutti e 3, ma mai del 25%.
• Il livello di ragionamento ultra esiste nella CLI e nel selettore in sessione, ma il backend lo rifiuta con una feature gate nominata.

Cos’è Muse Spark 1.3?

Muse Spark 1.3 è il modello di ragionamento multimodale di punta di Meta, rilasciato da Meta Superintelligence Labs il 2 settembre 2026 e progettato per lunghe sessioni agentiche e per il coding su repository di grandi dimensioni. Supporta 1.048.576 token di contesto e accetta testo, immagini, video e file.

Sei cambiamenti rispetto a Muse Spark 1.2:

• Efficienza. Circa il 20% di tool-call in meno e il 25% di token in meno nei confronti interni di Meta.
• Collaborazione. Fa domande di chiarimento su prompt vaghi e chiede conferma prima di azioni conseguenti.
• Multitasking all’interno di un thread, così un messaggio inviato a metà flusso si aggancia al task che intendevi.
• Seguire istruzioni lunghe, con meno vincoli persi in lavori multi-step.
• Migliore calibrazione sulle azioni irreversibili.
• Stile di coding più pulito. Meno passaggi inutili, meno verbosità.

Tutto bene, ma il punteggio pubblicato da Meta esegue Muse Spark 1.3 a max reasoning contro Muse Spark 1.2 a xhigh, e max al lancio era comunque gated. 

Artificial Analysis ha assegnato alla variante xhigh in distribuzione un Intelligence Index di 61 e a max di 62. Quindi solo un punto di differenza.

Matt Crabtree ha già coperto le tabelle complete dei benchmark, il dettaglio dei prezzi e come si confronta con GPT-5.6 Sol e Claude Opus 5 nella sua analisi del rilascio di Muse Spark 1.3. Non ripeterò nulla di tutto ciò. Quello che segue è cosa succede quando installi la cosa e la fai funzionare.

Come accedere a Muse Spark 1.3

Esistono tre strade e quella giusta dipende da cosa stai costruendo. Scegli dalla tabella e poi salta alla sezione corrispondente.

Muse Code, l’agente da terminale

Muse Code è l’agente di coding da terminale di Meta, in beta per macOS e Linux. È l’imbracatura che esegue Muse Spark, e i due hanno versioning indipendente, quindi muse --version non ti dice nulla su quale modello stai usando. Tienilo distinto a mente.

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

Scarica un binario da 230 MB e lo posiziona in ~/.local/bin/muse, che non è su PATH per tutti. 

Poi verifica cosa hai ottenuto:

muse --version

Il 4 settembre 2026 mi ha restituito Muse Code 1.0.2 (1.0.2-R2040.1). 

Un messaggio un po’ strano per una beta, visto che tool di terze parti documentavano Muse Code come 0.2.1 solo poche settimane prima. Associa qualsiasi versione ottieni alla data in cui l’hai ottenuta.

Screenshot dell’autore. Installazione di Muse Code con lo script a riga singola, poi conferma della versione 1.0.2 su macOS.

Ora esegui muse. La prima volta ha stampato Not logged in. Run muse again to log in. e si è chiuso. Quindi lo esegui due volte, che è quel piccolo dettaglio che ti fa pensare che l’installazione sia fallita.

La seconda esecuzione avvia un device flow OAuth. Stampa un URL di accesso contenente un codice breve, mostra lo stesso codice separatamente e ti chiede di confermare che coincidano prima di approvare nel browser.

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

Waiting for approval…

Dovresti quindi vedere la seguente schermata: 

Screenshot dell’autore. Il flusso di accesso alla Meta Model API, conferma dei dettagli dell’account prima dell’emissione delle credenziali. 

Nel browser confermi il nome, accetti i termini e inserisci una carta. Leggi il pannello dei prezzi in quella schermata di pagamento invece di cliccare oltre, per ragioni che saranno chiare tra una trentina di secondi.

Il tier predefinito addestra sul tuo codice

Tornando al terminale, l’intestazione della sessione ti dice cosa stai eseguendo:

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.

Rileggi quel nome del modello. La variante contributor, impostata come default, su un’installazione nuova, senza che nessuno lo chieda.

Meta non lo nasconde. L’informativa sta sotto il nome del modello, la schermata di pagamento etichetta contributor come DEFAULT e la status bar mantiene muse-spark-1.3-contributor visibile mentre lavori. 

Ma l’onere è invertito rispetto a quanto si aspetta la maggior parte degli sviluppatori.

Se apri Muse Code dentro il repo di un cliente e inizi a lavorare, hai già inviato quel codice a un endpoint idoneo all’addestramento. Controlla la status bar prima del primo prompt, non dopo.

Screenshot dell’autore. Una prima sessione Muse Code, con il modello di default impostato su muse-spark-1.3-contributor e l’informativa sul miglioramento del prodotto sotto.

La status bar mostra anche lo sforzo di ragionamento, che da me era high. Non xhigh, la variante su cui ha fatto benchmark Artificial Analysis. Vale la pena ricordarlo quando confronti i tuoi risultati con numeri pubblicati.

Scegliere e cambiare tier

Esegui /model e ottieni un selettore interattivo con quattro opzioni e le rispettive tariffe. Queste cifre corrispondono alla schermata di pagamento di Meta:

Contributor costa circa 12 volte meno in input e 21 volte meno in output.

Quello sconto lo acquisti con la tua proprietà intellettuale (IP). La formulazione di Meta è "il tuo contenuto, inclusi i messaggi tra sessioni, può essere usato per il miglioramento del prodotto", che copre più del solo codice che gli fornisci.

Entrambe le varianti di Muse Spark 1.2 sono ancora nel selettore agli stessi prezzi, cosa che conta per il confronto più avanti: dato che le tariffe non si muovono tra generazioni, un confronto sui token è un confronto sui costi senza nulla da normalizzare.

Screenshot dell’autore. Il selettore /model mostra tutte e quattro le varianti di Muse Spark con tariffe per cached, input e output.

Per disattivare, vai con le frecce su muse-spark-1.3 e premi invio. La riga "Discounted tokens" scompare dall’intestazione.

Per lavoro con clienti c’è un’opzione più forte che non compare mai nel terminale. Meta afferma di aver iniziato ad accettare richieste di zero data retention, gestite tramite il reparto vendite anziché con un toggle. 

Retention e training sono questioni separate, e i contratti di agenzia di solito richiedono risposta a entrambe.

Il rate limiting funziona in modo diverso tra i tier, anche se le fonti non concordano su come. Il blog per sviluppatori di Meta descrive il tier contributor come limitato dai token in una finestra mobile di 5 ore invece che dal numero di richieste. La stampa al lancio di 1.2 ha riportato invece un limite di 60 richieste al minuto, un meccanismo completamente diverso. Non ho mai raggiunto nessuno dei due limiti su circa 90 completion del modello in un pomeriggio.

La Meta Model API e OpenRouter

La Meta Model API è compatibile con l’SDK OpenAI, quindi migrare significa cambiare l’ID del modello e mantenere il tuo client. Gli ID modello sono muse-spark-1.3 e muse-spark-1.3-contributor.

OpenRouter lo espone con lo slug meta/muse-spark-1.3. Questo ha un costo: OpenRouter ha misurato un throughput intorno a 81 token al secondo contro i 182 registrati da Artificial Analysis andando diretti, con disponibilità intorno al 92% nei primi tre giorni. Meta è l’unico provider, quindi non c’è un secondo provider su cui fare failover.

La tua prima sessione con Muse Spark 1.3

Tutto ciò che segue gira su python-humanize/humanize, bloccato al commit 823ad6096. Sono 1.676 righe di sorgente su 6 moduli, la test suite gira in meno di un secondo e il dominio non ha bisogno di spiegazioni. Nulla qui modifica il repo. 

Sono domande in sola lettura per vedere come l’agente esplora una codebase prima di affidargli qualcosa che scrive.

Due prompt per capire come legge il codice, partiamo dal primo: 

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

Ha eseguito due comandi, elencato la struttura del progetto, poi ha scritto un parser AST invece di fare grep su import. Risposta: i18n con 4 import in ingresso, suddivisi come i18n 4, number 2 e filesize, lists, time e _version 1 ciascuno.

Ho verificato con il mio script e ho ottenuto numeri diversi, che sembravano una svista del modello. Il mio script era sbagliato. Conteggiava solo gli import relativi (from ._version import ...) e mancava la forma assoluta (from humanize.i18n import ...), che è il modo in cui la maggior parte di questo pacchetto importa. Il modello ha gestito entrambi.

Il secondo prompt è quello che vale la pena eseguire, perché puoi valutarlo:

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

Ha risposto 20 in totale: filesize 1, i18n 5, lists 1, number 8, time 5. Tutto corretto. Ha poi aggiunto, senza che fosse richiesto, che i18n.get_translation è pubblico nel nome ma assente da i18n.__all__, che esporta solo gli altri quattro. Anche questo corretto.

Quella sessione è costata $0.01 su 8 turni.

Il livello di ragionamento di cui Meta non parla

muse --help documenta questo:

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

Il selettore in sessione /effort offre sei di quei sette, escludendo none. 

Screenshot dell’autore. Il selettore /effort elenca sei livelli di ragionamento selezionabili, con high marcato come corrente.

Entrambi elencano un livello chiamato ultra, che non appare in nessun annuncio di Meta. La posizione pubblica di Meta è che il max reasoning è "in arrivo a breve dopo il completamento di ulteriori test di sicurezza".

Quindi l’ho chiesto:

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

C’è una feature gate nominata, ultra_reasoning_effort, ed è chiusa. La capacità è costruita e l’interruttore è spento lato server. È un quadro più specifico di "in attesa di test di sicurezza" ed è arrivato in un messaggio di avviso che contiene anche la parola "tbh".

Due punti pratici. Il client pubblicizza un livello che il backend non serve, sia nella CLI che nel selettore. E fa il downgrade in silenzio a xhigh con una singola riga su stderr, che in uno script o in un log di CI scorre via inosservata. Crederesti di eseguire una configurazione che in realtà non stai usando.

Poi ho provato un valore che non appare da nessuna parte nella documentazione:

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

Nessun avviso. Ha eseguito e restituito ok. Quindi un valore non documentato passa la validazione senza commenti mentre uno documentato viene bloccato, e non puoi capire dall’output quale livello di sforzo abbia effettivamente servito la tua richiesta.

Screenshot dell’autore. Richiedere ultra restituisce una feature gate chiusa e un downgrade silenzioso a xhigh, mentre l’undocumented max passa senza commenti.

Se ti interessa quale livello di ragionamento stai usando, impostalo esplicitamente e leggi stderr. Non dare per scontato che il flag passato sia quello usato.

L’affermazione di efficienza di Muse Spark 1.3 regge?

Ecco il test. Prendi un repo open source, ripristina un vero commit di bugfix così che una test suite fallisca davvero, poi esegui tre task di coding su entrambi i modelli con gli stessi prompt e gli stessi flag.

Questi sono separati dalla sessione esplorativa sopra. Ognuno di essi scrive codice.

Invertire la metà sorgente del commit 823ad6096 mantenendo i suoi test lascia 6 test falliti, ed è lo stato di partenza:

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

Ogni esecuzione ha usato lo stesso schema di comando, cambiando solo l’ID modello e il prompt:

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

Task 1, bug fix. 

Il successo qui è binario: i 6 test passano, oppure no. 

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

Task 2, piccola feature.

Abbastanza aperto perché i due modelli possano non essere d’accordo sull’ambito, cosa che si è rivelata rilevante.

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.

Task 3, refactor.

Il più pesante dei tre, tocca diversi file.

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.

I tre task sono stati eseguiti in sequenza senza reset tra loro, quindi i task 2 e 3 hanno costruito su ciò che il modello aveva prodotto prima. Entrambi i modelli hanno seguito lo stesso percorso.

I conteggi dei token provengono dai log di sessione in ~/.local/share/muse/sessions/, conteggiati una volta per completion del modello. Tutte e sei le esecuzioni hanno passato i test.

E le differenze, dove negativo significa che la 1.3 ha usato meno:

Leggere il risultato con onestà

Due task su tre sono risultati più economici, con il 23% e il 32% di completion in meno. È in linea con l’affermazione di Meta sulle tool-call. Poi il refactor è andato nell’altra direzione: 70% di completion in più e 38% di costi in più.

Sui tre complessivi, la 1.3 è costata il 12% in più della 1.2. Quindi l’affermazione di efficienza è reale ma dipendente dal task, e una singola percentuale a effetto lo nasconde del tutto.

L’input non in cache è sceso in ogni task del 19%, 22% e 5%. Mai del 25%. 

Meta non dice quali token abbia contato, e la risposta cambia molto a seconda che tu intenda input, output, non in cache o totale.

I tassi di hit della cache sono stati tra l’88% e il 97% e sono saliti con la lunghezza del task. Riportare i token di input grezzi senza separare cached da non cached sarebbe quasi privo di senso, dato che i 4,18M di input del refactor sono in realtà 109k di nuovo contesto più 4,07M di ri-letture fatturate a un cinquantesimo della tariffa.

Perché il refactor non è una perdita netta

Guarda cosa ha effettivamente fatto la 1.3 su quel task prima di chiamarla inefficiente.

Ha verificato che ogni blocco spostato fosse byte-identico all’originale, in modo programmatico. 

Ha eseguito --doctest-modules su entrambi i nuovi file. Ha testato la risoluzione degli import da una directory temporanea in /tmp. Poi ha segnalato due cose che nessuno aveva chiesto: che la funzione humanize.scientific fa shadowing al nuovo sottomodulo e che un doctest di naturaldelta fallisce identicamente sull’albero pulito, quindi il fallimento non è attribuibile alla modifica.

Muse Spark 1.2 ha duplicato una funzione helper per evitare un import circolare ed è andata avanti. La 1.3 l’ha importata e ha spiegato perché non c’era un ciclo.

Con questo design non puoi separare "ha bruciato più token" da "ha fatto un lavoro più accurato". L’affermazione onesta è che la 1.3 ha speso di più e consegnato di più, e se sia un vantaggio dipende dal fatto che tu volessi il rigore extra.

Il task della feature mostra il pattern opposto ed è l’illustrazione più pulita dell’affermazione "meno verbosa" di Meta. Muse Spark 1.2 ha inventato alias di parametro max_items, n e max_len che nessuno aveva richiesto e ha scritto 28 test. 

Muse Spark 1.3 ha scritto una singola firma con un default sensato e 20 test, con il 54% di token di output in meno.

Cosa non ho potuto controllare

Quattro cose, e l’articolo sarebbe disonesto senza dirlo.

1. Muse Code si è aggiornato da 1.0.2 a 1.0.3 a metà, quindi l’imbracatura non era identica su tutte e sei le esecuzioni. 
2. I task 2 e 3 sono partiti dall’output precedente di ciascun modello anziché da un albero byte-identico, perché la sequenza procede senza reset.
3. Ogni cella è una singola prova, quindi la normale varianza run-to-run non è misurata. 
4. E ho eseguito tutto sul tier contributor, che è lo stesso modello ma non gli stessi termini sui dati.

Nulla di ciò invalida la direzione dei risultati. Significa però che una differenza aggregata del 12% è un segnale più debole di quanto darebbero tre esecuzioni combacianti per cella.

Best practice e troubleshooting per Muse Spark 1.3

Alcune cose che avrei voluto sapere dal primo giorno.

Prompt per i comportamenti collaborativi

Muse Spark 1.3 fa domande di chiarimento su prompt ambigui, quindi un prompt iper-specifico disattiva una funzione per cui stai pagando. Controintuitivo se hai passato due anni a imparare a pre-caricare ogni istruzione.

L’ambito però conta ancora. "Dividi number.py" lascia al modello l’ipotesi sul confine, sugli aggiornamenti degli import e su cosa conti come fatto. La versione che ho effettivamente usato specifica tutti e 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.

Un’altra cosa utile da sapere. Il mio prompt di refactor diceva number.py is 571 lines. Sono 567. Entrambi i modelli mi hanno corretto senza richiesta, e la 1.3 l’ha fatto nella frase di apertura. Il mio numero veniva dal misurare la punta del repo invece del commit bloccato.

Tenere bassi i costi

Metti la parte stabile del tuo prompt all’inizio così resta in cache. Con hit rate tra l’88% e il 97%, il comportamento della cache sposta il conto molto più della scelta del modello.

I tre task sono costati in totale $0.034 su contributor. Lo stesso lavoro su standard sarebbe costato $0.91, una differenza di 27 volte. È la decisione sul tier espressa in denaro: tre centesimi contro novanta.

Se passi da OpenRouter, la web search si fattura separatamente a $2.50 per 1.000 chiamate.

Quando Muse Spark 1.3 non è la scelta giusta

• Nessuna traccia di ragionamento esposta. Vedi cosa ha deciso, non perché, il che rende un refactor sbagliato più difficile da debuggare.
• Il max reasoning è gated, quindi la configurazione dietro ogni numero di benchmark in evidenza è fuori portata.
• Pesi chiusi. Niente self-hosting, niente fine-tuning. La roadmap di Meta cita un "Muse Spark open weights release" senza versione, data o licenza.
• Un solo provider. Quando l’endpoint di Meta degrada, non c’è dove instradare.

Problemi comuni e soluzioni

• muse: command not found dopo una nuova installazione. Lo script installa in ~/.local/bin/muse, che non è su PATH in tutte le shell.
• Not logged in. Run muse again to log in. Esattamente come dice. Il primo muse esce, il secondo avvia l’accesso.
• Sei sul tier contributor e non l’hai scelto. È il default. Controlla la status bar ed esegui /model prima di aprire qualcosa di proprietario.
• ultra reasoning diventa silenziosamente xhigh. La gate è chiusa. Leggi stderr invece di fidarti del flag passato.
• Muse Code si aggiorna a sessione in corso. Da me è passato da 1.0.2 a 1.0.3 tra le esecuzioni. Se misuri qualcosa, blocca e registra la versione.

Una cosa che non si è riprodotta

Sono circolate segnalazioni che gli utenti UE venissero ancora serviti con Muse Spark 1.1 dopo l’uscita della 1.3. Ho eseguito tutto questo dai Paesi Bassi e ho ottenuto la 1.3 per tutto il tempo. Quelle segnalazioni riguardavano Meta.ai, l’assistente consumer, e non sembrano applicarsi a Muse Code o alla Model API. Due rollout diversi.

Considerazioni finali

L’affermazione di efficienza di Meta ha tenuto in due dei miei tre task e si è invertita nel terzo, per un aumento netto del 12% dei costi sull’insieme. Il lato tool-call dell’affermazione è solido con riduzioni del 23% e 32% dove la 1.3 ha vinto. Il lato token dipende interamente da quali token conti.

Se sei già sulla Meta Model API o in Muse Code, cambiare l’ID del modello richiede un minuto e probabilmente ne uscirai avvantaggiato sul lavoro di routine. Se stai scegliendo da zero per agenti in produzione, la variante max gated e le tracce di ragionamento assenti sono motivi concreti per aspettare qualche settimana.

La cosa su cui agirei davvero non è il numero sull’efficienza. È che Muse Code ti mette su un tier idoneo all’addestramento di default, e che un livello di ragionamento documentato fa downgrade silenzioso quando lo chiedi. Entrambi si controllano in una riga e sono facili da perdere.

Esegui il confronto sul tuo carico di lavoro. I miei tre task non sono i tuoi tre task, e la variabilità tra loro è stata più ampia della differenza tra i modelli.

Per il quadro completo dei benchmark, l’ analisi del rilascio di Muse Spark 1.3 di Matt ha le tabelle. Per sviluppare le competenze per valutare modelli come questo da solo, inizia con il nostro skill track AI Agent Fundamentals.