Tutoriel Muse Spark 1.3 : guide pratique pour développeurs

Meta a livré Muse Spark 1.3 le 2 septembre 2026, et les instructions de mise à niveau tiennent en une ligne : changer l'ID du modèle. Autrement dit, mêmes endpoints, même SDK, même tarification.

D'après Meta, cette édition « en une ligne » vous apporte un modèle qui termine la même tâche avec environ 20 % d'appels d'outils en moins et 25 % de tokens en moins que Muse Spark 1.2. Ces chiffres proviennent de comparaisons réalisées par les propres ingénieurs de Meta, sur des tâches non décrites et sans méthodologie publiée.

C'est exactement le genre d'affirmation que je préfère vérifier avant de la relayer. 

J'ai donc installé Muse Code, volontairement cassé un vrai projet open source, puis exécuté les mêmes trois tâches sur les deux modèles.

Pour suivre ce tutoriel Muse Code, vous aurez besoin d'un compte développeur Meta, d'un terminal dans lequel vous êtes à l'aise, et de macOS ou Linux pour l'agent Muse Code. Les utilisateurs Windows restent à l'écart dans la bêta actuelle.

En bref

• Muse Spark 1.3 est le modèle phare de raisonnement multimodal de Meta, sorti le 2 septembre 2026, avec une fenêtre de contexte d'un million de tokens.
• Par défaut, Muse Code vous place sur muse-spark-1.3-contributor, ce qui signifie que Meta entraîne sur votre code sauf si vous changez d'option. L'entraînement est en opt-out, pas en opt-in.
• Sur 6 exécutions et 3 tâches de code, la 1.3 a coûté moins cher sur 2 tâches et 38 % plus cher sur la troisième, pour une hausse nette de 12 % du coût sur l'ensemble.
• Les complétions de modèle ont chuté de 23 % et 32 % sur les 2 tâches où 1.3 l'a emporté, ce qui colle avec l'affirmation de Meta sur les appels d'outils. L'input non mis en cache a baissé sur les 3, mais jamais de 25 %.
• Le niveau de raisonnement ultra existe dans le CLI et le sélecteur en session, mais le backend le refuse avec un feature gate nommé.

Qu'est-ce que Muse Spark 1.3 ?

Muse Spark 1.3 est le modèle phare de raisonnement multimodal de Meta, publié par Meta Superintelligence Labs le 2 septembre 2026 et conçu pour de longues sessions agentiques et le codage sur de grands dépôts. Il accepte 1 48 576 tokens de contexte et prend en entrée du texte, des images, de la vidéo et des fichiers.

Six évolutions par rapport à Muse Spark 1.2 :

• Efficacité. Environ 20 % d'appels d'outils en moins et 25 % de tokens en moins dans les comparaisons internes de Meta.
• Collaboration. Pose des questions de clarification sur des prompts vagues et vérifie avant les actions conséquentes.
• Multitâche dans un même fil, pour rattacher un message envoyé en cours de route à la bonne tâche.
• Meilleur suivi d'instructions longues, avec moins de contraintes perdues sur du travail en plusieurs étapes.
• Meilleure calibration sur les actions irréversibles.
• Style de code plus propre. Moins de tours inutiles, moins de verbosité.

Tout cela est prometteur, mais le scorecard publié par Meta fait tourner Muse Spark 1.3 en max reasoning face à Muse Spark 1.2 en xhigh, et max était encore soumis à un gate au lancement. 

Artificial Analysis a noté la variante xhigh (livrée) à 61 sur l'Intelligence Index et max à 62. Un seul point d'écart.

Matt Crabtree a déjà traité l'intégralité des tableaux de benchmarks, la ventilation tarifaire, et la comparaison avec GPT-5.6 Sol et Claude Opus 5 dans son analyse de la sortie de Muse Spark 1.3. Je ne le répète pas ici. Ce qui suit décrit ce qui se passe quand on installe l'outil et qu'on le fait fonctionner.

Comment accéder à Muse Spark 1.3

Trois voies sont possibles, à choisir selon ce que vous construisez. Choisissez dans le tableau, puis passez à la section correspondante.

Muse Code, l'agent en terminal

Muse Code est l'agent de codage en terminal de Meta, en bêta pour macOS et Linux. C'est le harnais qui exécute Muse Spark, et les deux versionnent indépendamment, donc muse --version ne vous dit rien sur le modèle utilisé. Gardez bien ces deux notions séparées.

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

Cela télécharge un binaire de 230 Mo et le place dans ~/.local/bin/muse, qui n'est pas toujours présent dans le PATH de chacun. 

