GPT-6 Astra termine Portal seul, 24 heures sans décrocher

GPT-6 Astra termine Portal seul, 24 heures sans décrocher

Un développeur a laissé un modèle jouer seul à Portal. Objectif donné au départ, puis plus rien : aucun conseil, aucune reprise en main, aucune sauvegarde chargée à sa place. Presque vingt-quatre heures plus tard, le générique défilait.

L’expérience est signée cozyblaze, qui l’a racontée sur X et publié sur GitHub le code, les notes d’installation et le journal de la session. GPT-6 Astra a mené la partie de la première chambre de test au générique de fin, en 23 heures et 43 minutes.

Un modèle qui appuie sur pause pour réfléchir

Comment un modèle de langage appuie-t-il sur les touches ? Deux pièces logicielles s’en chargent. La première est MCP (Model Context Protocol), le protocole qui permet à un modèle d’appeler des outils extérieurs et d’en recevoir les réponses. La seconde est une version modifiée de SourcePauseTool, un utilitaire qui gèle le moteur du jeu à la demande.

La mécanique se répète à l’identique. Le jeu s’arrête. L’agent reçoit une capture d’écran, la position du joueur et l’angle de la caméra. Il choisit les touches à presser, rend la main, et le moteur repart pour quelques instants avant de se figer à nouveau. Des milliers de fois. La vidéo publiée coupe les pauses, sans quoi elle durerait une journée entière.

Une manette branchée en direct aurait été plus simple, mais elle était hors de portée : un aller-retour de réflexion se compte en secondes, quand Portal réclame des décisions en dizaines de millisecondes. La pause sépare deux horloges, celle de la machine et celle du jeu. La partie mesure donc des décisions, là où une manette mesurerait des réflexes.

Tenir l’objectif pendant des milliers de tours

Prise énigme par énigme, la difficulté reste modeste. Chaque chambre de Portal se résout dans un raisonnement court : repérer une surface capable de recevoir un portail, en placer un second au bon endroit, se laisser tomber. Un modèle de cette génération fait cela sans forcer.

L’exercice se corse sur la durée. Il faut garder un objectif en tête pendant des milliers de tours. Savoir qu’on a déjà essayé ce mur, que la tentative précédente a échoué, que la sortie se trouve derrière soi. Repartir après un échec sans recommencer la chambre entière, ni tourner en rond quarante minutes. Rien de spectaculaire tour par tour. Beaucoup, cumulé.

Le genre n’est pas neuf. Anthropic a lâché Claude sur Pokémon Red, un développeur indépendant a fait boucler Pokémon Blue à Gemini. Ces parties-là se sont étalées sur des semaines de diffusion en direct, avec un échafaudage logiciel retouché en cours de route ; celle-ci a tenu en un jour, sur une boucle qui n’a pas bougé.

L’endurance tient à un choix technique discret : l’agent ne mémorise pas l’état du monde, il le relit. À chaque pause, la position et l’angle de caméra lui reviennent du moteur du jeu, jamais de son propre historique. Sa mémoire porte l’intention, pas les faits.

Vos agents, eux, calent à la vingtième étape

Un agent livré à lui-même sur une migration de code, une file de tickets ou un back-office s’effondre rarement sur l’étape difficile. Il s’effondre à la vingtième : contexte tronqué, action déjà effectuée refaite une seconde fois, contrainte posée au départ oubliée en chemin. Cette dérive coûte plus cher qu’un échec franc, parce qu’elle passe inaperçue jusqu’au moment où le résultat est faux.

La partie de Portal, elle, ne dérive pas, et ce qui l’en préserve se transpose tel quel à un agent de production :

  • une boucle courte, identique à chaque tour, qu’on peut relancer mille fois sans qu’elle se déforme ;
  • un état relu à la source à chaque itération, jamais reconstitué de mémoire ;
  • un moyen de suspendre l’exécution le temps de la décision, pour que la latence du modèle ne se paie pas en erreurs.

Concrètement, cela revient à donner à votre agent les moyens de vérifier l’état réel du système à chaque étape (le dépôt, la base, le ticket, la page) au lieu de lui demander de s’en souvenir. Ce qu’il garde en tête doit rester léger. Ce qu’il vérifie doit être exact.

570 dollars à l’API, 200 au forfait

Au tarif public d’Astra, la consommation de tokens représente au moins 570 dollars pour cette seule session. Le développeur, lui, a joué sur un abonnement Codex à 200 dollars. Deux additions pour un même travail, selon qu’on paie au token ou au forfait.

L’écart pèse sur la conception de tout agent au long cours. Une session de vingt-quatre heures se règle en tokens, et le mode de facturation décide de ce qu’on s’autorise à lancer. Des charges de travail déraisonnables à l’API deviennent tenables sous forfait plafonné. C’est aujourd’hui l’un des rares moyens de tester l’endurance d’un agent sans faire sauter une ligne budgétaire.

Dans son fil, cozyblaze rappelle qu’OpenAI s’était fixé en 2016 l’objectif de résoudre quantité de jeux différents avec un agent unique, et qualifie Astra de « the worst model we’ll ever get », le plus mauvais que nous connaîtrons jamais. Dix ans après, une partie complète bouclée sans main humaine ressemble à un premier acompte sur cette promesse. La marche suivante se devine déjà : la même endurance, mais sans le droit d’arrêter le temps.

Sources

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *