Muse Wonder Full n'est pas le modèle de l'API

Meta a lancé Muse Wonder et Muse Wonder Full le 12 octobre 2026, mais Full, le modèle le plus capable, n’est pas disponible dans la Meta Model API. Il exige un abonnement Muse Code compatible. Cela change ma lecture du lancement : les meilleurs résultats de Full justifient de tester Full ; une intégration API a besoin de données sur le modèle Wonder qu’elle peut réellement appeler. [1] [2]

Peut-on utiliser Muse Wonder Full par API ?

Non. Meta Developers précise que Full est réservé aux abonnements Muse Code et que choisir max sur Wonder ne sélectionne pas Full. Le modèle de l’API s’appelle muse-wonder-1.0. Full est une variante plus capable, accessible autrement, et non un autre nom pour le niveau de raisonnement maximal de Wonder. [2]

Cette distinction compte avant toute comparaison de benchmarks. Si je choisis un modèle pour un agent API existant, la colonne Wonder est le bon point de départ. Si je cherche un agent de terminal et que je suis prêt à m’abonner, Full entre dans la comparaison, avec les outils et les limites de Muse Code.

L’abonnement est aussi lié à l’identifiant Muse Code créé pendant la configuration initiale. La documentation de Meta précise que cet identifiant est réservé à Muse Code ; les clés API supplémentaires sont facturées séparément à l’usage. Payer l’abonnement ne rend donc pas Full accessible à n’importe quel client API. [6]

Cette distinction est plus utile que d’y voir une simple répétition de la confusion autour du lancement et des benchmarks de Muse Spark 1.3. Ici, Meta documente clairement la séparation. Il reste à associer chaque résultat au bon nom de modèle.

Que montrent vraiment les benchmarks de Muse Wonder ?

L’écart entre Wonder et Full est faible sur un test de programmation et plus grand sur un autre. Meta Developers publie des résultats presque identiques sur DeepSWE 1.1, alors que Full devance Wonder de 4,4 points de pourcentage sur SWE-Marathon. Cela invite à examiner chaque tâche, plutôt qu’à voir une grande amélioration dans tous les résultats de Full. [3]

L’avance de Full est de 0,2 point de pourcentage sur DeepSWE, contre 4,4 sur SWE-Marathon. Sans estimation de l’incertitude ni répétitions, je ne m’appuierais pas sur le premier écart pour défendre un avantage significatif. Le second me donne une raison plus précise de tester Full sur un projet conséquent qui demande de nombreuses étapes.

La fiche du modèle de Meta explique pourquoi il faut lire ces lignes séparément. DeepSWE 1.1 comprend 113 tâches issues de 91 dépôts, évaluées par des tests fonctionnels et de non-régression. Meta attribue les résultats de Wonder et Full à Datacurve. SWE-Marathon évalue plutôt des projets de grande ampleur à l’aide de leurs tests exécutables ; la fiche attribue cette ligne à Abundant AI. [4]

La même fiche indique que les résultats des concurrents sur SWE-Marathon utilisent des produits comme Codex et Claude Code. La ligne entière ne constitue donc pas une comparaison contrôlée dans un harness commun. Le harness est le logiciel qui entoure le modèle : outils, instructions et boucle d’exécution. Cela n’annule pas les résultats, mais change la question à laquelle ils répondent. Ils comparent les systèmes évalués sans isoler la qualité du modèle. C’est le problème que j’aborde dans l’analyse des capacités différentes derrière des scores de benchmark proches. [4]

Combien coûte l’API de Muse Wonder ?

Meta Developers affiche Wonder à 4 dollars par million de tokens d’entrée sans cache, 0,20 dollar par million de tokens d’entrée en cache et 20 dollars par million de tokens de sortie. Wonder n’a pas de réduction via le mode contributeur (Contributor mode) dans l’API, et les prix publiés n’ajoutent pas de supplément pour les contextes longs. Ce sont les tarifs de Wonder, pas un prix par token pour Full. [5]

