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 : la plupart des harnais lui font recopier à l'identique l'ancien texte, puis le nouveau, avant de rechercher l'ancienne chaîne dans le fichier pour savoir où appliquer le changement. Cela paraît trivial. En pratique, c'est une source d'échecs récurrente : les espaces ne concordent pas, la chaîne apparaît deux fois, un caractère parasite casse le diff — et le modèle gaspille 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 maison du projet — 16 modèles, 180 tâches, 3 exécutions chacune, avec la réserve habituelle sur l'auto-déclaration — chiffre l'effet : Hashline apporte en moyenne 15 points de plus que l'édition classique par remplacement de chaîne, sur l'ensemble des 16 modèles. Ce sont les extrêmes qui intéressent. Grok Code Fast passe d'un taux de réussite de 6,7 % à 68,3 %, un bond d'un facteur dix imputable au seul format d'édition et non au modèle — « quand le format d'édition cesse de dévorer le modèle tout cru » —, et Grok 4 Fast abat le même travail avec 61 % de tokens de sortie en moins. Ni l'un ni l'autre ne constitue un gain de capacité : dans les deux cas, c'est un harnais qui empêche purement et simplement un mode de défaillance précis 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 et privilégie leur exécution interne plutôt que le passage par un appel système : ripgrep et glob tournent nativement, et 58 utilitaires en ligne de commande sont compilés directement dans le binaire, ce qui évite aux opérations courantes le coût d'un lancement de 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 rétroactives. Une correspondance d'expression régulière peut interrompre la génération en plein token, injecter une règle sous forme de rappel système, puis reprendre au même endroit : une contrainte vivante, qui survit à la compaction de session, plutôt qu'une consigne système figée 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 lancés en parallèle via task renvoient des objets typés et validés que le parent lit directement : pas de prose à analyser, pas de conflit de fusion entre ce que deux agents ont chacun décidé de raconter.
Revue de code de P0 à P3. /review lance des relecteurs en parallèle qui classent chaque constat par gravité et par niveau de confiance : la question « est-ce que ça part en production ? » reçoit ainsi un vrai verdict, au lieu d'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 : l'outil est donc conçu pour faire tourner n'importe quel modèle qu'on lui désigne, et non pour en avantager un seul. Personne ne l'a lancé 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, eux, tiennent de la 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 à lui donner une étoile n'était pas une place au classement, mais le fait que Hashline ait supprimé une panne précise et quotidienne qu'elles subissaient personnellement. La recherche sur les harnais avance donc sur deux fronts : sous l'aiguillon des classements d'ARC Prize d'un côté, et grâce à des développeurs qui cherchent simplement à empêcher un outil de casser de l'autre. Rien n'indique que le second groupe apprenne moins que le premier.

À 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.
Les harnais de laboratoire vont-ils commencer à citer des outils communautaires, et non l'inverse ? Jusqu'ici, la circulation s'est faite dans un seul sens : des projets communautaires qui enveloppent des modèles de pointe. Qu'un laboratoire de pointe reprenne un correctif né dans un projet parallèle à 23 600 étoiles constituerait un échange d'un genre vraiment nouveau.
Le tableau de benchmarks mérite d'être rejoué par un tiers. C'est la règle que ce blog applique à tout résultat de harnais auto-déclaré : un bond d'un facteur dix sur un modèle appelle les 180 tâches de quelqu'un d'autre avant d'être tenu pour acquis.