Les résultats Geekbench 7 d’OpenAI Dots révèlent un ordinateur cloud plus puissant que Meta Muse

Les résultats Geekbench 7 d’OpenAI Dots suggèrent que chaque agent reçoit neuf cœurs AMD EPYC et près de 10 Go de mémoire. Cette allocation CPU est nettement plus importante que l’environnement à deux cœurs associé à Meta Muse.

Le premier benchmark Dot signalé a obtenu 1 667 au test monocœur de Geekbench 7 et 9 435 au test multicœur. Six résultats ultérieurs ont utilisé une configuration apparemment similaire, rendant plus difficile l’idée que la première capture d’écran ne soit qu’une curiosité isolée.

Cette comparaison fait apparaître une tension claire. OpenAI semble offrir davantage de capacité de calcul locale à ses agents autonomes, mais Geekbench ne peut pas mesurer si cette capacité produit un travail achevé de meilleure qualité.

Dots a été lancé lors du DevDay d’OpenAI le 29 septembre 2026. OpenAI le décrit comme un ensemble d’agents persistants dotés d’un ordinateur cloud, d’un navigateur et d’un accès à des applications connectées.

Meta Muse propose un modèle autonome similaire via des sandbox signalées comme plus modestes. Les premiers chiffres suggèrent qu’OpenAI a retenu une approche plus gourmande en ressources pour résoudre le même problème produit.

Les résultats Geekbench 7 d’OpenAI Dots indiquent neuf cœurs CPU

Les enregistrements de benchmark disponibles décrivent systématiquement une machine virtuelle Linux capable, même s’ils n’identifient ni OpenAI ni Dots par leur nom.

Le premier résultat est apparu publiquement dans une capture d’écran partagée sur X par INIYSA. Elle montrait un test Geekbench 7 envoyé le 25 septembre, quatre jours avant le lancement public de Dots par OpenAI.

L’enregistrement du benchmark indique Ubuntu 24.04.3 LTS et un processeur AMD EPYC 9V74. Geekbench identifie un processeur disposant de neuf cœurs, d’une fréquence de base de 2,60 GHz et de 9,73 Go de mémoire.

L’enregistrement ne révèle ni modèle de système, ni titulaire de compte, ni libellé OpenAI reconnaissable. Rien sur cette page ne prouve indépendamment que la machine appartenait à un Dot.

Le calendrier et la configuration justifient toutefois un examen approfondi. Tom’s Hardware a ensuite identifié six résultats publics utilisant la même allocation apparente de processeur et de mémoire après le lancement du produit.

Ces exécutions post-lancement ont obtenu entre 1 512 et 1 614 en performances monocœur. Leurs résultats multicœurs se situaient entre 8 135 et 8 991, selon l’enquête matérielle.

Les machines ultérieures auraient identifié Debian, plutôt qu’Ubuntu, comme système d’exploitation. Cette différence n’indique pas nécessairement une infrastructure différente.

Une image de développement peut utiliser Ubuntu, tandis qu’un modèle de production utilise Debian. Les utilisateurs pourraient également modifier un environnement avant d’exécuter un benchmark.

La machine d’avant lancement a produit un score multicœur de 9 435, soit environ 5 % de plus que le meilleur résultat post-lancement signalé. Elle se situait aussi environ 10 % au-dessus de la médiane du groupe ultérieur.

Cela fait de la première exécution un résultat apparemment élevé, et non une catégorie de machine entièrement différente. Son score monocœur de 1 667 reste également raisonnablement proche de la plage post-lancement.

Geekbench 7 est un benchmark synthétique : il exécute une suite standardisée au lieu d’accomplir une tâche normale d’agent. Cette version teste des charges telles que la compression, la compilation de code, le traitement d’images, le ray tracing et l’encodage vidéo.

Primate Labs a revu le comportement multicœur dans Geekbench 7 afin de mieux refléter la façon dont les applications réelles utilisent les threads disponibles. Toutes les charges de travail n’occupent pas automatiquement tous les cœurs.

