Le harnais à 23 600 étoiles n'a pas été construit pour gagner un benchmark

Tous les harnais couverts par ce blog cette semaine — VISTA, Schema, Prime Agent — ont été construits par un laboratoire ou une équipe de recherche, visant un seul benchmark, et publiés avec un graphique. oh-my-pi (omp) n'est rien de tout cela. C'est un agent de codage en terminal, sous licence MIT, forké depuis pi-mono de Mario Zechner et étendu par le chercheur en sécurité Can Bölük, sans aucune ligne de benchmark à défendre et pourtant 23 600 étoiles sur GitHub. Il mérite d'être couvert pour la même raison que les autres : il résout le même problème sous-jacent — cesser de faire refaire au modèle un travail qu'il a déjà accompli — depuis un angle complètement différent, à une couche qu'aucun des harnais d'ARC-AGI-3 de cette semaine n'avait touchée.

Le problème que tout harnais a et ne mentionne jamais

Demandez à un modèle de modifier un fichier, et la plupart des harnais lui font reproduire exactement l'ancien texte, puis le nouveau, puis font correspondre l'ancienne chaîne au fichier pour trouver où appliquer le changement. Ça semble trivial. En pratique, c'est une source persistante d'échecs : les espaces ne correspondent pas, la chaîne apparaît deux fois, un caractère parasite casse le diff, et le modèle brûle un tour à retaper des lignes qu'il venait pourtant de lire parfaitement.

Hashline est le correctif d'omp, et l'idée est presque trop simple : quand le harnais montre un fichier au modèle, chaque ligne porte un court hash de contenu. Pour modifier la ligne 42, le modèle écrit Line 42:f1 replace suivi du nouveau contenu — il pointe vers l'ancre plutôt que de retaper la ligne. Deux conséquences en découlent. Les échecs de correspondance d'espaces et les erreurs de correspondance ambiguë disparaissent presque entièrement, parce que le modèle référence un hash plutôt que de reproduire des caractères exacts. Et l'obsolescence est détectée gratuitement : si le fichier a changé entre le moment où le modèle l'a lu et celui où il tente de le modifier, le hash ne correspondra plus, et le harnais rejette le correctif avant qu'il ne corrompe quoi que ce soit — le même instinct que le journal d'événements à rejeu exact de Muse Code, appliqué à une seule modification de fichier plutôt qu'à une session entière.

Le benchmark du projet lui-même — 16 modèles, 180 tâches, 3 exécutions chacune, avec la réserve habituelle sur l'auto-déclaration — chiffre l'effet : Hashline ajoute en moyenne 15 points de pourcentage par rapport à l'édition par remplacement de chaîne standard, sur l'ensemble des 16 modèles. Les extrêmes sont les données les plus intéressantes : Grok Code Fast passe d'un taux de réussite de 6,7% à 68,3% — un bond d'un facteur dix attribué spécifiquement au format d'édition, pas au modèle, « quand le format d'édition arrête de dévorer le modèle vivant » — et Grok 4 Fast accomplit le même travail avec 61% de tokens de sortie en moins. Aucun des deux n'est un gain de capacité. Les deux sont un harnais qui empêche complètement un mode d'échec précis et bien identifié de se produire.

Le reste de la boîte à outils suit le même instinct

Au-delà de l'édition, omp est construit autour de l'idée de ne pas redériver ce qui n'a pas besoin de l'être. Il embarque 31 outils intégrés et privilégie leur exécution en interne plutôt que par appel shell externe — ripgrep et glob tournent nativement, et 58 utilitaires en ligne de commande sont compilés directement dans le binaire, si bien que les opérations courantes évitent le coût de lancer un sous-processus à chaque fois. Les cellules Python et JavaScript sont persistantes : l'état survit d'un appel d'outil à l'autre plutôt que de redémarrer un interpréteur à chaque fois, et les outils peuvent réintégrer ces cellules, si bien qu'un script que le modèle a construit sur plusieurs tours reste disponible au tour suivant.