Ensuite, vérifiez ce qui a été installé :

muse --version

Le 4 septembre 2026, cela m'a renvoyé Muse Code 1.0.2 (1.0.2-R2040.1). 

Un message un peu étrange pour une bêta, puisque des outils tiers documentaient Muse Code en 0.2.1 quelques semaines plus tôt. Epinglez la version que vous obtenez à la date où vous l'avez installée.

Capture d'écran par l'auteur. Installation de Muse Code via la commande en une ligne, puis vérification de la version 1.0.2 sur macOS.

Lancez maintenant muse. La première fois, il a affiché Not logged in. Run muse again to log in. puis s'est fermé. Il faut donc le lancer deux fois, le genre de détail qui fait croire que l'installation a échoué.

Au deuxième lancement, un device flow OAuth démarre. Il affiche une URL de connexion avec un code court, montre le même code séparément, et vous demande de confirmer qu'ils correspondent avant d'approuver dans le navigateur.

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

Waiting for approval…

Vous devriez ensuite voir l'écran suivant : 

Capture d'écran par l'auteur. Le parcours de connexion à la Meta Model API, qui confirme les informations du compte avant d'émettre des identifiants. 

Côté navigateur, vous confirmez votre nom, acceptez les conditions et ajoutez une carte. Lisez bien le panneau de tarification à cet écran de paiement au lieu de cliquer trop vite : vous comprendrez pourquoi dans une trentaine de secondes.

Le niveau par défaut entraîne sur votre code

De retour dans le terminal, l'en-tête de session indique ce qui tourne :

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.

Relisez le nom du modèle. La variante contributor, réglée par défaut, sur une installation neuve, sans que personne ne vous demande votre avis.

Meta ne le cache pas. La mention apparaît sous le nom du modèle, l'écran de paiement indique contributor comme DEFAULT, et la barre d'état garde muse-spark-1.3-contributor visible pendant que vous travaillez. 

Mais la charge est inversée par rapport à ce à quoi la plupart des développeurs s'attendent.

Si vous ouvrez Muse Code dans un dépôt client et commencez à travailler, vous avez déjà envoyé ce code à un endpoint éligible à l'entraînement. Vérifiez la barre d'état avant votre premier prompt, pas après.

Capture d'écran par l'auteur. Une première session Muse Code, avec le modèle par défaut muse-spark-1.3-contributor et la mention d'amélioration produit en dessous.

La barre d'état affiche aussi l'effort de raisonnement, qui était à high chez moi. Pas xhigh, la variante benchmarkée par Artificial Analysis. A garder en tête quand vous comparez vos résultats à des chiffres publiés.

Choisir et changer de niveau

Lancez /model et vous obtenez un sélecteur interactif avec quatre options et leurs tarifs. Ces montants correspondent à l'écran de paiement de Meta :

Contributor est environ 12 fois moins cher en entrée et 21 fois moins cher en sortie.

Ce qui achète cette remise, c'est votre propriété intellectuelle (PI). Le libellé de Meta est : « votre contenu, y compris les messages inter-sessions, peut être utilisé pour l'amélioration du produit », ce qui couvre bien plus que le code que vous lui fournissez.

Les deux variantes de Muse Spark 1.2 sont toujours dans le sélecteur aux mêmes prix, ce qui comptera plus tard : puisque les tarifs ne bougent pas entre générations, une comparaison de tokens équivaut à une comparaison de coûts, sans normalisation.

Capture d'écran par l'auteur. Le sélecteur /model affichant les quatre variantes de Muse Spark avec les tarifs cache, entrée et sortie.

Pour vous désinscrire, remontez sur muse-spark-1.3 et validez. La ligne « Discounted tokens » disparaît de l'en-tête.

Pour du travail client, il existe une option plus robuste qui n'apparaît jamais dans le terminal. Meta indique avoir commencé à accepter des demandes de rétention zéro, gérées via les ventes plutôt qu'un interrupteur. 

La rétention et l'entraînement sont deux sujets différents, et les contrats d'agence exigent généralement des réponses sur les deux.

Le rate limiting diffère entre les niveaux, même si les sources ne s'accordent pas sur le comment. Le blog développeurs de Meta décrit le niveau contributor comme plafonné par tokens sur une fenêtre glissante de 5 heures plutôt que par nombre de requêtes. La presse au lancement de la 1.2 parlait d'un plafond de 60 requêtes par minute, un mécanisme tout autre. Je n'ai atteint aucune de ces limites sur environ 90 complétions en une après-midi.