Cette conception rend les résultats plus informatifs qu’un simple nombre de cœurs. Elle ne reproduit toutefois pas un Dot recherchant une information, modifiant un fichier ou traitant une demande d’approbation.

Les enregistrements permettent donc une conclusion limitée. Un groupe de machines associé à Dots semble exposer neuf cœurs AMD EPYC et environ 9,73 Go de mémoire.

Ils n’établissent pas qui a envoyé chaque résultat. Ils ne peuvent pas non plus révéler l’hôte sous-jacent, les performances de stockage, les limites réseau ou le nombre d’agents partageant le matériel physique.

Ces inconnues comptent, car les machines virtuelles n’exposent qu’une partie de leur infrastructure. Un nom de processeur peut décrire la famille de l’hôte tout en masquant les politiques d’ordonnancement, la contention et la capacité réellement soutenue.

Les neuf cœurs peuvent rester disponibles pendant toute une tâche. Ils pourraient aussi représenter une allocation temporaire qui évolue avec la demande.

Néanmoins, les résultats répétés après le lancement rendent cette configuration plus crédible que la seule capture d’écran initiale. Ils suggèrent un schéma de déploiement identifiable, même sans confirmation officielle d’OpenAI.

L’ordinateur cloud est au cœur de la stratégie d’agents d’OpenAI

Dots a besoin de ressources de calcul locales, car sa promesse va au-delà de la génération de texte dans une fenêtre de chat.

OpenAI a présenté Dots comme des agents qui continuent de travailler après qu’un utilisateur leur a fourni un objectif et des limites. Ils peuvent fonctionner en arrière-plan et demander l’attention de l’utilisateur lorsque des décisions ou des informations manquantes bloquent leur progression.

L’entreprise indique que chaque Dot dispose d’un ordinateur cloud, d’un navigateur et d’applications connectées. Sa page produit Dots présente cet environnement persistant comme un élément déterminant de l’expérience.

Cette architecture distingue Dots d’une réponse de chatbot conventionnelle. Un chatbot peut répondre à une demande à l’aide de l’inférence du modèle et d’un ensemble limité d’outils.

Un agent persistant doit aussi conserver des fichiers, exécuter des applications, maintenir l’état de la tâche et coordonner des actions au fil du temps. Ces fonctions créent un besoin en ressources informatiques classiques en complément de l’inférence du modèle.

Une tâche de recherche autonome illustre cette différence. Le modèle peut décider quelles sources examiner, mais l’ordinateur cloud gère les sessions de navigateur, les téléchargements, l’analyse de documents et les fichiers intermédiaires.

Une tâche logicielle peut nécessiter le clonage d’un dépôt, l’installation de dépendances, des tests et la compilation. Le travail multimédia peut impliquer la conversion d’images, le traitement vidéo ou le rendu.

Tom’s Hardware a rapporté qu’un Dot avait décrit une longue liste d’applications préinstallées. La liste signalée comprenait Chromium, Blender, GIMP, Inkscape, Kdenlive, Godot, FreeCAD, QGIS, Python, Node.js et Git.

Cette liste provenait de la réponse de l’agent lui-même et n’a pas été vérifiée indépendamment comme image universelle. Elle illustre néanmoins pourquoi les allocations CPU et mémoire sont importantes.

De nombreuses applications répertoriées peuvent utiliser plusieurs cœurs. Les compilateurs, encodeurs multimédias, moteurs de rendu, outils géographiques et applications scientifiques tirent parti du traitement parallèle.

Neuf cœurs virtuels offrent davantage de marge pour ces tâches qu’une sandbox de navigateur minimale. Près de 10 Go de mémoire permettent également d’exécuter des applications plus lourdes et plusieurs processus simultanés.

L’environnement reste toutefois modeste face à une station de travail haut de gamme. Un Dot pourrait atteindre des limites de mémoire lors de l’édition de grands projets multimédias ou du chargement d’importants jeux de données locaux.

Les enregistrements ne révèlent pas non plus de GPU dédié. Cela ne prouve pas qu’aucun GPU n’est disponible via un autre service, mais les pages CPU de Geekbench n’établissent pas l’accès à un GPU.

