Claude Opus 4.6 perd 65 points à mesure que les tâches MineExplorer se complexifient

Claude Opus 4.6 d’Anthropic a dominé MineExplorer, mais son taux de réussite est passé de 77 % sur les tâches à un saut à 12 % sur celles à quatre sauts. Le modèle n’a achevé que 41 % du benchmark au total, selon les résultats publiés par l’équipe LongCat de Meituan.

C’est cet effondrement qui constitue la véritable histoire d’Anthropic MineExplorer. Claude a bien fonctionné lorsque l’objectif nécessitait une seule étape directe. Il a peiné lorsque la réussite dépendait de la découverte et de la coordination de plusieurs prérequis implicites dans un monde en évolution.

MineExplorer mesure cet écart à travers 813 scénarios Minecraft vérifiés par des humains, d’une durée pouvant atteindre trois minutes. Il teste 18 modèles multimodaux issus de huit familles de modèles, dont des systèmes Claude, GPT et Gemini. Les auteurs du benchmark ont publié son code, son jeu de données, son flux de génération des tâches et son environnement d’évaluation.

Le résultat remet en cause une hypothèse répandue sur les agents multimodaux. Reconnaître une menace, un objet ou une ressource ne signifie pas qu’un modèle puisse conserver un plan utile à mesure que l’environnement change. MineExplorer transforme cette distinction en une courbe d’échec mesurable.

Les précédents benchmarks Minecraft examinaient la planification, le suivi d’instructions, la construction ou la connaissance du jeu. MineExplorer écarte au contraire de nombreuses tâches dépendant fortement de règles propres à Minecraft. Son objectif déclaré est plus large : une exploration combinant perception, raisonnement et action sur une trajectoire prolongée.

Le benchmark reste une prépublication, et Minecraft ne peut représenter tous les environnements physiques. Toutefois, ces résultats mettent immédiatement sous pression les affirmations selon lesquelles une vision plus performante et un contexte plus long produisent automatiquement des agents autonomes fiables.

MineExplorer transforme trois minutes en un véritable test d’agent

MineExplorer fait passer la cible de l’évaluation de la reconnaissance d’une scène à la réussite d’une séquence de décisions interdépendantes.

L’équipe LongCat a présenté MineExplorer dans une prépublication de mai 2026. Une deuxième version a suivi le 12 juin, tandis que l’équipe technique de Meituan a publié en juillet un résumé détaillé des résultats.

Chaque épisode peut durer 1 800 étapes d’environnement. Une étape représente 0,1 seconde, soit trois minutes d’interaction continue. Le monde est mis à jour après chaque action ; le modèle doit donc réévaluer en permanence ce qu’il voit et ce qu’il doit faire ensuite.

Cette durée paraît courte à l’échelle humaine. Elle est longue pour un agent qui doit observer des images, maintenir un état, sélectionner des actions et se remettre d’erreurs sur des centaines d’interactions.

Les tâches sont réparties selon leur nombre de sauts. Une tâche à un saut présente un objectif qui n’exige pas de l’agent qu’il déduise une sous-tâche implicite. Les scénarios de deux à quatre sauts ajoutent des prérequis cachés qui doivent être découverts dans l’environnement.

Imaginons un agent chargé d’atteindre un lieu protégé. L’itinéraire immédiat peut être bloqué, l’outil nécessaire peut se trouver ailleurs et des entités hostiles peuvent limiter les déplacements. L’instruction indique la destination, mais pas toutes les actions nécessaires pour l’atteindre.

MineExplorer représente chaque tâche composite par un état initial, une instruction en langage naturel, un graphe de dépendances et des jalons fondés sur des règles. Le graphe de dépendances enregistre la structure cachée de la tâche. Le modèle ne reçoit jamais ce graphe complet.

Les jalons permettent à l’évaluateur de mesurer les progrès partiels sans demander à un autre modèle linguistique de juger toute la trajectoire. Un jalon peut détecter si l’agent a trouvé un objet, pénétré dans une zone ou réalisé une action intermédiaire requise.

