Muse Code, le pari de Meta sur des agents qui n'oublient rien

Meta a lancé aujourd'hui Muse Code — un agent de codage en terminal, en bêta publique pour macOS et Linux — propulsé par Muse Spark 1.2, une mise à jour axée sur le code, co-entraînée spécifiquement pour fonctionner avec lui.

L'architecture : des agents qui n'oublient pas d'un tour à l'autre

Le vrai pari de Muse Code, ce sont les agents de fond persistants. La plupart des harnais de codage font naître un sous-agent auxiliaire frais par tâche — explorer le dépôt, faire le travail, jeter le contexte, recommencer au tour suivant. Les agents spécialisés de Muse Code « restent actifs pendant toute la session, plutôt que d'être créés pour des tâches individuelles », ce qui signifie qu'un agent ayant déjà exploré un dépôt n'a pas à le réexplorer à chaque nouvelle demande du développeur. Ils travaillent de façon autonome en arrière-plan et choisissent quand rendre compte à l'agent principal, plutôt que d'être interrogés en continu.

L'autre élément réel est un journal d'événements local : chaque appel de modèle, exécution d'outil, approbation et modification est ajouté à une source de vérité unique. Cela rend l'exécution reproductible à l'identique et sûre au redémarrage — après un plantage, l'agent reprend exactement là où il s'est arrêté, plutôt que de redériver un état ou de perdre la session. C'est le même instinct que le noyau d'entraînement déterministe de Cursor et la capture de trajectoires par proxy de harnais de Liquid, appliqué à l'exécution plutôt qu'à l'entraînement : une session d'agent que l'on peut auditer et reprendre est un artefact fondamentalement différent de celle que l'on ne peut que relancer de zéro.

Trois compétences intégrées s'ajoutent à cette boucle : /plan transforme une tâche en un plan que le développeur doit approuver avant l'exécution, /grill soumet ce plan à un stress-test avant qu'aucun code ne soit écrit, et /goal travaille vers un objectif spécifié plutôt qu'une séquence d'instructions figée. L'ordre est la partie intéressante — planifier, puis mettre le plan sous pression de façon adversariale, et exécuter seulement ensuite — ce qui place un point de contrôle avant la partie coûteuse d'une tâche longue plutôt qu'après.

Muse Spark 1.2 a été co-entraîné spécifiquement pour exploiter cela — Meta affirme qu'il « présente ses meilleures performances et sa meilleure utilisabilité pour le code lorsqu'il est associé » à Muse Code, et non comme un modèle généraliste qui s'y exécuterait par hasard. Concrètement, l'entraînement a inclus des trajectoires de harnais par échantillonnage par rejet et des optimisations de recette réglées spécifiquement pour les objectifs, la compaction et les sous-agents, ainsi qu'une intégration directe de l'ensemble d'outils de Muse Code. C'est un modèle entraîné contre le harnais réel avec lequel il est livré, et non un modèle généraliste reconverti a posteriori — le même couplage que celui décrit par Liquid pour le RL agentique de LFM2.5 dans de vrais harnais, étendu ici à un harnais que Meta contrôle elle-même.

Les données d'entraînement pour cela comportent aussi une boucle d'auto-amélioration qui mérite d'être nommée : Meta a utilisé Muse Spark 1.1 pour générer des environnements de codage exigeants et des modèles de suivi d'instructions, puis lui a fait noter des solutions candidates au regard de ces exigences auto-générées — une façon scalable de fabriquer un jeu d'entraînement pour la version 1.2 sans attendre davantage de tâches étiquetées par des humains. C'est une cousine plus légère de l'approche de distillation par professeur qu'LFM2.5 a utilisée pour MOPD : le checkpoint plus ancien ne se contente pas de générer des données, il note aussi les devoirs de son successeur.

Les gains par rapport à la version 1.1 sont réels selon les propres chiffres de Meta : Terminal-Bench 2.1 passe de 76,2 à 82,9, DeepSWE 1.1 de 53,0 à 59,3. Sur la comparaison indépendante plus exigeante, il est troisième — DeepSWE 1.1 place Muse Spark 1.2 à 59,3%, derrière Claude Opus 5 (65,0%) et GPT-5.6 Terra (64,8%). Sur son propre benchmark de codage interne, il devance Terra (70,6 contre 65,4) et Gemini 3.6 Flash (63,9) — un écart à lire comme ce blog lit tout graphique auto-noté par un éditeur : réel, mais pas neutre.

L'étude de cas que Meta a réellement menée : 24 heures d'optimisation de kernels

