Meta a lancé aujourd'hui Muse Code, un agent de programmation en ligne de commande, en version bêta publique pour macOS et Linux. Il s'appuie sur Muse Spark 1.2, une mise à jour orientée code, co-entraînée spécifiquement pour fonctionner avec lui.
L'architecture : des agents qui n'oublient plus d'un tour à l'autre
Le vrai pari de Muse Code, ce sont les agents d'arrière-plan persistants. La plupart des harnais de programmation créent un sous-agent neuf pour chaque tâche : explorer le dépôt, faire le travail, jeter le contexte, tout recommencer au tour suivant. Les agents spécialisés de Muse Code, eux, « restent actifs pendant toute la session, au lieu d'être créés pour des tâches isolées » : un agent qui a déjà exploré un dépôt n'a donc pas à le réexplorer à chaque nouvelle demande. Ils travaillent de façon autonome en arrière-plan et choisissent le moment de rendre compte à l'agent principal, au lieu d'être interrogés en permanence.
L'autre apport concret est un journal d'événements local : chaque appel au modèle, chaque exécution d'outil, chaque validation et chaque modification vient s'inscrire dans une source unique de vérité. L'exécution devient ainsi reproductible à l'identique et sûre en cas de redémarrage : après un plantage, l'agent repart exactement d'où il s'était arrêté, sans avoir à reconstituer un état ni à perdre la session. C'est la même intuition que le noyau d'entraînement déterministe de Cursor et que la capture de trajectoires par proxy de harnais chez Liquid, appliquée cette fois à l'exécution et non à l'entraînement. Une session d'agent que l'on peut auditer et reprendre n'a rien à voir avec une session qu'on ne peut que relancer de zéro.
Trois commandes intégrées viennent compléter cette boucle : /plan transforme une tâche en un plan que le développeur doit valider avant exécution, /grill met ce plan à l'épreuve avant qu'une seule ligne de code ne soit écrite, et /goal travaille vers un objectif défini plutôt que vers une séquence d'instructions figée. C'est l'ordre qui est intéressant — planifier, puis soumettre le plan à la contradiction, et n'exécuter qu'ensuite —, car il place le point de contrôle avant la partie coûteuse d'une tâche longue, et non après.
Muse Spark 1.2 a été co-entraîné pour tirer parti de tout cela : Meta affirme qu'il « atteint ses meilleures performances et sa meilleure ergonomie sur le code lorsqu'il est associé » à Muse Code, et non qu'il s'agirait d'un modèle généraliste s'y exécutant par hasard. Concrètement, l'entraînement a mobilisé des trajectoires de harnais obtenues par échantillonnage avec rejet et des ajustements de recette calibrés pour les objectifs, la compaction et les sous-agents, ainsi qu'une intégration directe de la boîte à outils de Muse Code. Voilà un modèle entraîné contre le harnais réel avec lequel il est livré, et non reconverti après coup — le même couplage que celui décrit par Liquid pour l'apprentissage par renforcement agentique de LFM2.5 dans de vrais harnais, étendu ici à un harnais que Meta maîtrise de bout en bout.
Les données d'entraînement reposent en outre sur une boucle d'auto-amélioration qui mérite d'être nommée : Meta s'est servi de Muse Spark 1.1 pour produire des environnements de programmation exigeants et des grilles de suivi d'instructions, puis lui a fait noter des solutions candidates au regard de ces exigences qu'il avait lui-même générées. Une manière industrialisable de fabriquer un jeu d'entraînement pour la version 1.2, sans attendre de nouvelles tâches annotées par des humains. C'est une cousine allégée de la distillation par professeurs qu'LFM2.5 emploie avec MOPD : le checkpoint précédent ne se contente pas de produire les données, il corrige aussi les copies de son successeur.
Les gains par rapport à la version 1.1 sont réels, si l'on en croit les 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, le modèle n'arrive que troisième : DeepSWE 1.1 situe Muse Spark 1.2 à 59,3 %, derrière Claude Opus 5 (65,0 %) et GPT-5.6 Terra (64,8 %). Sur son propre benchmark interne, en revanche, il devance Terra (70,6 contre 65,4) et Gemini 3.6 Flash (63,9) — écart à lire comme ce blog lit tout graphique auto-évalué par un éditeur : réel, mais pas neutre.
L'étude de cas que Meta a vraiment menée : 24 heures d'optimisation de noyaux
Derrière l'argumentaire architectural se cache le seul résultat de ce lancement qui ne soit pas un tableau de benchmark figé : une exécution agentique réelle. Et elle est plus instructive que les classements ci-dessus, précisément parce qu'elle est plus étroite.
La tâche : optimiser des noyaux GPU KDA et MLA pour NVIDIA Hopper, de manière itérative — écrire, compiler, profiler, améliorer, recommencer — face à une référence fournie, sur plus de 1 000 appels d'outils et jusqu'à 24 heures, à l'intérieur de l'environnement agentique de Muse Code. Meta a tracé l'accélération obtenue par rapport à cette référence, en fonction du nombre cumulé d'appels d'outils, pour six modèles :
| Modèle | Accélération finale vs référence |
|---|---|
| Claude Opus 5 | +75,4 % |
| Claude Opus 4.8 | +67,1 % |
| GPT-5.6 Sol | +62,9 % |
| Muse Spark 1.2 | +61,1 % |
| GPT-5.6 Terra | +47,7 % |
| Gemini 3.6 Flash | +39,1 % |
Deux enseignements se lisent sur la courbe plutôt que sur le seul point d'arrivée. D'abord, Muse Spark 1.2 plafonne tôt — un bond net jusqu'à environ 60 % en quelques centaines d'appels d'outils —, et il devance même GPT-5.6 Sol sur une longue portion médiane, avant que celui-ci ne comble l'écart et ne le dépasse de justesse au décompte final. Ensuite, les deux modèles Claude prennent l'avantage d'emblée et le conservent : Opus 5 termine avec 14 points d'avance, un écart que cette tâche ne comble jamais.
Le tableau est plus honnête que ne le laissent croire les classements ci-dessus, dans les deux sens. Il confirme que Muse Spark 1.2 rivalise réellement avec le milieu de gamme des modèles de programmation de pointe sur une tâche longue et authentiquement difficile, et pas seulement sur des benchmarks calibrés pour être franchissables. Mais il s'agit d'un cas unique, choisi et exécuté par Meta, dans un domaine — l'optimisation de noyaux GPU — qui recoupe très exactement ce pour quoi ce modèle a été réglé. À retenir comme un indice, pas comme un verdict.
La tarification : deux paliers, et c'est le second qui compte
Le tarif d'API standard s'établit à 1,25 $ en entrée et 4,25 $ en sortie par million de tokens : moins cher que les 2 et 12 $ de GPT-5.6 Terra, plus cher que les 0,20 et 1,20 $ de Luna après sa baisse. Soit à peu près le milieu du tableau. Rien de remarquable en soi.
Le palier contributeur, en revanche, n'a rien d'anodin : 0,10 $ en entrée et 0,20 $ en sortie, avec une entrée mise en cache à 0,002 $ — soit environ douze et vingt et une fois moins cher que le tarif standard —, en échange d'une autorisation explicite d'entraîner les futurs modèles de Meta sur vos requêtes et vos réponses.
Les paliers gratuits et économiques de tous les laboratoires font déjà, implicitement, quelque chose d'équivalent : les conditions d'utilisation des assistants grand public autorisent discrètement l'entraînement sur les conversations depuis des années. La nouveauté, c'est que Meta a mis un chiffre dessus. Une remise de plus de 90 % contre des droits d'entraînement, ce n'est pas une case cochée au fond d'une mise à jour des conditions générales : c'est un prix, délibérément fixé. Il met une valeur en dollars sur ce que la plupart des produits obtiennent par défaut, sans qu'on le remarque, et à charge pour l'utilisateur de s'y opposer. C'est à ce jour la déclaration publique la plus claire sur ce que valent réellement les données d'usage des développeurs pour un laboratoire qui construit un modèle de programmation — formulée comme une remise plutôt que dissimulée dans une clause.
À surveiller ensuite
- La remise du palier contributeur fera école. Dès lors qu'un grand laboratoire met ouvertement un prix sur les droits d'usage des données au lieu de les enfouir, ses concurrents devront s'aligner sur cette transparence — ou expliquer pourquoi ils s'y refusent.
- Les agents d'arrière-plan persistants seront copiés plus vite que la tarification. C'est ici l'architecture qui constitue la vraie idée transposable : tout éditeur de harnais qui regarde ce lancement vient de voir les sous-agents limités à une seule tâche prendre un sérieux coup de vieux.
- L'étude de cas sur l'optimisation de noyaux appelle une réplication. Il s'agit pour l'instant d'un cas unique, exécuté par Meta elle-même ; l'étape suivante, pour qui doute de la courbe, consiste à refaire tourner la même tâche sur les mêmes modèles, de façon indépendante.