Les auteurs ont comparé ces résultats automatisés aux évaluations humaines des trajectoires de Claude Opus 4.6. Les ensembles de jalons achevés ont reçu des notes humaines moyennes proches de quatre sur une échelle de cinq. Les ensembles ayant entièrement échoué sont restés sous trois.

Cette concordance ne rend pas l’évaluateur parfait. Elle apporte néanmoins des éléments indiquant que l’achèvement des jalons reflète des progrès significatifs, plutôt que des événements arbitraires du jeu.

L’équipe a aussi tenté de distinguer l’exploration de l’expertise Minecraft mémorisée. Les tâches atomiques candidates ont été examinées afin d’évaluer leur dépendance aux conventions spécifiques au jeu. Les tâches dominées par des connaissances spécialisées ont été supprimées.

Ce choix de conception est important, car un agent peut échouer à un objectif Minecraft pour deux raisons très différentes. Il peut lui manquer une recette du wiki du jeu, ou ne pas réussir à relier des indices visibles à un plan réalisable.

MineExplorer cherche à mettre l’accent sur le deuxième problème. Ses 14 catégories de capacités couvrent la perception, le raisonnement et l’action. Elles incluent la perception spatiale et temporelle, le suivi des entités, la conscience des ressources, le raisonnement causal, le déplacement, la collecte, le placement, la fabrication et le combat.

Les 813 exemples publiés couvrent des dépendances d’un à quatre sauts. Le jeu de données ouvert comprend le texte des tâches, les commandes de configuration des scènes, les tâches atomiques sélectionnées, les jalons, les graphes de dépendances et des notes de conception.

Il s’agit de plus qu’un ensemble statique de questions. Les chercheurs peuvent examiner comment les scènes ont été construites, relancer les évaluations, créer des variantes plus difficiles ou utiliser l’environnement pour l’entraînement.

Cette ouverture donne au benchmark une chance d’influencer le développement des agents. Elle rend également ses hypothèses plus faciles à contester, une caractéristique importante pour un benchmark formulant de vastes affirmations sur l’exploration.

Pourquoi la première place d’Anthropic MineExplorer reste un avertissement

Claude Opus 4.6 a remporté la comparaison, mais son avance révèle à quel point tous les modèles testés restent éloignés d’un comportement fiable à long horizon.

Le benchmark a évalué 18 modèles multimodaux avancés répartis en huit familles. Claude Opus 4.6 a obtenu le meilleur taux global de réussite des tâches, atteignant 41 %.

Un résultat de 41 % peut sembler respectable si l’on ne considère que sa position au classement. Il paraît bien plus faible lorsqu’on le sépare selon la profondeur des tâches.

Claude Opus 4.6 a achevé 77 % des tâches à un saut. Son taux de réussite est tombé à 12 % sur les tâches à quatre sauts. Cette baisse de 65 points montre que des dépendances supplémentaires font plus que simplement ajouter un peu de difficulté.

Chaque prérequis caché crée une occasion supplémentaire de perdre le fil du plan. Le modèle doit repérer les éléments pertinents, déduire un objectif intermédiaire, l’exécuter correctement et préserver son lien avec l’objectif final.

Une erreur initiale peut se propager tout au long de l’épisode. Passer à côté d’une ressource nécessaire empêche l’action suivante. Choisir le mauvais itinéraire consomme des étapes et modifie la vue de l’agent. Une observation ultérieure peut alors être interprétée à partir d’un état interne déjà erroné.

C’est pourquoi le résultat Anthropic MineExplorer exerce une pression qui dépasse Anthropic. Claude était le modèle le plus performant du test. Sa courbe d’échec fait donc office de plafond pour cette configuration particulière, et non de preuve d’une faiblesse isolée de Claude.