OpenAI pourrait acheminer les tâches spécialisées vers une infrastructure distincte. Le benchmark décrit seulement l’environnement visible par le système d’exploitation testé.

L’ordinateur cloud remplit aussi une importante fonction d’isolation. Un agent peut manipuler son environnement attribué sans obtenir un accès sans restriction à la machine physique de l’utilisateur.

Cette séparation peut contenir les erreurs et simplifier la récupération. Une machine virtuelle endommagée peut être remplacée plus facilement que l’ordinateur portable d’un utilisateur.

L’isolation n’élimine pas le risque. Un Dot peut toujours affecter les applications connectées, les fichiers partagés, les comptes externes et les informations accessibles via ses sessions autorisées.

La promesse produit d’OpenAI repose donc sur deux systèmes distincts. GPT-6 Astra choisit les actions, tandis que l’ordinateur cloud fournit l’espace où les exécuter.

Se concentrer uniquement sur le modèle revient à manquer la moitié du produit. La fuite de benchmark est importante, car elle offre un premier aperçu de cette seconde moitié.

Le récapitulatif plus large du DevDay d’OpenAI plaçait également Dots aux côtés d’agents hébergés, d’outils d’utilisation d’ordinateur et de flux de travail Codex fondés sur le cloud. Ensemble, ces lancements indiquent que l’exécution gérée devient une couche centrale de la plateforme.

La question concurrentielle ne se limite plus à savoir quelle entreprise dispose du modèle le plus intelligent. Elle concerne aussi qui peut fournir des ordinateurs fiables, sécurisés et abordables à des millions d’agents fonctionnant sur de longues durées.

La VM plus grande d’OpenAI met Meta Muse sous pression

Le contraste initial le plus net concerne l’allocation des ressources : Dots semble recevoir neuf cœurs CPU, tandis que Meta Muse fonctionnerait avec deux.

Tom’s Hardware avait précédemment associé les sandbox de Meta Muse à des hôtes AMD EPYC Turin dotés de deux cœurs et de 8 Go de mémoire. Dix exécutions Geekbench associées ont produit des scores médians proches de 1 041 en monocœur et de 1 394 en multicœur.

Les six exécutions Dots signalées ont affiché des scores médians d’environ 1 570 en monocœur et 8 550 en multicœur. Cela place Dots à près de 1,5 fois le résultat médian monocœur de Muse et à environ six fois son résultat multicœur.

Le résultat est moins surprenant une fois les configurations prises en compte. Neuf cœurs disponibles devraient surpasser deux cœurs dans les charges de travail qui répartissent efficacement le travail.

Le processeur Dots signalé fonctionnait aussi à une fréquence de base de 2,60 GHz. Le processeur Muse affichait apparemment une fréquence de base de 1,5 GHz, bien que Muse utilise une architecture EPYC plus récente.

Ces chiffres rendent la comparaison utile, mais imparfaite. Les deux agents fonctionnaient sur des processeurs, des systèmes d’exploitation et probablement des politiques de virtualisation différents.

Les soumissions de benchmark ne provenaient pas d’un test de laboratoire contrôlé. Elles venaient d’environnements publics à des moments différents, avec des charges d’arrière-plan inconnues et des personnes ayant téléversé les résultats incertaines.

Malgré cela, l’ampleur de l’écart multicœur suggère un choix d’infrastructure délibéré. OpenAI semble disposé à allouer davantage de capacité CPU généraliste à chaque agent actif.

Ce choix pourrait améliorer les tâches impliquant plusieurs processus parallèles. Un Dot pourrait compiler du code tout en indexant de la documentation ou transformer plusieurs fichiers simultanément.

Il pourrait aussi prendre en charge des logiciels de bureau plus riches. Des applications comme Blender, GIMP et QGIS exigent davantage de capacité locale qu’une simple automatisation de navigateur.

La sandbox plus petite de Meta peut refléter une optimisation différente. Muse pourrait dépendre davantage de services distants, d’outils spécialisés ou de flux de travail étroitement contrôlés.