La Meta Model API et OpenRouter

La Meta Model API est compatible avec le SDK OpenAI, donc migrer revient à changer l'ID du modèle en conservant votre code client. Les IDs sont muse-spark-1.3 et muse-spark-1.3-contributor.

OpenRouter le propose sous le slug meta/muse-spark-1.3. Cela a un coût : OpenRouter a mesuré un débit d'environ 81 tokens par seconde contre 182 chez Artificial Analysis en direct, avec une disponibilité proche de 92 % sur les trois premiers jours. Meta est l'unique fournisseur, sans bascule possible vers un second.

Votre première session Muse Spark 1.3

Tout ce qui suit tourne sur python-humanize/humanize, figé au commit 823ad6096. 1 676 lignes de source sur 6 modules, une suite de tests qui s'exécute en moins d'une seconde, et un domaine sans mystère. Rien ici ne modifie le dépôt. 

Ce sont des questions en lecture seule pour observer comment l'agent explore une base de code avant de lui confier quoi que ce soit en écriture.

Deux prompts pour jauger sa lecture de code, commençons par le premier : 

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

Il a exécuté deux commandes, listé la structure du projet, puis écrit un parseur d'AST plutôt que de grepper import. Réponse : i18n avec 4 imports entrants, détaillés en i18n 4, number 2, et filesize, lists, time et _version 1 chacun.

J'ai vérifié avec mon propre script et obtenu des chiffres différents, ce qui semblait être un lézard. Mon script était faux. Il ne comptait que les imports relatifs (from ._version import ...) et manquait la forme absolue (from humanize.i18n import ...), qui est la plus courante dans ce package. Le modèle a géré les deux.

Le second prompt vaut la peine d'être lancé, car vous pouvez le noter :

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

Il a répondu 20 au total : filesize 1, i18n 5, lists 1, number 8, time 5. Tout est correct. Il a ajouté, sans qu'on le lui demande, que i18n.get_translation est publique par son nom mais absente de i18n.__all__, qui n'exporte que les quatre autres. Egalement correct.

Cette session a coûté 0,01 $ sur 8 tours.

Le niveau de raisonnement dont Meta ne parle pas

muse --help documente ceci :

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

Le sélecteur /effort en session propose six de ces sept niveaux, sans none. 

Capture d'écran par l'auteur. Le sélecteur /effort liste six niveaux de raisonnement sélectionnables, avec high marqué comme courant.

Les deux listent un niveau appelé ultra, absent de toute annonce de Meta. La position publique de Meta est que le raisonnement max arrive « bientôt, une fois les tests de sécurité supplémentaires terminés ».

J'ai donc tenté :

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

Il existe un feature gate nommé, ultra_reasoning_effort, et il est fermé. La capacité est construite, et l'interrupteur est éteint côté serveur. C'est plus précis que « en attente de tests de sécurité », et le message d'avertissement contient aussi « tbh ».

Deux points pratiques. Le client annonce un niveau que le backend ne sert pas, à la fois dans le CLI et dans le sélecteur. Et il rétrograde silencieusement vers xhigh avec une seule ligne sur stderr, qui dans un script ou un log CI passera inaperçue. Vous pourriez croire avoir utilisé une configuration qui n'était pas en vigueur.

J'ai ensuite essayé une valeur absente de la documentation :

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

Aucun avertissement. La commande a tourné et renvoyé ok. Donc une valeur non documentée passe la validation sans commentaire tandis qu'une valeur documentée est bloquée, et vous ne pouvez pas savoir au vu de la sortie quel niveau a effectivement servi votre requête.

Capture d'écran par l'auteur. Demander ultra renvoie un feature gate fermé et une rétrogradation silencieuse vers xhigh, tandis que le non-documenté max passe sans commentaire.

Si vous tenez au niveau de raisonnement utilisé, définissez-le explicitement et lisez stderr. N'assumez pas que le flag passé est celui qui a été appliqué.

L'affirmation d'efficacité de Muse Spark 1.3 tient-elle la route ?

Voici le test. Prendre un dépôt open source, rétablir un vrai commit correctif pour faire échouer une suite de tests de manière réelle, puis exécuter trois tâches de code sur les deux modèles avec les mêmes prompts et les mêmes flags.

C'est distinct de la session exploratoire ci-dessus. Chaque tâche écrit du code.

Rétablir la partie source du commit 823ad6096 tout en conservant ses tests laisse 6 tests en échec : état de départ.

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

Chaque exécution utilise la même commande, en ne changeant que l'ID du modèle et le prompt :

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