Une requête hypothétique comprenant 100 000 tokens d’entrée sans cache et 10 000 tokens de sortie coûte 0,60 dollar : 0,40 pour l’entrée et 0,20 pour la sortie. Si toute l’entrée pouvait être servie depuis le cache, les mêmes volumes coûteraient 0,22 dollar. Ces exemples excluent les outils facturés séparément et les requêtes suivantes. Meta facture la recherche web 2,50 dollars pour 1 000 requêtes, en plus des tokens. [5]

Pour un agent, le coût utile est celui de la tentative entière. Des appels d’outils répétés renvoient davantage de contexte, les approches infructueuses consomment des tokens, et une correction peut exiger une nouvelle exécution. Une grille tarifaire me dit combien coûtent les tokens. Elle ne me dit pas combien Wonder en utilisera pour livrer une modification que je peux accepter.

Je n’associerais donc pas les tarifs API de Wonder au meilleur score de Full pour présenter l’ensemble comme une bonne affaire. Ce serait réunir le résultat d’un modèle et le prix d’un autre. Je ne diviserais pas non plus le prix mensuel d’un abonnement par un nombre supposé de tâches : le résultat dépendrait de l’usage réel et des limites de l’offre. La différence entre prix par token et coût mesuré par tâche compte aussi dans la comparaison de GPT-6.1 Sol.

Active Memory remplace-t-il la gestion du contexte ?

Meta AI Research décrit Active Memory comme la conservation d’informations pertinentes entre les conversations. Active Focus désigne la poursuite d’un objectif malgré les obstacles et les changements. Ces capacités méritent un test, mais leur description ne dit pas à elle seule comment un agent API donné conservera l’état de son projet. [7]

L’intégration doit toujours répondre à une question pratique : quelles informations le modèle recevra-t-il à la reprise du travail ? Un modèle capable de retrouver une exigence n’est utile que si le système la conserve et lui donne les bonnes informations. Je le testerais avec une exigence modifiée et une ancienne note contradictoire, puis je vérifierais laquelle l’agent suit.

Je garderais donc une gestion explicite du contexte pour les agents de programmation pendant les essais de Wonder. Une grande fenêtre de contexte et une fonction de mémoire annoncée ne rendent pas évidentes les instructions actuelles du dépôt, les décisions acceptées ou les tâches inachevées. Le résultat utile est un agent qui reprend avec les bonnes contraintes, pas un agent qui se contente de réciter une phrase.

Quand Full vaudrait-il le prix de l’abonnement ?

Full gagnerait sa place chez moi s’il terminait du travail difficile avec moins de corrections que l’alternative accessible par API. L’écart plus grand sur SWE-Marathon me donne une raison de le tester sur des tâches longues, mais je mesurerais les résultats acceptés et le temps écoulé avant de lui attribuer un rôle.

Je partirais d’une modification connue du dépôt, avec le même commit initial et les mêmes tests d’acceptation, et je noterais les tentatives ratées comme les réussites. Pour Wonder par API, je conserverais les frais de tokens et d’outils. Pour Full dans Muse Code, je relèverais l’usage de l’abonnement, l’attente et mes corrections ultérieures. Cela préserve la distinction entre le modèle que j’appelle et le produit auquel je m’abonne.

Avant d’utiliser du code privé dans cet essai, je vérifierais aussi le mode contributeur. La documentation des abonnements de Meta indique qu’il est activé par défaut et permet l’entraînement sur le contenu envoyé en échange d’un usage accru. Il peut être désactivé, et Full reste disponible dans les offres compatibles dans les deux modes. Ce choix fait partie de la préparation du test puisqu’il change les conditions de traitement du code. [6]

Devant un résultat impressionnant de Muse Wonder, ma première question porte donc sur le nom exact du modèle. Une fois ce point éclairci, je peux choisir un test adapté à mon accès réel et déterminer combien me coûte le travail terminé.