Les résultats compliquent également le récit habituel sur la mise à l’échelle des modèles. L’article indique que des modèles plus grands et des modes de réflexion dédiés n’ont pas amélioré les performances de manière systématique.

Davantage de paramètres peuvent renforcer la perception ou le raisonnement dans le cadre d’un prompt délimité. Un environnement dynamique exige une autre capacité : maintenir un alignement utile entre la mémoire, les observations actuelles et des objectifs changeants.

Un contexte plus long ne garantit pas cet alignement. Il peut conserver d’anciennes images qui ne décrivent plus la scène présente. Ces observations peuvent entrer en concurrence avec des éléments plus récents au lieu d’aider le modèle.

Les auteurs ont testé ce problème en augmentant le nombre de cadres visuels historiques. Les performances ont fini par diminuer lorsque des observations obsolètes ont perturbé la compréhension de l’état actuel par le modèle.

Ils ont aussi examiné si les modèles avaient simplement besoin de plus de temps. Les agents en échec ont continué d’échouer même lorsque les épisodes autorisaient jusqu’à 1 800 étapes. Les tâches résolubles avaient tendance à être achevées plus tôt, tandis que des interactions supplémentaires n’ont pas sauvé beaucoup de trajectoires compromises.

Ces résultats fragilisent deux solutions faciles. Donner davantage de contexte à un agent n’équivaut pas à lui donner une meilleure mémoire. Lui donner davantage d’actions n’équivaut pas à lui donner un meilleur plan.

La pression s’étend aux développeurs qui construisent des agents d’utilisation d’ordinateur, des systèmes robotiques et des outils de recherche automatisés. Ces produits évoluent hors d’une capture d’écran figée. Leurs environnements changent en réponse à l’agent comme aux événements externes.

Un agent navigateur peut devoir trouver un dossier, modifier un filtre, interpréter la page mise à jour et vérifier l’envoi final. Un robot d’entrepôt peut devoir changer d’itinéraire après avoir découvert qu’une allée est bloquée. Un agent de recherche peut devoir réviser sa recherche après avoir découvert des éléments contradictoires.

Dans chaque cas, l’objectif visible dissimule des décisions préalables. Un modèle peut exécuter correctement chaque action isolée tout en échouant à réaliser la tâche complète.

MineExplorer ne prouve pas que les taux d’échec se transféreront directement aux navigateurs ou aux robots. Il montre que la réussite à de courts tests multimodaux offre une garantie limitée dès lors que les dépendances cachées s’accumulent.

Cette distinction devrait influencer les décisions d’achat et de déploiement. Les acheteurs devraient demander comment un agent se comporte sur des flux de travail achevés, et pas seulement si son modèle reconnaît des écrans ou génère des actions suivantes plausibles.

Le véritable problème est la navigation, pas la reconnaissance visuelle

Près de 60 % des échecs de Claude Opus 4.6 ont été attribués à la navigation, faisant du déplacement avec état le principal goulot d’étranglement du benchmark.

L’analyse des échecs de l’équipe LongCat distingue les erreurs de navigation des problèmes tels que l’interaction avec les objets ou le raisonnement sur les tâches. La navigation a représenté près de 60 % des échecs analysés.

Ce chiffre ne signifie pas que le modèle manquait simplement d’indications. La navigation dans un monde ouvert combine mémoire spatiale, reconnaissance visuelle, contrôle des actions et gestion des objectifs.

L’agent doit savoir où il se trouve, se souvenir des endroits déjà visités et déterminer si son déplacement a produit le résultat attendu. Il doit aussi décider quand abandonner un itinéraire ou explorer une autre possibilité.

Un test de vision statique n’isole qu’une partie de cette boucle. Le modèle voit une image et répond à une question. La scène ne change pas en fonction de sa réponse, et une réponse erronée ne fausse pas l’observation suivante.

