Muse Spark 1.1 dévoilé
(ai.meta.com)- Muse Spark 1.1, dévoilé par Meta Superintelligence Labs, est un modèle de raisonnement multimodal destiné aux tâches agentiques, avec des capacités renforcées par rapport à son prédécesseur en matière d’utilisation d’outils et d’ordinateur, de codage et de compréhension multimodale
- Son point clé est de prendre en charge la planification et l’orchestration à travers des apps et services externes, et de se généraliser en zero-shot aux native tools, aux MCP servers et aux custom skills
- Il gère activement une fenêtre de contexte de 1 million de tokens afin de rechercher des informations issues de travaux passés, puis de compresser et conserver le contexte essentiel nécessaire aux étapes suivantes
- Les développeurs peuvent accéder au modèle via la Meta Model API, disponible en preview publique, et l’utiliser en mode « Thinking » dans l’app Meta AI et sur meta.ai
- Meta indique avoir mené des évaluations de sécurité avant déploiement selon l’Advanced AI Scaling Framework, et estime que le modèle reste dans les marges de sécurité pour les catégories Chemical & Biological, Cybersecurity et Loss of Control
Positionnement et modes d’accès de Muse Spark 1.1
- Muse Spark 1.1 est le dernier modèle de Meta Superintelligence Labs, présenté comme une mise à niveau majeure par rapport à Muse Spark
- Il s’agit d’un modèle de raisonnement multimodal pour les tâches agentiques, avec des améliorations mises en avant dans les domaines suivants
- Utilisation d’outils
- Utilisation d’ordinateur
- Codage
- Compréhension multimodale
- Ce lancement, accompagné de la publication de Muse Image, est présenté comme une étape vers la vision de « personal superintelligence » de Meta
- Les développeurs peuvent accéder à Muse Spark 1.1 via la Meta Model API, disponible en preview publique
- Dans l’app Meta AI et sur meta.ai, il est proposé en mode « Thinking »
Tâches agentiques et traitement des longs contextes
- Il planifie et orchestre les flux d’exécution dans des tâches d’agent personnel couvrant plusieurs apps et services externes
- Il se généralise en zero-shot aux native tools, aux MCP servers et aux custom skills
- Il a été entraîné pour traiter des projets complexes beaucoup plus rapidement que Muse Spark
- L’agent principal collecte le contexte, élabore un plan, puis délègue l’exécution à des subagents parallèles
- Les subagents suivent les tâches qui leur sont confiées, comprennent les outils disponibles et remontent à l’agent principal lorsque c’est nécessaire
- Il gère activement une fenêtre de contexte de 1 million de tokens
- Il mémorise les actions effectuées
- Il recherche des informations issues de travaux bien antérieurs
- Il compresse le contexte afin de conserver les étapes clés nécessaires aux travaux suivants
Automatisation de l’utilisation d’un ordinateur
- Muse Spark 1.1 se distingue dans les workflows d’utilisation d’ordinateur qui passent d’une application à l’autre et où les informations changent en temps réel
- Il conserve le contexte sur de longues sessions, s’adapte à l’évolution des exigences et explore des interfaces inconnues avec une intervention humaine minimale
- Il ne traite pas toujours les tâches desktop uniquement clic par clic, mais choisit selon la situation entre automatisation et manipulation directe
- Il écrit des scripts lorsque l’automatisation est plus rapide
- Il utilise les clics lorsque l’interaction directe est simple
- Il regroupe plusieurs actions à chaque étape
- Dans l’exemple de préparation d’un dîner, il reconnaît l’apparition d’un nouveau contexte pendant le processus de commande et effectue les mises à jour nécessaires sans intervention de l’utilisateur
Performances en codage et workflows de développement
- Les performances de Muse Spark 1.1 ont fortement progressé sur des tâches de codage réelles impliquant de grands codebases complexes
- Il peut diagnostiquer et corriger des bugs complexes, implémenter de nouvelles fonctionnalités dans des systèmes de niveau entreprise et réaliser des migrations de code à grande échelle
- Il affiche de fortes améliorations par rapport au premier modèle dans des cas d’usage comme la création d’applications web et les questions-réponses end-to-end
- Il a été entraîné pour s’adapter facilement à divers harness et gérer de manière fiable des actions multitours complexes
- planning mode
- goal conditioning
- subagent delegation
- Il prend en charge les fonctions courantes de codage agentique comme context compaction
- Dans la démo de débogage OpenCode, il crée une app web de chat, détecte les échecs visibles par l’utilisateur grâce à des captures d’écran automatiques, remonte jusqu’au code concerné pour le corriger, puis vérifie les changements
- Les développeurs et chercheurs internes de Meta utilisent Muse Spark 1.1 au quotidien, et le modèle montre une nette amélioration par rapport à Muse Spark sur Meta Internal Coding Bench, avec des résultats compétitifs face aux principales alternatives
- Les chercheurs utilisent aussi Muse Spark 1.1 dans leurs workflows pour automatiser des tâches de développement et d’évaluation de modèles
- Dans l’exemple d’évaluation DeepSWE, il auto-évalue dans OpenCode une partie des tâches DeepSWE à plusieurs niveaux d’intensité de raisonnement, puis génère un tableau de bord d’analyse fondé sur les résultats
Compréhension multimodale et exécution
- Muse Spark 1.1 est également performant sur les tâches qui combinent perception, raisonnement multimodal et utilisation d’outils
- Il peut interagir avec des environnements réels pour produire des résultats fondés
- Génération de livrables de code à partir de supports visuels
- Génération de légendes très détaillées pour des images et vidéos
- Exécution de workflows agentiques pour des cas d’usage multimodaux
- Ses capacités multimodales sont particulièrement utiles dans les situations nécessitant à la fois perception et action
- Il inspecte le visuel et l’audio
- Il préserve les détails au fil de longs workflows
- Il utilise ces détails lorsqu’il manipule un ordinateur au nom de l’utilisateur
- Dans l’exemple de l’agent Facebook Marketplace, il extrait des photos utiles à partir d’une vidéo filmée au smartphone, déduit le produit, puis manipule le navigateur de l’utilisateur pour créer une annonce Marketplace
Évaluation de sécurité
- Avant le déploiement, Meta a mené une vaste évaluation de sécurité selon l’Advanced AI Scaling Framework
- Ce framework définit les évaluations, les modèles de menace et les critères de déploiement pour les modèles les plus avancés de Meta
- Les catégories évaluées incluent les frontier risks suivants
- Chemical & Biological
- Cybersecurity
- Loss of Control
- Selon l’évaluation de Meta, Muse Spark 1.1 fonctionne dans les marges de sécurité pour toutes les catégories de frontier risk
- Il montre une forte résistance aux jailbreaks directs, aux attaques indirectes provenant de données non fiables, au prompt injection et aux attaques sur developer-prompt
- Cela se traduit par une meilleure adversarial robustness, ainsi qu’une réduction du taux d’hallucination et de la sycophancy
- L’ensemble des éléments relatifs à la sécurité est documenté dans le Muse Spark 1.1 Evaluation Report
Premiers retours de partenaires et prochaines étapes
- Avec la preview publique de la Meta Model API, les développeurs peuvent pour la première fois commencer à construire sur Muse Spark 1.1
- Les premiers partenaires le considèrent comme un modèle de fondation capable de traiter des workloads agentiques à grande échelle en combinant long contexte, codage et capacités de raisonnement
- Amjad Masad, CEO de Replit, souligne qu’un seul modèle réunit un contexte de 1 million de tokens, la prise en charge multimodale des images, vidéos et PDF, une recherche intégrée avec citations, des sorties structurées, des appels d’outils parallèles et des packages compatibles OpenAI
- Saoud Rizwan, CEO de Cline, explique avoir voulu proposer un accès anticipé aux développeurs de Cline parce que le modèle combine une forte utilisation des outils et un niveau de prix permettant d’exécuter à grande échelle des workloads de codage réels
- Yashodha Bhavnani, de Box, estime que Muse Spark a montré, sur le jeu d’évaluation des tâches d’entreprise de Box, des capacités entreprise compétitives face aux principaux modèles frontier actuels
- Dave Morin, de l’OpenClaw Foundation, décrit Muse Spark 1.1 comme un modèle rapide et puissant pour l’exécution agentique
- Meta indique entraîner des modèles plus performants et prévoit de les partager à l’avenir
1 commentaires
Avis de Hacker News
Le rapport lié contient beaucoup plus de détails : https://ai.meta.com/static-resource/muse-spark-1-1-evaluatio...
Dans les détails de Terminal-Bench-2.1, il est indiqué que « 89 tâches Terminal-Bench 2.1 du dépôt officiel ont été évaluées avec un harness d’agent limité aux outils bash, avec des ressources plafonnées à 6 cœurs CPU et 8 Go de RAM », mais dans ces conditions, le résultat est disqualifié
Chaque tâche de benchmark terminal a sa propre limite de CPU et de RAM, et dépasser l’une ou l’autre entraîne une disqualification. Pour tbench-2.1, sur 89 tâches, 0 autorisent 6 cœurs CPU, et seulement 8 autorisent 8 Go de RAM
Ce genre de benchmarking douteux retire tout le plaisir de construire un harness pour améliorer les performances d’un modèle sur un benchmark. Parce que, quoi qu’on fasse, on ne peut pas battre les chiffres inexacts affichés en gros titre. C’est probablement pour cela que ce modèle n’apparaît pas dans le leaderboard officiel https://www.tbench.ai/leaderboard/terminal-bench/2.1
En tant qu’ex-employé de Meta, c’est un peu amer, mais pas très surprenant. Après la fin du PSC et avant de passer à la suite, faire monter les chiffres était l’indicateur clé de performance
harbor / tb2.1 a-t-il limité le swap disponible lors de l’exécution Docker ? Il y avait autrefois un bug où l’exécution d’instances Docker pouvait utiliser plus de mémoire que ce qui était spécifié. Certaines tâches d’origine étaient quasiment impossibles à terminer sans utiliser le swap, et si l’on empêchait Docker d’y accéder, même la solution oracle ne passait pas
De mémoire, crack-7z-hash et filter-js-from-html avaient ce problème, mais je ne les ai pas regardés depuis des mois, donc je n’en suis pas certain
J’ai pu l’essayer en avance pendant quelques jours, et pendant ce temps j’ai pu créer un plugin pour LLM. On peut tester le modèle dans le terminal comme ceci
uv tool install llmllm install llm-meta-aillm keys set meta-ai# paste API key herellm -m meta-ai/muse-spark-1.1 "Generate an SVG of a pelican riding a bicycle"Le résultat est ici : https://tools.simonwillison.net/markdown-svg-renderer#url=ht...
À titre de comparaison, le pélican produit par Muse Spark 1 est ici : https://simonwillison.net/2026/Apr/8/muse-spark/
Zuck ferait peut-être mieux de se concentrer sur un rôle de spoiler du marché des modèles plutôt que sur une concurrence frontale
Il n’a pas besoin de rattraper le chiffre d’affaires des modèles d’Anthropic ou d’OpenAI, seulement de parvenir à l’amputer de 99 %. Continuer à dépenser des milliards de dollars dans le développement de modèles frontier, les publier en poids ouverts, et transformer les modèles de codage en commodité générique. Il faudra aussi un bon harness de référence open source
Très peu de personnes sont en position de le faire tout en ayant une logique business derrière. De toute façon, le mouvement ira probablement dans cette direction, et il peut l’accélérer considérablement. Comme les compilateurs l’ont fait, il faut espérer que les modèles passent de produits propriétaires à des commodités génériques
Ce pourrait être l’une des meilleures choses que Zuck puisse faire pour le monde
Le prix est absurdement bon. 1,25 $ par million de tokens en entrée, 4,5 $ en sortie, et les entrées mises en cache sont à 0,15 $
https://dev.meta.ai/docs/getting-started/pricing-rate-limits
J’étais en train de tester le remplacement de Haiku et Sonnet par Grok 4.5, et je compte aussi essayer celui-ci. Le prix du cache, en particulier, est beaucoup moins cher
Grok 4.5 est sorti à 2 $/6 $, mais facture discrètement 0,50 $ par million de tokens d’entrée mis en cache. C’est aussi cher qu’Opus 4.8
Je ne comprends vraiment pas pourquoi quelqu’un voudrait dépenser plus de 1,50 $ par million de tokens en sortie. Alors 15 à 50 $, n’en parlons même pas. Est-ce qu’il y a vraiment des consommateurs qui paient à l’usage ?
Jusqu’à hier encore, j’avais l’impression que le sentiment dominant était qu’OpenAI et Anthropic avaient pris une avance irréversible, mais maintenant xAI et Meta ont au moins sorti des modèles pratiques et compétitifs, et moins chers
Bien sûr, avec Fable, et probablement bientôt GPT-6, l’idée que les deux labos en tête restent devant tient encore, mais ce n’est pas une partie déjà totalement pliée comme le disaient les faiseurs d’opinion
L’attente autour de GLM 5.2 était déjà forte avant cela. xAI ou Meta n’ont pas créé un grand écart d’une autre manière ; on est plutôt sur des résultats et des prix proches de GLM 5.2
Personnellement, je n’aime pas particulièrement Meta, mais je reconnais ça. Plus il y a de concurrence, mieux c’est pour les consommateurs, et aussi pour les entreprises
Le fait que les modèles chinois, Grok, Meta, Google, OpenAI et Anthropic soient tous en concurrence, je vois ça comme une victoire. Tant que ces tokens subventionnés sont disponibles, je construis frénétiquement des choses pour en profiter au maximum
D’un côté, il devient plus facile de créer des produits, donc davantage de gens vont en créer, et il y aura plus de produits et de fonctionnalités. Beaucoup de non-techniciens essaieront aussi, mais ils finiront par être bloqués, et auront donc besoin d’ingénieurs. Le volume total de produits que créeront des entreprises tech expérimentées, des fondateurs non techniques et de futurs fondateurs sera énorme. Le scénario haussier selon lequel il faudra davantage d’ingénieurs logiciels dans un avenir proche est là
À l’inverse, dans environ un an, les gens auront créé quantité de ces produits, mais la plupart ne parviendront pas à les commercialiser, à les vendre ou à gagner de l’argent. Au final, il se pourrait qu’on n’ait pas besoin d’autant d’ingénieurs logiciels. Malgré tout, je pense que, globalement, le scénario haussier a de bonnes chances de l’emporter en effet net
Chacun permet de télécharger les poids pour une exécution locale
Je ne sais pas si la concurrence est une bonne chose ; on le verra dans quelques années. J’attends avec impatience le jour où j’aurai de nouveau un métier manuel, pour la première fois depuis longtemps
Comment est-il possible que toutes les entreprises arrivent à faire croire qu’elles sont premières sur tous les benchmarks ?
Ensuite, elles se comparent à la version précédente des modèles concurrents. Si ça ne donne toujours pas une bonne image, elles se comparent à leur propre modèle précédent
Pour être juste, si le principal point fort est le prix, il paraît plus pertinent de comparer avec des modèles au niveau de performance similaire
J’avais raté que Meta développait et lançait un modèle à poids fermés. Dommage. J’aimerais voir davantage de progrès sur les modèles américains à poids ouverts
Je l’ai fait fonctionner avec codex dans un conteneur. Pour info, il semble y avoir un bug que vous rencontrerez probablement souvent dans l’interface Codex:Muse
À mon avis, codex ne s’attendait pas à des appels d’outils côté serveur, et la façon dont Meta gère ces ID provoque une sorte d’erreur de parsing ou d’intégration. Les premières fois où j’ai lancé codex avec muse, ça échouait au premier appel non lié à une recherche web
J’ai corrigé ça, et même si, personnellement, je ne suis pas encore complètement convaincu par les appels d’outils côté serveur personnalisés et le stockage de fichiers indéfini, c’est jusqu’ici un modèle plutôt impressionnant et je prends plaisir à l’utiliser
https://github.com/accretional/awesome-muse-spark/blob/main/...
D’après les benchmarks publiés, le codage et le multimodal semblent aussi plutôt bons, mais le taux de réussite des appels d’outils paraît très élevé.
Quels cas d’usage correspondent le mieux à ce profil de performances ?
Le diagnostic de bugs est un domaine où il faut savoir un peu coder, mais surtout mieux utiliser les outils. Avec un bon rapport de diagnostic, on peut confier la correction à Opus.
Opus rédige aussi des rapports dans une certaine mesure, mais dans les documents typst, il se trompe encore souvent sur la largeur des tableaux, ce qui fait que la dernière colonne se retrouve remplie de texte alors qu’elle n’a qu’une largeur de quelques caractères.