2 160 tours de simulation sans bouton d'arrêt : recherche MiroFish, partie 3

Le troisième article de la série d'études MiroFish examine ce qui se passe lorsque l'entrée est correcte. La durée de la simulation est définie par une phrase comme « au cours des 7 prochains jours » dans la requête de l'utilisateur ; le système ne demande jamais de confirmation. Sur six exécutions avec un horizon, le nombre de tours était exactement le nombre de jours multiplié par 24 (168, 336, 2160 tours), documenté dans quatre familles de modèles. L'inspection statique du code a confirmé le mécanisme : le générateur de configuration invite le LLM à remplir total_simulation_hours (24-168 heures) et minutes_per_round (30-120, recommandé 60), et l'exécuteur calcule total_rounds = total_hours * 60 / minutes_per_round. Avec la recommandation de 60 minutes, les tours sont égaux aux heures, donc 90 jours deviennent 2160 tours. La plage documentée de 24 à 168 heures n'est qu'une recommandation dans l'invite ; aucun code ne restreint ou ne valide le nombre. Le système ne peut pas remplir ses propres obligations : les agents accumulent de la mémoire sans limite, ce qui entraîne une dégradation et des erreurs du fournisseur ; un monde de 7 agents s'est dégradé vers le tour 300, un monde de 4 agents vers le tour 515, tandis que des mondes de 18 à 19 agents ont nécessité des arrêts précoces. Il n'y a pas de bouton d'arrêt dans l'interface ; un membre de la communauté a découvert que le gestionnaire frontend existe mais n'est connecté à aucun bouton, et a soumis une demande d'extraction. Le chercheur a dû utiliser un POST non documenté /api/simulation/stop pour mettre fin à l'exécution de 90 jours au tour 592, après que toute activité significative avait cessé. L'étude note des limites : la plupart des cellules sont en n=1, seules quatre familles de modèles ont été testées, et tous les effondrements se sont produits sur des mondes DeepSeek, donc l'indépendance vis-à-vis de la famille de modèles reste non vérifiée.