Minecraft crée une boucle de rétroaction. Si l’agent tourne dans la mauvaise direction, son image suivante contient des indices différents. S’il reste bloqué contre un obstacle, des commandes de déplacement répétées consomment du temps sans faire progresser la tâche.

Le modèle doit alors diagnostiquer si l’itinéraire a échoué, si l’action a échoué ou si son plan initial était erroné. Cette distinction est difficile lorsque les observations arrivent sous forme d’images distinctes plutôt que d’une carte interne stable.

Les scores de capacités de MineExplorer renforcent cette interprétation. Claude Opus 4.6 a obtenu un score de perception de 61,91 et un score de raisonnement de 54,71. Parmi la plupart des modèles évalués, la perception dépassait l’action, tandis que l’action dépassait le raisonnement.

Les modèles pouvaient souvent identifier les détails pertinents. Ils avaient davantage de difficultés à transformer ces détails en une stratégie coordonnée capable de résister aux changements de l’environnement.

Cela crée un renversement important dans la manière dont les progrès multimodaux sont habituellement présentés. Une meilleure compréhension des images élargit ce qu’un agent peut remarquer, mais elle expose aussi la faiblesse du système de planification qui exploite ces observations.

Un modèle qui détecte dix objets pertinents doit encore décider lequel importe à cet instant. Il doit relier ce choix à l’objectif final et conserver ce lien après un changement de point de vue.

Le benchmark s’appuie sur l’approche ReAct, qui alterne raisonnement, actions et nouvelles observations. Le cadre ReAct original a été conçu pour permettre aux modèles de réviser leur raisonnement grâce aux retours de l’environnement.

MineExplorer montre où cette boucle peut se rompre sur des trajectoires plus longues. Le raisonnement se détache de l’état actuel, les actions cessent de servir l’objectif initial, ou de nouvelles observations ne déclenchent pas une révision nécessaire.

La navigation amplifie ces trois problèmes. Un agent mal positionné observe les mauvais éléments, construit une mauvaise estimation de l’état et choisit des actions ultérieures depuis une position dégradée.

C’est un problème plus difficile que de générer une chaîne de pensée plus longue. Un agent a besoin d’une représentation structurée des entités persistantes, des emplacements, des jalons accomplis, des itinéraires échoués et des dépendances non résolues.

L’historique visuel brut est un substitut médiocre. Il enregistre ce que la caméra a vu, pas ce dont l’agent devrait se souvenir.

La même distinction s’applique aux agents d’entreprise. La transcription de chaque écran précédent ne produit pas automatiquement un état de workflow fiable. L’agent doit savoir quel formulaire a été soumis, quel filtre reste actif et quelle exigence n’est toujours pas satisfaite.

Pour les systèmes incarnés, la navigation devient à la fois une épreuve physique et cognitive. Le modèle doit se déplacer dans l’espace tout en préservant la structure logique de la tâche.

La part de 60 % d’échecs attribuée à MineExplorer pointe donc vers un travail au niveau système. De meilleurs contrôleurs locaux, des cartes explicites, une mémoire causale, le suivi de progression et des politiques de récupération peuvent compter autant qu’un modèle de base plus puissant.

Ce que le benchmark mesure, et ce qu’il ne mesure pas

MineExplorer fournit un test de résistance utile, mais ses résultats restent circonscrits à un monde simulé et à une distribution de tâches définie par les chercheurs.

L’argument sceptique le plus solide concerne la validité externe. Minecraft propose un monde 3D dynamique aux règles cohérentes, mais il ne reproduit pas toutes les difficultés rencontrées dans les foyers, les usines, les bureaux ou les espaces publics.

Les robots réels font face à une physique incertaine, au bruit des capteurs, aux dommages matériels et aux contraintes de sécurité. Les agents d’utilisation informatique rencontrent des états d’application cachés, des barrières d’authentification, des pop-ups et des interfaces changeantes.

Minecraft élimine nombre de ces complications. Ses objets sont discrets, sa physique est reproductible et son environnement peut être réinitialisé à l’identique.

Ce contrôle constitue également un avantage. Les chercheurs peuvent comparer les modèles dans des conditions identiques et retracer les échecs sans mettre en danger du matériel ou des utilisateurs.

L’essentiel est de considérer MineExplorer comme un instrument de diagnostic, et non comme un score universel de l’intelligence incarnée. Un résultat de 41 % ne signifie pas que Claude achèverait 41 % de workflows réels sans rapport.

Le filtrage des connaissances du benchmark mérite aussi un examen attentif. Les auteurs utilisent des jugements de modèles de langage pour classer si les tâches atomiques reposent principalement sur des connaissances générales ou sur des conventions propres à Minecraft.

Ce processus réduit les facteurs de confusion évidents liés à la connaissance du jeu. Il ne peut toutefois pas garantir que chaque tâche retenue soit exempte d’effets de familiarité.

Des modèles entraînés sur des vidéos Minecraft, des guides ou des discussions de gameplay peuvent toujours reconnaître des agencements et comportements courants. Différentes familles de modèles ont peut-être rencontré des quantités différentes de ce type de contenu.

Le benchmark lui-même reste en cours d’élaboration, selon sa fiche arXiv. De futures révisions pourraient modifier les tâches, les prompts, les contrôleurs ou les procédures d’évaluation.

La conception du contrôleur est particulièrement importante. Un modèle multimodal manipule rarement un jeu par le seul raisonnement abstrait. Le système agent qui l’entoure convertit les sorties du modèle en commandes de déplacement et d’interaction.

Les performances reflètent donc à la fois le modèle sous-jacent et son échafaudage. Un meilleur système de cartographie ou un contrôleur bas niveau pourrait améliorer les résultats sans modifier le modèle.

Les auteurs du benchmark reconnaissent une autre limite. MineExplorer se concentre actuellement sur l’évaluation empirique, bien que son infrastructure puisse également prendre en charge l’entraînement.

L’entraînement dans l’environnement du benchmark crée son propre risque. Une fois que les développeurs optimisent directement pour des tâches publiques, les gains au classement peuvent refléter une spécialisation au benchmark plutôt qu’une exploration générale.

Le code MineExplorer, entièrement ouvert, facilite la réplication et l’extension. Il rend aussi les questions de contamination et de surapprentissage plus importantes pour les futures versions de modèles.

Les évaluations indépendantes devraient préserver des scénarios de test cachés. Elles devraient aussi faire varier les agencements des scènes, les structures de dépendances, les implémentations des contrôleurs et les formats de prompt.

Le contexte historique justifie cette prudence. MinePlanner avait auparavant publié 45 tâches Minecraft de planification à long horizon et constaté que les planificateurs établis peinaient dans de grands environnements contenant de nombreux objets.

Le benchmark MinePlanner portait sur la planification propositionnelle et numérique plutôt que sur l’exploration multimodale interactive. Ses résultats ont néanmoins montré que Minecraft peut révéler des problèmes de passage à l’échelle cachés par des domaines de planification plus restreints.

D’autres systèmes ont étudié le suivi d’instructions, la construction, la mémoire et les compétences ouvertes. Ces projets utilisent le même jeu pour des questions différentes ; leurs scores phares ne doivent donc pas être comparés directement.

La contribution spécifique de MineExplorer réside dans la combinaison d’une interaction visuelle continue, de prérequis cachés, de la construction de tâches à sauts multiples et d’une évaluation des jalons fondée sur des règles.

Sa revendication de « premier » doit être comprise dans le cadre de cette définition. Minecraft a accueilli des recherches à long horizon avant MineExplorer. La revendication de nouveauté de l’équipe concerne l’exploration multimodale en monde ouvert à l’échelle de minutes, selon sa structure d’évaluation particulière.

Une autre limite est l’absence de réactions indépendantes larges si peu de temps après la sortie. Les interprétations détaillées proviennent actuellement surtout des auteurs et de leurs canaux techniques affiliés.

