Terminal-Universe extrait 37 300 salles d'entraînement d'anciennes exécutions d'agents

Chaque exécution d'un agent de codage laisse deux artefacts derrière elle. L'un est la transcription : les commandes lancées, les fichiers modifiés. L'autre est l'espace de travail sur lequel ces commandes ont été exécutées. Les transcriptions sont conservées ; les espaces de travail ne le sont pas, et un préprint soumis à arXiv le 3 septembre 2026 soutient que c'est l'inverse qui devrait se produire.

L'article, Terminal-Universe: Turning Agent Trajectories into Scalable Terminal Environments, argumente sur ce que consomme réellement le post-entraînement d'agents de terminal. Une trajectoire est une démonstration figée. Un environnement, lui, peut être réinterrogé pour produire de nombreuses tâches vérifiables et renvoie un retour d'exécution à chaque fois. Les trajectoires se sont accumulées à grande échelle tandis que les environnements exécutables restent rares, et l'historique d'exécution d'outils contenu dans une trajectoire décrit déjà l'environnement dans lequel elle a tourné avec assez de précision pour le reconstruire.

Terminal-Universe ne génère donc pas des environnements à partir de zéro. Il exploite ceux qui avaient été jetés.

Pourquoi un espace de travail survit à une démonstration

Une démonstration figée permet l'imitation : elle apprend à un agent ce que quelqu'un a fait une fois. Un espace de travail récupéré permet l'interrogation : les mêmes fichiers et le même test qui échoue peuvent être sollicités différemment à chaque passage. C'est cette réutilisabilité que l'article présente comme la propriété qui passe à l'échelle, et c'est elle qui manque à une transcription seule.

La rareté que pointe le préprint n'est pas une question de stockage. Les environnements sont coûteux à construire et faciles à perdre, parce qu'un bac à sable n'existe que le temps d'une exécution tandis que le journal lui survit. Le correctif proposé relève davantage de la récupération archivistique que de la synthèse.

Rejouer les opérations de fichier pour reconstruire le bac à sable

Le mécanisme se déroule en deux étapes. Terminal-Universe rejoue d'abord les opérations de fichier enregistrées dans une trajectoire pour restaurer chaque fichier dans l'état où il se trouvait avant que l'agent ne le modifie. Le résultat est un espace de travail partiel : les fichiers touchés par l'agent reviennent, le reste de l'arborescence non. Un agent de complétion fournit ensuite les fichiers manquants et les dépendances dont l'espace de travail a besoin pour s'exécuter.

La génération de tâches ne commence qu'après. Sur l'espace de travail reconstruit, le cadre récupère la tâche que la trajectoire d'origine tentait d'accomplir et en synthétise de nouvelles, l'étape qui transforme un enregistrement unique en corpus.

Deux axes : entre bases de code et entre tours

La reconstruction seule laisserait une archive de problèmes statiques, à un seul coup. L'article déploie plutôt ses tâches synthétiques selon deux axes. L'axe de largeur exploite les relations de dépendance directionnelle entre environnements apparentés et construit des requêtes inter-espaces de travail qui couvrent plusieurs bases de code, ce que les auteurs présentent comme une approximation du travail de développement ordinaire. L'axe de profondeur étire une requête à un seul tour en une session à plusieurs tours, un agent utilisateur fournissant un retour itératif et affinant les exigences au fil de la session.

Ce que les trois chiffres clés montrent, et ne montrent pas

Appliqué à des trajectoires publiques d'agents de terminal, le pipeline a produit 37 300 environnements « suffisants pour une tâche ». Le fine-tuning supervisé de Qwen3.5-27B sur ce corpus a produit deux améliorations rapportées.

Chaque chiffre est autodéclaré, mesuré sur un modèle que les auteurs ont fine-tuné, sur des benchmarks qu'ils ont choisis. Le résumé ne nomme aucune référence de base et ne décrit aucune exécution de contrôle. Il laisse aussi « suffisant pour une tâche » sans définition, de sorte qu'aucun critère énoncé ne distingue un environnement capable d'héberger une tâche d'un environnement qui se contente de s'exécuter.

Le chiffre multi-tours est plus difficile à interpréter. EvoCode-Bench v2 MT@4 est nommé mais pas décrit, et l'évaluation multi-tours introduit un utilisateur simulé dont le retour pilote chaque tour. Le résumé ne dit pas si cet agent utilisateur est maintenu fixe, si c'est le même modèle qui le génère, ni quelle part du gain de 13,8 points revient au modèle plutôt qu'à la conversation qu'on lui fournit.

Provenance, licences et contamination des benchmarks

Le résumé indique que les trajectoires sources étaient publiques. Il ne dit pas quelles collections ont été utilisées, ce que leurs licences autorisent, ni si les espaces de travail reconstruits peuvent faire réapparaître des fichiers qui n'auraient jamais dû quitter leur bac à sable d'origine.

La contamination est la question la plus aiguë. Les environnements récupérés à partir de trajectoires publiques puisent dans la même population de sessions de développement réelles que celle qui sert à construire les benchmarks publics, et le préprint ne traite pas la question de savoir si l'un des 37 300 environnements recoupe les espaces de travail derrière Terminal-Bench 2.1 ou EvoCode-Bench v2. Un corpus assemblé en rejouant des exécutions enregistrées est particulièrement exposé à ce recoupement, parce que les entrées sont de vraies sessions et non des exemples synthétiques.

Rien de tout cela n'invalide l'argument du recyclage, qui est simple et vérifiable. Si un espace de travail peut être récupéré à partir du journal, le jeter était facultatif. Ce que les chiffres ne disent pas encore, c'est la fidélité. La reconstruction dépend de la part du système de fichiers qu'une trajectoire a enregistrée, et là où le journal est mince, un agent de complétion doit deviner. Le résumé rend compte du rendement du pipeline, pas de la ressemblance entre les salles reconstruites et celles dans lesquelles les agents ont réellement travaillé.