Tâche 1, correctif de bug. 

Succès binaire : les 6 tests passent, ou non. 

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

Tâche 2, petite fonctionnalité.

Assez ouverte pour que les deux modèles divergent sur le périmètre, ce qui s'est révélé 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.

Tâche 3, refactorisation.

La plus lourde des trois, touche plusieurs fichiers.

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.

Les trois tâches ont tourné à la suite sans réinitialisation entre elles, donc les tâches 2 et 3 ont bâti sur la production du modèle précédent. Les deux modèles ont suivi la même trajectoire.

Les comptes de tokens proviennent des logs de session dans ~/.local/share/muse/sessions/, comptés une fois par complétion. Les six exécutions ont passé leurs tests.

Et les écarts, où une valeur négative signifie que la 1.3 a moins consommé :

Lire le résultat honnêtement

Deux tâches sur trois coûtent moins cher, avec 23 % et 32 % de complétions en moins. C'est conforme à l'affirmation de Meta sur les appels d'outils. Puis la refactorisation part dans l'autre sens : 70 % de complétions en plus et 38 % de coût en plus.

Sur l'ensemble, la 1.3 coûte 12 % de plus que la 1.2. L'affirmation d'efficacité est donc réelle mais dépend de la tâche, et un pourcentage « titre » masque complètement cela.

L'input non mis en cache a baissé sur chaque tâche de 19 %, 22 % et 5 %. Jamais 25 %. 

Meta ne précise pas quels tokens ont été comptés, et la réponse varie fortement selon que l'on parle d'entrée, de sortie, de non mis en cache ou du total.

Les taux de hit cache allaient de 88 % à 97 % et augmentaient avec la longueur de la tâche. Rapporter des tokens d'entrée bruts sans distinguer cache et non cache serait quasi dépourvu de sens, puisque les 4,18 M d'entrée du refactor sont en réalité 109k de nouveau contexte plus 4,07 M de relectures facturées à un cinquantième du tarif.

Pourquoi la refactorisation n'est pas une perte sèche

Regardez ce que la 1.3 a réellement fait sur cette tâche avant de la qualifier d'inefficace.

Elle a vérifié, de manière programmée, que chaque bloc déplacé était identique octet par octet à l'original. 

Elle a exécuté --doctest-modules sur les deux nouveaux fichiers. Elle a testé la résolution des imports depuis un répertoire jetable dans /tmp. Puis elle a signalé deux points non demandés : que la fonction humanize.scientific masque le nouveau sous-module, et qu'un doctest de naturaldelta échoue de manière identique sur l'arbre vierge, donc l'échec n'est pas imputable au changement.

Muse Spark 1.2 a dupliqué une fonction utilitaire pour éviter un import circulaire et a continué. La 1.3 l'a importée et expliqué pourquoi il n'y avait pas de cycle.

Avec ce design, on ne peut pas dissocier « a brûlé plus de tokens » de « a fait un travail plus approfondi ». L'énoncé honnête est que la 1.3 a dépensé plus et livré plus, et que le gain dépend de votre appétit pour ce surcroît de rigueur.

La tâche feature montre le schéma inverse et illustre le mieux l'affirmation « moins verbeux » de Meta. Muse Spark 1.2 a inventé des alias de paramètres max_items, n et max_len que personne n'avait demandé et écrit 28 tests. 

Muse Spark 1.3 a proposé une signature unique avec une valeur par défaut pertinente et 20 tests, soit 54 % de tokens de sortie en moins.

Ce que je n'ai pas pu contrôler

Quatre points, qu'il serait malhonnête de passer sous silence.

1. Muse Code s'est mis à jour de 1.0.2 à 1.0.3 en cours de route, donc le harnais n'était pas identique sur les six exécutions. 
2. Les tâches 2 et 3 ont démarré de la sortie propre à chaque modèle plutôt que d'un arbre strictement identique, car la séquence s'enchaîne sans réinitialisation.
3. Chaque cellule est un seul essai, donc la variance run-to-run n'est pas mesurée. 
4. Et j'ai tout exécuté sur le niveau contributor, qui est le même modèle mais pas les mêmes conditions de données.

Rien de tout cela n'invalide la tendance des résultats. Mais une différence agrégée de 12 % est un signal plus faible que trois exécutions concordantes par cellule.

Bonnes pratiques et dépannage pour Muse Spark 1.3

Quelques conseils que j'aurais aimé avoir dès le premier jour.

Prompting pour les comportements de collaboration