Les résultats mesurés sont disponibles à l’examen, mais les explications causales restent en partie interprétatives. La forte part d’échecs de navigation, par exemple, n’isole pas complètement si la cause première relève de la cartographie, de la mémoire, de la planification ou de l’exécution des actions.

Ces incertitudes n’effacent pas le constat central. Le taux de réussite chute fortement à mesure que les prérequis cachés s’accumulent. Elles définissent ce que de futures expériences doivent distinguer.

L’open source fait de MineExplorer plus qu’un classement

Cette publication compte parce que les chercheurs peuvent tester si de meilleures mémoires, de meilleurs contrôleurs ou de meilleures méthodes d’entraînement aplanissent la courbe d’échec à long horizon.

L’équipe a utilisé un workflow multi-agents pour construire les instances du benchmark. Cinq agents spécialisés collaborent sous la direction d’un orchestrateur qui contrôle leur séquence.

Le workflow commence par une première ébauche de tâche. Des agents spécialistes et de validation débattent ensuite de la conception, identifient les incohérences et révisent la scène, le graphe de dépendances et les évaluateurs de jalons.

Selon l’évaluation humaine des auteurs, ce processus a augmenté la validité des instances d’environ 30 points de pourcentage par rapport à une base de référence à agent unique. Il a également relevé les scores de qualité d’environ 0,5 point, avec le plus grand bénéfice pour les tâches à quatre sauts.

La version finale contient 813 instances vérifiées par des humains. Un sous-ensemble difficile distinct propose 100 scénarios sélectionnés pour leur difficulté accrue.

Ce pipeline de génération répond à un problème persistant des benchmarks. Construire manuellement des centaines d’environnements interactifs est lent, tandis que les tâches générées par des modèles sans contraintes contiennent souvent des objectifs impossibles ou des évaluations défaillantes.

Associer la synthèse automatisée à une vérification humaine offre une voie intermédiaire. L’approche peut produire davantage de tâches tout en préservant un contrôle qualité.

La même méthode peut générer des scénarios d’entraînement, et pas seulement des cas de test. Les chercheurs peuvent créer des graphes de dépendances, instancier des scènes sandbox et ajouter des vérifications de jalons déterministes.

C’est important parce que les agents à long horizon doivent s’exercer sur des échecs qui se déroulent dans le temps. Les jeux de données visuels statiques ne peuvent pas enseigner la récupération après un mauvais détour ou un prérequis manqué.

L’infrastructure ouverte invite aussi à des alternatives à l’augmentation de l’échelle des modèles de bout en bout. Une équipe peut maintenir le modèle de base constant et tester des cartes spatiales explicites, une mémoire épisodique, des graphes causaux ou des planificateurs hiérarchiques.

Une autre expérience pourrait séparer la planification de haut niveau du déplacement de bas niveau. Le modèle pourrait sélectionner les objectifs tandis qu’un contrôleur spécialisé gère l’évitement des obstacles et l’exécution des itinéraires.

Les chercheurs peuvent alors se demander si les échecs de navigation reflètent une intelligence insuffisante, un contrôle moteur insuffisant ou une interface instable entre les deux.

Le benchmark peut également prendre en charge la conception de curricula. Les agents pourraient commencer par des tâches à un saut, puis progresser vers des graphes de dépendances plus profonds à mesure que leur taux de réussite se stabilise.

Toutefois, les ensembles d’entraînement et d’évaluation doivent rester distincts. Réutiliser des scénarios publics transformerait MineExplorer en test de mémorisation.

Le résultat futur le plus instructif ne sera pas un petit gain au classement. Ce sera un déclin plus faible entre les tâches à un saut et celles à quatre sauts.

Un système qui augmente le taux de réussite global tout en conservant la même courbe d’effondrement a amélioré ses compétences locales. Un système qui maintient ses performances à mesure que les dépendances s’approfondissent a amélioré sa coordination à long horizon.