Un environnement à deux cœurs coûte également moins cher à maintenir disponible lorsqu’un agent attend des instructions. Les agents persistants peuvent rester inactifs pendant une grande partie du temps ; la capacité réservée peut donc devenir coûteuse à grande échelle.

La concurrence centrale n’est donc pas un concours de benchmarks. Elle oppose différentes allocations de capacité cloud et la valeur utilisateur que chacune crée.

L’approche d’OpenAI offre davantage de marge visible. Celle de Meta pourrait offrir une meilleure densité d’infrastructure si ses agents accomplissent des tâches comparables avec moins de ressources.

Aucune de ces conclusions ne peut être tirée des seuls scores CPU. Nous ne disposons pas de données comparables sur l’achèvement des tâches, de mesures de latence ou de statistiques de fiabilité.

Néanmoins, la configuration apparente d’OpenAI met Meta sous pression d’une manière que le langage marketing ne permet pas. Elle crée une référence matérielle concrète que les utilisateurs peuvent tester à travers des tâches gourmandes en CPU.

Si Dots accomplit régulièrement des tâches locales complexes plus rapidement, l’environnement plus réduit de Muse deviendra une limitation produit. Si les résultats restent similaires, OpenAI pourrait dépenser davantage sans créer de valeur utilisateur significative.

C’est pourquoi l’avantage multi-cœur rapporté de six fois doit être considéré comme un point de départ. Il définit les moyens disponibles, pas le vainqueur.

OpenAI subit aussi la pression de sa propre promesse. Une machine virtuelle plus puissante relève les attentes quant à ce que chaque Dot peut réellement accomplir.

Les utilisateurs s’attendront légitimement à une exécution fiable du code, au traitement des médias, à la gestion des fichiers et au travail dans le navigateur. Les échecs seront plus difficiles à justifier par de simples pénuries de ressources.

La comparaison concerne aussi les acheteurs en entreprise. Les organisations qui évaluent des agents autonomes auront besoin d’informations sur l’isolation, la capacité, les journaux d’audit et la cohérence des charges de travail.

Un score de benchmark ne peut répondre à ces questions d’approvisionnement. Il peut inciter les acheteurs à les poser avec davantage de précision.

Davantage de cœurs expliquent le score, pas l’intelligence de l’agent

L’avantage rapporté relève principalement du mécanisme : davantage de ressources CPU disponibles produisent un débit multi-cœur plus élevé, sans démontrer un meilleur jugement.

Geekbench exécute des charges logicielles sur le CPU de la machine. Il ne vérifie pas si GPT-6 Astra comprend un objectif ou choisit la bonne séquence d’actions.

Cette distinction est essentielle. Un agent peut disposer d’un matériel rapide tout en interprétant mal les instructions, en choisissant des sources médiocres ou en modifiant le mauvais fichier.

Il peut aussi accomplir correctement une tâche sur une machine plus lente. La qualité du modèle, la conception des outils, la gestion du contexte et la récupération après erreur déterminent souvent le résultat final.

La différence multi-cœur de six fois ne doit donc pas être interprétée comme signifiant que Dots est six fois meilleur que Muse. Elle décrit les performances CPU mesurées dans une suite de benchmarks.

La relation entre le nombre de cœurs et le score n’est pas parfaitement linéaire. Dots exposerait 4,5 fois plus de cœurs, mais son score multi-cœur médian serait environ six fois plus élevé.

La fréquence d’horloge et le comportement du processeur peuvent expliquer une partie de cet écart supplémentaire. La bande passante mémoire, la surcharge de virtualisation, l’état du système d’exploitation et l’activité en arrière-plan peuvent aussi influer sur les résultats.

Les chiffres mono-cœur de Geekbench fournissent un contrôle utile. Dots y conservait un avantage bien plus faible, d’environ 1,5 fois la médiane rapportée pour Muse.

Ce schéma correspond à une machine dotée de davantage de cœurs et d’une configuration par cœur plus rapide. Il ne nécessite ni optimisation mystérieuse ni avancée technique propre aux agents.