Muse Spark 1.3 pose des questions de clarification sur des prompts ambigus, donc un prompt trop spécifié désactive une fonctionnalité que vous payez. Contre-intuitif si vous avez passé deux ans à tout précharger dans l'instruction.

Le périmètre reste important toutefois. « Scinder number.py » laisse le modèle deviner la frontière, les mises à jour d'import, et la définition de fini. La version que j'ai utilisée détaille les trois :

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.

Autre point utile : mon prompt de refactor disait number.py is 571 lines. Il en compte 567. Les deux modèles m'ont corrigé sans que je le demande, et la 1.3 l'a fait dès sa première phrase. Mon chiffre venait de la mesure à la pointe du dépôt et non au commit figé.

Réduire les coûts

Placez la partie stable de votre prompt au début pour qu'elle reste éligible au cache. Avec 88 % à 97 % de taux de hit, votre comportement de cache pèse bien plus sur la facture que le choix du modèle.

Les trois tâches ont coûté 0,034 $ en contributor. Le même travail en standard aurait coûté 0,91 $, soit 27×. Voilà la décision de niveau en euros sonnantes : trois centimes contre quatre-vingt-dix.

Si vous passez par OpenRouter, la recherche web est facturée séparément : 2,50 $ pour 1 000 appels.

Quand Muse Spark 1.3 n'est pas le bon choix

• Pas de traces de raisonnement exposées. Vous voyez la décision, pas le pourquoi, ce qui complique le debug d'une mauvaise refactorisation.
• Le raisonnement max est soumis à un gate, donc la configuration derrière beaucoup de chiffres « vitrine » est hors de portée.
• Poids fermés. Pas d'auto-hébergement, pas de fine-tuning. La feuille de route de Meta mentionne un « Muse Spark open weights release » sans version, date ni licence.
• Un seul fournisseur. Si l'endpoint de Meta se dégrade, pas de routage de secours.

Problèmes courants et correctifs

• muse: command not found après une installation propre. Le script installe dans ~/.local/bin/muse, qui n'est pas sur le PATH de tous les shells.
• Not logged in. Run muse again to log in. C'est littéral. Le premier muse se ferme, le second lance la connexion.
• Vous êtes sur le niveau contributor sans l'avoir choisi. C'est le défaut. Vérifiez la barre d'état et lancez /model avant d'ouvrir quoi que ce soit de propriétaire.
• ultra devient silencieusement xhigh. Le gate est fermé. Lisez stderr plutôt que de faire confiance au flag passé.
• Muse Code se met à jour en pleine session. Le mien est passé de 1.0.2 à 1.0.3 entre deux exécutions. Si vous mesurez quoi que ce soit, épinglez et notez la version.

Un point qui ne s'est pas reproduit

Des retours indiquaient que des utilisateurs de l'UE étaient encore servis par Muse Spark 1.1 après la sortie de la 1.3. J'ai exécuté tout cela depuis les Pays-Bas et obtenu 1.3 partout. Ces rapports concernaient Meta.ai, l'assistant grand public, et ne semblent pas s'appliquer à Muse Code ni à la Model API. Deux déploiements différents.

Conclusion

L'affirmation d'efficacité de Meta tient sur deux de mes trois tâches et s'inverse sur la troisième, pour une hausse nette de 12 % du coût sur l'ensemble. Le volet appels d'outils semble solide avec 23 % et 32 % de réduction là où 1.3 gagne. Le volet tokens dépend entièrement des tokens que vous comptez.

Si vous êtes déjà sur la Meta Model API ou dans Muse Code, changer l'ID du modèle prend une minute, et vous serez probablement gagnant sur le quotidien. Si vous choisissez à neuf pour des agents en production, la variante max encore gérée par gate et l'absence de traces de raisonnement sont de bonnes raisons d'attendre quelques semaines.

Ce que je retiendrais surtout n'est pas le chiffre d'efficacité. C'est que Muse Code vous met par défaut sur un niveau éligible à l'entraînement, et qu'un niveau de raisonnement documenté est rétrogradé silencieusement quand on le demande. Deux vérifications d'une ligne, faciles à manquer.

Faites la comparaison sur votre propre charge. Mes trois tâches ne sont pas les vôtres, et l'écart entre elles était plus grand que la différence entre les modèles.

Pour la vue d'ensemble des benchmarks, l' analyse de sortie de Muse Spark 1.3 de Matt contient les tableaux. Pour acquérir les compétences permettant d'évaluer vous-même des modèles comme celui-ci, commencez par notre AI Agent Fundamentals skill track.