Cette distinction devrait orienter les futurs rapports. Le taux global de réussite des tâches compresse plusieurs comportements en un seul chiffre. Les performances spécifiques à chaque saut révèlent où l’agent cesse de fonctionner de manière fiable.

La publication ouverte donne aux équipes externes les outils pour tester ces affirmations. Elle leur permet aussi de proposer des évaluations plus difficiles sans reconstruire toute la pile Minecraft.

Ce qu’il faut surveiller après le résultat Anthropic MineExplorer

La prochaine phase devrait se concentrer sur la réplication indépendante, l’amélioration des systèmes de navigation et des performances stables sur des tâches multi-sauts inédites.

Le premier signal est la reproduction indépendante du score global de 41 % et de la baisse de 77 % à 12 %. Les chercheurs devraient réexécuter Claude Opus 4.6 et d’autres modèles avec des réglages documentés de contrôleur, de prompt et d’environnement.

Une reproduction proche renforcerait l’affirmation selon laquelle les prérequis cachés entraînent un schéma d’échec général. De grands écarts suggéreraient que l’échafaudage agentique contribue davantage que ne l’indique le classement initial.

Le deuxième signal est de savoir si des systèmes explicites d’état et de navigation réduisent la catégorie d’échec dominante. Des expériences utiles devraient comparer l’historique brut des images à des cartes, une mémoire structurée, des graphes de tâches causaux et des politiques de récupération d’itinéraire.

Une amélioration significative réduirait les échecs de navigation sans sacrifier les performances de raisonnement ou d’action. Augmenter simplement la fenêtre de contexte ne répondrait pas à la critique centrale du benchmark.

Le troisième signal est la performance de modèles plus récents sur des scénarios à quatre sauts tenus à l’écart. Les développeurs devraient rapporter le taux de réussite par nombre de sauts, et non uniquement une moyenne globale.

Un modèle qui obtient de meilleurs résultats sur les tâches à un saut tout en restant proche de 12 % sur celles à quatre sauts n’a pas comblé l’écart à long horizon. De meilleurs résultats sur des structures de dépendances inédites fourniraient des preuves plus solides d’une exploration générale.

Les lecteurs devraient aussi surveiller si les développeurs de modèles adoptent MineExplorer ou des évaluations associées dans leurs fiches système officielles. Une telle inclusion indiquerait que l’interaction multimodale de longue durée devient un objectif standard de capacité.

Pour les développeurs, la leçon pratique est déjà claire. N’évaluez pas un agent uniquement à travers des actions isolées ou des démonstrations soignées.

Testez des workflows complets avec des prérequis cachés, un état changeant et des possibilités de récupération. Mesurez où l’agent perd de vue son objectif, et distinguez les erreurs de perception des échecs de navigation, de raisonnement et de contrôle.

Les acheteurs en entreprise devraient exiger les mêmes preuves. Le classement d’un modèle sur un benchmark en dit peu sur la capacité d’un agent intégré à achever de manière cohérente un processus en plusieurs étapes.

MineExplorer ne tranche pas le débat sur l’IA incarnée. Il fournit une manière reproductible de rendre une faiblesse plus difficile à ignorer.

Le résultat Anthropic MineExplorer est particulièrement révélateur parce que Claude Opus 4.6 est arrivé premier. Le modèle testé le plus performant a tout de même perdu 65 points de pourcentage à mesure que la profondeur de la tâche passait d’un saut à quatre.

C’est le renversement central du benchmark. Les modèles multimodaux actuels peuvent souvent décrire un monde qu’ils ne peuvent pas naviguer de manière fiable.

La prochaine étape crédible pour les agents n’est donc pas une nouvelle réponse parfaite à partir d’une capture d’écran. C’est une progression continue dans un environnement inconnu, avec la capacité de repérer une mauvaise direction et de se rétablir avant la fin de la tâche.