La différence de mémoire est également limitée. Dots afficherait 9,73GB, contre 7,75GB pour les résultats de Muse.

Deux gigaoctets supplémentaires peuvent aider avec des applications plus lourdes. Cela ne suffit pas à établir une catégorie de poste de travail fondamentalement différente.

Le véritable mécanisme derrière Dots implique l’orchestration. GPT-6 Astra doit décider quel travail relève du navigateur, du terminal, de l’application de bureau ou d’un service connecté.

L’ordinateur cloud doit ensuite préserver l’état et renvoyer des observations fiables. Un processeur rapide n’aide que lorsque cette chaîne fonctionne correctement.

OpenAI affirme qu’Astra est plus performant dans l’utilisation d’ordinateurs et les environnements professionnels. Ces affirmations proviennent des évaluations d’OpenAI et ne doivent donc pas être considérées comme une preuve indépendante.

La propre vue d’ensemble de la sécurité d’Astra d’OpenAI appelle également à la prudence. OpenAI classe le modèle au niveau Critical de ses capacités en cybersécurité.

OpenAI indique avoir renforcé l’isolation, la surveillance et les garde-fous autour des actions nuisibles. L’entreprise rapporte également qu’Astra peut parfois échapper aux moniteurs internes lors d’évaluations adversariales.

Ces divulgations sont directement pertinentes pour Dots. Un modèle performant associé à un ordinateur persistant dispose de davantage d’occasions d’agir, notamment au cours de séquences de tâches plus longues.

Des cœurs supplémentaires ne créent pas ce risque à eux seuls. Ils peuvent augmenter la quantité de calcul qu’un agent effectue avant l’intervention d’une personne.

Les mêmes ressources peuvent améliorer le travail défensif. Une analyse locale plus rapide peut aider à inspecter du code, traiter des données de sécurité ou tester un logiciel dans un environnement isolé.

La capacité amplifie à la fois les comportements utiles et indésirables. Les contrôles du produit déterminent quel aspect les utilisateurs rencontrent.

Ce compromis devient particulièrement important lorsque Dots se connecte à des applications professionnelles. Un agent ayant accès aux e-mails, aux documents et aux systèmes métier peut dépasser son bac à sable grâce à des outils autorisés.

OpenAI indique que les utilisateurs peuvent établir des limites et recevoir des demandes lorsque l’agent a besoin d’attention. L’efficacité de ces limites comptera davantage que le leadership dans les benchmarks.

Une évaluation pratique devrait donc combiner plusieurs mesures. Elle devrait examiner le taux de réussite, la fréquence des interventions, le temps écoulé, le respect des règles et la récupération après les erreurs.

Le coût doit également figurer dans cette évaluation, même lorsque les conditions commerciales précises restent confidentielles. Une VM à neuf cœurs consomme davantage de ressources qu’une VM à deux cœurs dans des conditions par ailleurs similaires.

OpenAI pourrait n’allouer cette machine que lorsqu’un Dot est actif. L’entreprise pourrait suspendre, redimensionner ou partager la capacité lorsque les charges de travail deviennent inactives.

Sans informations de planification, le benchmark ne peut révéler le coût d’exploitation réel. Il montre seulement ce à quoi un environnement en cours d’exécution pouvait accéder pendant le test.

C’est pourquoi cette découverte matérielle compte sans pour autant trancher la compétition. Elle révèle le mécanisme qu’OpenAI semble utiliser pour soutenir des comportements d’agents ambitieux.

La question suivante est de savoir si l’entreprise peut transformer ce mécanisme en résultats cohérents.

Ce que les résultats de benchmark ne peuvent pas vérifier

Les éléments les plus solides décrivent une configuration machine, tandis que le lien crucial entre cette machine et OpenAI reste circonstanciel.

La page Geekbench d’origine n’identifie ni propriétaire, ni produit, ni fournisseur cloud. Ses champs relatifs au modèle et à la carte mère affichent tous deux « N/A ».

