Meta a publié Muse Code le 5 août, un agent de code en terminal pour macOS et Linux qui planifie, écrit et valide des modifications à travers de gros dépôts. Il repose sur le modèle Muse Spark 1.2, s'installe en une seule commande et répartit le travail vers des sous-agents dans des worktrees git isolés, si bien que les tâches parallèles ne touchent jamais votre copie de travail. La partie qui mérite une seconde lecture, c'est la page de tarifs. Le palier standard coûte 1,25 dollar par million de tokens en entrée et 4,25 en sortie, et Meta indique que les prompts n'y servent pas à l'entraînement. Le palier contributeur coûte environ dix fois moins, et ce que vous cédez à la place, c'est votre code.
The short answer
Muse Code est le premier agent de code de Meta : un outil en terminal qui planifie, écrit et valide des modifications à travers de gros dépôts, bâti sur le modèle Muse Spark 1.2 et installé en une commande. Pour les grosses tâches, il se répartit en sous-agents tournant dans des worktrees git isolés, et il tient un journal d'événements local pour qu'une exécution interrompue puisse reprendre. Les tarifs prennent deux formes. Le palier standard se paie à l'usage sans entraînement sur vos prompts. Le palier contributeur coûte environ dix fois moins et exige l'autorisation d'entraîner les modèles sur tout ce que vous envoyez.
Il existe désormais un agent de code chez chaque entreprise assez grande pour avoir un modèle, et la question intéressante a cessé d'être : est-ce que ça marche. L'entrée de Meta est arrivée le 5 août sous le nom de Muse Code, en bêta publique, pour macOS et Linux, installée par une seule commande curl et pilotée entièrement depuis un terminal. Pas d'application de bureau, pas de greffon d'éditeur au lancement.
La description des capacités est devenue standard : il prend une tâche, planifie la modification, écrit le code et valide le résultat, sur un dépôt assez gros pour que vous n'ayez pas envie de le décrire à la main. Il repose sur Muse Spark 1.2, une révision du modèle orientée code adoptée par Meta après Llama, et la direction IA a été directe : l'argument, c'est le coût. Leur responsable IA l'a présenté comme une option convaincante « surtout du point de vue du coût ».
Deux éléments de conception méritent mieux que ce que la couverture du lancement leur a accordé.
Les sous-agents ont leur propre worktree
Quand une tâche est assez grosse, Muse Code la répartit entre des sous-agents parallèles, et chacun reçoit un worktree git isolé plutôt que de partager votre copie de travail.
Cela ressemble à de la tuyauterie, et c'en est, mais c'est la tuyauterie qui décide si des agents parallèles sont utiles ou dangereux. Un worktree est un second répertoire de travail rattaché au même dépôt, avec sa propre copie et son propre index. Deux agents dans deux worktrees ne peuvent pas écraser mutuellement leurs fichiers, ne peuvent pas se disputer l'index, et ne peuvent pas laisser votre propre travail non commité dans un état que vous n'avez pas demandé. Meta cite une exécution interne qui a construit six fonctionnalités à la fois sans collision, ce qui est tout l'intérêt du chiffre : le mode de défaillance évité n'est pas la lenteur, c'est la corruption.
N'importe qui peut monter cela avec git worktree add et une boucle shell, et beaucoup d'équipes l'ont déjà fait. En faire le comportement par défaut plutôt qu'un exercice laissé au lecteur est une vraie amélioration, et nous nous attendons à voir les autres agents converger dessus.
Le journal d'événements
Le deuxième élément est un journal local de ce que l'agent a fait, enregistré pas à pas : appels au modèle, invocations d'outils, approbations accordées, modifications effectuées. Son objectif affiché est la reprise après incident, et une longue exécution qui meurt à la trente-cinquième minute sans perdre trente-cinq minutes de travail vaut vraiment le coup.
Le meilleur usage reste la relecture. Un diff vous dit ce qui a changé. Il ne vous dit pas pourquoi l'agent a cru que c'était la tâche, sous laquelle de vos approbations il agissait, ni ce qu'il avait lu avant de décider. Sur une modification touchant onze fichiers, cette distinction fait la différence entre relire un correctif et relire une décision. Lisez le journal avant de fusionner quoi que ce soit dont vous seriez gêné.
Lisez la page de tarifs comme un contrat, pas comme une grille
Le palier standard est classique : 1,25 dollar par million de tokens en entrée, 4,25 par million en sortie, 0,15 par million pour l'entrée en cache, avec des limites de trois mille requêtes et quatre millions de tokens par minute et par équipe. Meta indique que les prompts et les réponses de ce palier ne servent pas à entraîner ses modèles.
C'est le palier contributeur qui devient intéressant. Environ 0,10 par million en entrée et 0,20 par million en sortie, l'entrée en cache à des fractions de centime, et une limite de soixante requêtes par minute. La contrepartie est explicite : vous autorisez Meta à entraîner ses modèles sur vos prompts et vos réponses. La presse l'a qualifié de palier le moins cher du marché, et sur l'arithmétique brute, il l'est.
Voici ce qui distingue cela d'une remise ordinaire. Un agent de code ne voit pas une question, il voit votre dépôt. Le source, la configuration, les noms d'hôtes internes, les commentaires qui expliquent pourquoi un contournement existe, la forme d'un système que personne hors de votre équipe n'a décrit publiquement. Si vous travaillez sous contrat client, sous accord de confidentialité ou sous un contrat de travail avec clause de propriété intellectuelle, le palier contributeur n'est pas une décision d'achat qu'un ingénieur prend seul. Ce n'est pas un reproche à Meta, qui a documenté l'échange clairement. C'est une note pour rappeler que ce palier a été conçu pour les particuliers et les essais, la limite de soixante requêtes le dit, et qu'il devrait y rester.
Ce que nous ferions
L'essayer sur quelque chose de réel et sans importance, sur le palier standard, et lire le journal.
Les parties de Muse Code que nous copierions sont architecturales plutôt que propriétaires. Isoler les agents parallèles dans des worktrees est juste, et vous pouvez le faire dès aujourd'hui avec l'agent que vous utilisez déjà. Conserver une trace durable et pas à pas d'une session d'agent est juste, et largement absent ailleurs. Ces deux idées survivront aux tarifs de n'importe quel produit.
Sur la question du palier, notre position est simple. Si le code est le vôtre et que l'enjeu est faible, le palier contributeur est une bonne affaire et vous devriez la prendre. Si le code appartient à un client ou à un employeur, le prix n'est pas le nombre affiché sur la page.
Sources et pour aller plus loin
- Meta debuts Muse Code to take on Anthropic and OpenAI, CNBC, 5 août 2026
- Meta launches Muse Code, an AI agent for large code bases, TechCrunch, 5 août 2026
- Meta enters the AI coding wars with Muse Spark 1.2 and Muse Code, VentureBeat, 5 août 2026
- Meta launches Muse Code for macOS and Linux, 9to5Mac, 5 août 2026
- Détail des paliers tarifaires, BigGo Finance, 5 août 2026
- Documentation git worktree
Questions fréquentes
Que me coûte réellement le palier contributeur ?
De l'argent, non. De la confidentialité, oui. Sur le palier standard, Meta facture 1,25 dollar par million de tokens en entrée, 4,25 par million en sortie et 0,15 par million d'entrée en cache, et précise que les prompts et les réponses n'y servent pas à entraîner ses modèles. Le palier contributeur descend à environ 0,10 par million en entrée et 0,20 par million en sortie, soit à peu près douze fois moins cher à l'aller et vingt fois moins au retour, à la condition explicite que Meta puisse entraîner ses modèles sur ce que vous envoyez. Un agent de code voit tout votre dépôt : le source, la configuration, les commentaires, les noms de services internes, la forme de votre architecture. Si une partie de cela relève d'un contrat client ou d'un contrat de travail, le palier bon marché n'est pas une décision d'achat qu'un ingénieur prend seul. Il est aussi limité à soixante requêtes par minute, donc conçu pour les particuliers et les essais, pas pour une chaîne d'équipe.
À quoi sert de lancer les sous-agents dans des worktrees séparés ?
Cela élimine le pire mode de défaillance des agents parallèles : deux d'entre eux modifiant le même fichier dans la même copie de travail. Un worktree git est un second répertoire de travail rattaché au même dépôt, positionné sur son propre commit, avec son propre index. Donnez-en un à chaque sous-agent et leurs modifications sont physiquement séparées jusqu'à ce que quelque chose les fusionne. Meta indique qu'un essai a construit six fonctionnalités de jeu en parallèle sans collision, et ce chiffre porte tout l'argument : sans isolation, des agents concurrents sur une seule copie produisent un désordre qui coûte plus cher à démêler que le travail en série. Vous pouvez bâtir ce motif vous-même avec n'importe quel agent et un script shell, et beaucoup l'ont fait. L'avoir comme comportement par défaut plutôt que comme montage à refaire, c'est la vraie amélioration produit.
Pourquoi un journal d'événements local compte-t-il pour un agent ?
Parce que les longues exécutions échouent à mi-chemin et que sans trace, on recommence à zéro. Muse Code écrit au fil de l'eau un journal local des appels au modèle, des invocations d'outils, des approbations et des modifications, si bien qu'une session interrompue peut reprendre au lieu de repartir. Deux conséquences en découlent. La plus évidente est le temps : une exécution de quarante minutes qui meurt à la trente-cinquième ne vous coûte pas deux fois quarante minutes. La moins évidente est la relecture. Un agent qui a modifié onze fichiers dans un dépôt est difficile à auditer à partir du seul diff, parce que le diff montre ce qui a changé mais pas ce que l'agent croyait faire ni sous quelle approbation il agissait. Un journal pas à pas est ce qui ressemble le plus à une trace écrite chez ces outils aujourd'hui, et il mérite d'être lu avant toute fusion importante.
Dois-je quitter l'agent que j'utilise déjà ?
Pas sur la foi d'une annonce. Muse Code est en bêta publique, il tourne uniquement sur macOS et Linux, et c'est un outil en terminal sans application de bureau : la surface sur laquelle il concourt est donc étroite et déjà familière. Les vraies raisons de l'essayer sont le coût sur de gros volumes et la répartition en worktrees si vous lancez régulièrement des tâches parallèles. Les vraies raisons d'attendre sont que le modèle derrière, Muse Spark 1.2, est assez récent pour que les bancs d'essai indépendants n'aient pas suivi, et que les tarifs de bêta bougent historiquement. Notre conseil est celui que nous donnons pour chaque agent : pointez-le vers un dépôt réel mais non critique, donnez-lui une tâche dont vous connaissez déjà la réponse, et relisez chaque ligne produite avant de le laisser approcher de ce qui compte.
A-t-il besoin d'envoyer tout mon dépôt quelque part ?
Il envoie tout ce qu'il lit, ce qui sur un gros dépôt s'accumule vite. C'est vrai de tout agent de code hébergé, ce n'est pas une particularité de celui-ci, et c'est pourquoi la question du palier n'est pas théorique. L'agent tourne localement dans votre terminal, mais pas le modèle : les prompts, le contenu des fichiers qu'il décide de lire et les résultats des appels d'outils partent tous vers l'API de Meta. Le palier standard et le palier contributeur ne diffèrent que sur le sort de ces données ensuite. Si votre organisation a une règle sur les lieux où le code source peut être traité, elle s'applique ici exactement comme pour n'importe quel autre agent hébergé, et la réponse ne change pas parce que l'outil tourne dans un terminal plutôt que dans un navigateur.