Enfouie derrière l'argumentaire architectural se trouve le seul résultat de ce lancement qui ne soit pas un tableau de benchmark statique — une exécution agentique en direct, et elle est plus instructive que les chiffres de classement ci-dessus précisément parce qu'elle est plus étroite.

La tâche : optimiser des kernels GPU KDA et MLA pour NVIDIA Hopper, de façon itérative — écrire, compiler, profiler, améliorer, recommencer — face à une base de référence fournie, sur plus de 1 000 appels d'outils, jusqu'à 24 heures, à l'intérieur de l'environnement agentique propre à Muse Code. Meta a tracé l'accélération par rapport à la référence en fonction du nombre cumulé d'appels d'outils pour six modèles :

Deux éléments méritent d'être lus sur la courbe plutôt que sur le seul point final. Muse Spark 1.2 atteint son plateau tôt — un bond net à environ 60% en quelques centaines d'appels d'outils — et pendant une longue portion médiane, il se situe en réalité devant GPT-5.6 Sol, avant que Sol ne comble l'écart et ne le dépasse de justesse au décompte final. Et les deux modèles Claude prennent l'avantage tôt et le conservent : Opus 5 termine avec 14 points d'avance sur Muse Spark 1.2, un écart que cette tâche ne referme jamais.

C'est un tableau plus honnête que ne le laissent penser les classements ci-dessus, dans les deux sens. Il confirme que Muse Spark 1.2 est un concurrent réel face au palier intermédiaire des modèles de codage de pointe sur une tâche longue et véritablement difficile, pas seulement sur des benchmarks conçus pour être maîtrisables — mais c'est un seul cas d'usage, choisi et exécuté par Meta elle-même, sur un domaine (l'optimisation de kernels GPU) qui sert exactement ce pour quoi ce modèle a été réglé. À retenir comme un point de données, pas comme un verdict.

La tarification : deux paliers, et le second est l'histoire

La tarification API standard est de 1,25 $ en entrée / 4,25 $ en sortie par million de tokens — moins cher que les 2 $/12 $ de GPT-5.6 Terra, plus cher que les 0,20 $/1,20 $ de Luna après sa baisse, à peu près au milieu du tableau. Rien de remarquable en soi.

Le palier contributeur n'a, lui, rien d'anodin : 0,10 $ en entrée / 0,20 $ en sortie, avec une entrée mise en cache à 0,002 $ — environ 12× et 21× moins cher que le tarif standard — en échange d'une autorisation explicite d'entraîner les futurs modèles de Meta sur vos prompts et vos réponses.

Les paliers gratuits et économiques de chaque laboratoire font déjà quelque chose d'implicitement similaire ; les conditions d'utilisation des produits de chat grand public autorisent discrètement l'entraînement sur les conversations depuis des années. Ce qui change ici, c'est que Meta a nommé le chiffre. Une remise de plus de 90% pour des droits d'entraînement n'est pas une case cochée enfouie dans une mise à jour des CGU — c'est un prix, fixé délibérément, qui donne une valeur en dollars explicite à ce que la plupart des produits offrent par défaut sans qu'on le remarque, à charge pour l'utilisateur de s'en désinscrire. C'est la déclaration publique la plus claire à ce jour de ce que valent réellement les données d'usage des développeurs pour un laboratoire qui construit un modèle de codage, exprimée comme une remise plutôt que comme une clause dissimulée.

À surveiller ensuite

• La remise du palier contributeur devient le modèle à suivre. Dès qu'un grand laboratoire tarife explicitement les droits sur les données plutôt que de les enfouir, attendez-vous à ce que les concurrents égalent la transparence ou soient sommés d'expliquer pourquoi ils ne le font pas.
• Les agents de fond persistants seront copiés plus vite que la tarification. L'architecture est ici la véritable idée transposable ; tout fournisseur de harnais qui observe ce lancement vient de voir les sous-agents à portée de session paraître dépassés.
• L'étude de cas sur l'optimisation de kernels appelle une réplication. C'est aujourd'hui un seul cas d'usage exécuté par Meta elle-même ; l'étape naturelle suivante pour quiconque doute de la courbe est de faire tourner la même tâche sur les mêmes modèles de façon indépendante.

Références : Meta AI Research — Introducing Muse Code and Muse Spark 1.2 · VentureBeat — Meta entre dans la guerre du codage IA · MarkTechPost — couverture de la bêta Muse Code · BigGo Finance — le palier contributeur · couverture liée : La guerre des prix que personne ne mène vraiment · Mixture-of-Kittens · LFM2.5-2.6B