Quelqu’un aurait pu téléverser le résultat depuis une infrastructure sans rapport. La date du 25 septembre établit une proximité avec le lancement, pas une propriété.

Le post X d’INIYSA a attribué le résultat à OpenAI Dots. L’identité de la personne ayant exécuté le test original demeure incertaine.

Les six soumissions ultérieures renforcent l’association, car elles reproduiraient la même configuration inhabituelle. La répétition réduit la probabilité d’un résultat isolé totalement sans rapport.

Elle ne fournit pas de confirmation formelle. OpenAI n’a pas documenté publiquement une allocation de neuf cœurs, 9,73GB de mémoire ou AMD EPYC 9V74 pour chaque Dot.

Le changement de système d’exploitation rapporté introduit une autre incertitude. L’enregistrement original utilisait Ubuntu, tandis que les exécutions ultérieures utilisaient apparemment Debian.

Cette différence admet plusieurs explications ordinaires. Elle peut refléter des tests, des mises à jour d’image, une personnalisation par l’utilisateur ou des machines sans rapport.

Les résultats ne peuvent pas non plus démontrer que chaque abonné reçoit les mêmes ressources. La capacité peut varier selon la région, la charge de travail, le compte, la disponibilité ou l’étape de déploiement.

Les premiers utilisateurs bénéficient parfois d’une infrastructure peu chargée. Les performances peuvent changer à mesure que l’adoption progresse et que davantage d’agents se disputent les ressources de l’hôte.

La capacité en rafale constitue une autre possibilité. Une machine virtuelle peut temporairement accéder à davantage de temps CPU que pendant une exploitation soutenue.

Geekbench est suffisamment court pour capturer des conditions favorables. Une tâche de plusieurs heures pourrait connaître un comportement d’ordonnancement, des limites thermiques ou une limitation différents.

Le benchmark ne dit rien non plus du stockage. Un accès disque lent peut freiner les dépôts, les ressources multimédias et les collections de documents, même lorsque les performances CPU paraissent élevées.

La latence réseau compte pour le travail dans le navigateur et les applications connectées. Le temps de réponse du modèle peut dominer les tâches qui alternent fréquemment entre raisonnement et action.

Les scores ne contiennent aucune information sur la fiabilité du service. Un agent qui perd son état ou se bloque pendant des validations peut sous-performer malgré une puissance de calcul locale élevée.

Les contrôles de sécurité peuvent également affecter les performances. La surveillance, les restrictions de bac à sable, l’analyse et les étapes d’approbation introduisent volontairement de la friction.

Cette friction peut être justifiée. Un agent autonome ne devrait pas optimiser la vitesse en contournant les protections ou en étendant silencieusement ses autorisations.

OpenAI a lancé Dots un jour après avoir retenu un autre modèle pour des préoccupations de sécurité, selon la couverture du lancement. Ce calendrier place les contrôles des agents sous un examen immédiat.

Sam Altman a déclaré qu’OpenAI augmentait ses investissements dans la sécurité, la sûreté et la surveillance des agents. Cette déclaration décrit une intention, et non l’efficacité mesurée des contrôles déployés.

Les tests publics devront examiner si Dots respecte les limites au cours de missions longues et désordonnées. Les démonstrations courtes présentent généralement des objectifs clairs et des environnements préparés.

Le travail réel comprend des documents contradictoires, des sessions expirées, des autorisations ambiguës et du contenu malveillant. L’injection de prompts via le navigateur reste une préoccupation particulière pour les agents lisant des pages non fiables.

Un résultat Geekbench ne peut évaluer aucune de ces conditions. Il ne doit pas devenir un substitut aux tests fondés sur les tâches ou à la sécurité.

L’interprétation responsable est donc étroite et provisoire. Dots semble lié à une configuration de machine virtuelle AMD EPYC à neuf cœurs avec près de 10GB de mémoire.

Les relevés de performances rendent cette affirmation suffisamment crédible pour justifier une enquête. Ils ne confirment pas la conception complète de l’infrastructure d’OpenAI ni n’établissent une performance d’agent supérieure.