Quelques fonctionnalités moins évidentes méritent d'être nommées à part :

Rôle « advisor ». Une seconde instance de modèle lit chaque tour pris par l'agent principal et y injecte des notes en ligne — un second avis permanent tournant sur son propre contexte, plutôt qu'une passe de relecture ajoutée à la fin.
Règles de flux voyageant dans le temps. Une correspondance regex peut interrompre la génération en plein token, injecter une règle comme rappel système, et reprendre au même endroit — une contrainte vivante qui survit à la compaction de session, plutôt qu'un prompt système statique en espérant que le modèle s'en souvienne.
GitHub comme système de fichiers. Les pull requests et les issues sont des chemins adressables (pr://1428) via le même outil read que les fichiers locaux — une seule interface à apprendre pour le modèle, au lieu d'un jeu séparé de commandes type gh pr view à mal utiliser.
Sous-agents validés par schéma. Les sous-agents parallèles lancés via task renvoient des objets typés et validés par schéma que le parent lit directement — pas de prose à analyser, pas de conflits de fusion entre ce que deux workers ont chacun décidé de dire.
Revue de code P0–P3. /review lance des relecteurs en parallèle qui classent chaque constat par sévérité et confiance, si bien que « est-ce que ça part en production » obtient un vrai verdict plutôt qu'un mur de commentaires.

Qui construit cela, et pourquoi ce n'est pas un laboratoire

omp est un fork, pas un projet original — la mention de licence indique « © 2025 Mario Zechner ; © 2025–2026 Can Bölük », et le README est direct sur l'objectif : étendre pi-mono avec ce dont a besoin un outil du quotidien — sessions persistantes, sous-agents, commandes slash, architecture de plugins. Plus de soixante fournisseurs de LLM sont pris en charge, donc il est construit pour faire tourner n'importe quel modèle qu'on lui indique plutôt que pour en flatter un seul. Personne ne l'a fait tourner sur ARC-AGI-3, et rien dans sa conception ne visait cela.

C'est le vrai contraste à établir avec la couverture des autres harnais de cette semaine. VISTA, Schema et Prime Agent existent tous parce qu'un benchmark a créé une incitation à les construire, et leurs chiffres sont la seule raison d'en parler. Les chiffres d'omp sont une note de bas de page dans son propre README, enfouis sous une liste de fonctionnalités, parce que ce qui a poussé 23 600 personnes à le star n'était pas une position au classement — c'était que Hashline a arrêté un échec précis et quotidien de leur arriver personnellement. La recherche sur les harnais avance sous la pression de notation d'ARC Prize d'un côté, et par des développeurs qui essaient simplement d'empêcher un outil de casser de l'autre, et rien n'indique que le second groupe apprend moins.

À surveiller ensuite

Attendez-vous à voir l'édition ancrée par hash, ou une approche similaire consciente de l'obsolescence, se répandre. Elle résout un problème que partage tout harnais doté d'un outil d'édition de fichiers, pas seulement omp, et son adoption ne nécessite de réentraîner quoi que ce soit.
Surveillez si les harnais de laboratoire commencent à citer des outils communautaires plutôt que l'inverse. Jusqu'ici, le trafic n'est allé que dans un sens — des projets communautaires enveloppant des modèles de pointe. Un laboratoire de pointe adoptant un correctif né dans un projet parallèle à 23 600 étoiles serait un genre de croisement réellement nouveau.
Le tableau de benchmark mérite une réexécution indépendante. La même discipline que ce blog applique à tout résultat de harnais auto-déclaré : un bond d'un facteur dix sur un modèle est le genre de chiffre qui mérite les 180 tâches de quelqu'un d'autre avant d'être considéré comme acquis.

Références : can1357/oh-my-pi (MIT) · badlogic/pi-mono — le projet dont celui-ci est forké · couverture liée : Deux harnais résolvent le même benchmark en s'opposant sur la mémoire · Prime Agent et la troisième théorie de la mémoire · Muse Code de Meta · Le harnais QM de YC