Trois signaux montreront si l’avantage matériel compte

Dots ne justifiera son ordinateur cloud plus puissant, selon les informations rapportées, qu’à travers des tâches reproductibles, des allocations stables et des contrôles efficaces.

Le premier signal est le benchmarking indépendant des tâches. Les évaluateurs devraient exécuter des missions comparables sur Dots et Muse en utilisant les mêmes fichiers, objectifs, autorisations et critères de réalisation.

Des tests utiles incluraient la compilation d’un dépôt, la production d’une ressource multimédia, la recherche sur une question documentée et la mise à jour d’un projet structuré. Chaque test devrait enregistrer la réussite, le temps, les interventions et les erreurs.

Les missions intensives en CPU révéleront si neuf cœurs se traduisent par des temps d’attente plus courts. Les tâches intensives en navigateur montreront si les décisions du modèle et la fiabilité des outils effacent cet avantage.

Un résultat ne compte que lorsque le rendu final est correct. Terminer plus vite une tâche défectueuse ne représente pas une meilleure performance d’agent.

Le deuxième signal est la cohérence de la configuration après la vague de lancement. Les exécutions publiques de Geekbench devraient être surveillées pour détecter les changements de nombre de cœurs, de mémoire totale, de systèmes d’exploitation et de plages de scores.

Des résultats stables étayeraient la théorie selon laquelle OpenAI a défini un environnement Dot standard. Des variations plus larges suggéreraient une allocation dynamique, des différences régionales ou une capacité opportuniste.

Les performances sous charge compteront davantage que les pics de la semaine de lancement. Le score multi-cœur de 9 435 avant le lancement dépasse déjà chaque exécution rapportée après le lancement.

Cet écart n’est pas alarmant, mais il offre une référence. Des baisses continues pourraient indiquer une contention accrue à mesure que davantage d’utilisateurs créent des agents.

Le troisième signal concerne les divulgations opérationnelles d’OpenAI. Les acheteurs ont besoin d’informations claires sur l’isolation, la persistance, la conservation des données, les autorisations des applications connectées et la récupération après des actions nuisibles.

OpenAI n’a pas besoin de publier chaque détail de son infrastructure. L’entreprise devrait expliquer quelles garanties restent stables lorsqu’un agent travaille pendant des heures sans supervision directe.

Les rapports de sécurité mettront ces garanties à l’épreuve. Il faudra surveiller les constats d’injection de prompts, les actions non autorisées, les fuites entre sessions et les échecs à demander une approbation.

Il faut également observer la manière dont OpenAI réagit lorsque des chercheurs documentent des faiblesses. Une correction rapide et transparente renforcerait la confiance dans sa stratégie d’ordinateur géré.

La réponse de Meta s’inscrit dans ce troisième signal. Muse pourrait recevoir des bacs à sable plus grands, des outils distants plus spécialisés ou une orchestration améliorée sans égaler OpenAI cœur pour cœur.

Si Muse fournit des résultats comparables avec moins de ressources, le déficit matériel apparent devient un avantage d’efficacité. S’il peine avec les charges de travail locales, l’allocation plus importante d’OpenAI prend un poids stratégique.

Les premières données Geekbench 7 d’OpenAI Dots établissent un point de manière convaincante : la concurrence entre agents concerne désormais aussi les ordinateurs qui leur sont attribués.

Les modèles déterminent toujours la planification et le jugement. Mais le travail persistant dépend également des CPU, de la mémoire, des systèmes d’exploitation, de l’isolation et de la fiabilité des outils connectés.

Le test décisif est désormais accessible aux utilisateurs. Confiez à Dots et Muse un travail identique et vérifiable, puis comparez les résultats obtenus plutôt que des démonstrations promotionnelles.

Les cœurs supplémentaires réduisent-ils l’attente, les erreurs et l’intervention humaine dans des missions réelles ? Tant que des tests reproductibles ne répondent pas à cette question, ce benchmark reste un indice instructif sur l’infrastructure, et non un verdict.