En bref
Le “harness” est le code qui entoure un LLM — prompts, retrieval, mémoire, logique d’orchestration. Lee et al. (Stanford/MIT/KRAFTON, 2026) montrent que ce code peut produire un gap de performance de 6× sur le même benchmark, avec le même modèle. Meta-Harness est un système d’optimisation automatique de ces harnesses : un coding agent explore l’historique complet des tentatives passées et propose des itérations successives. Résultat sur trois domaines : +7.7 pts en classification de texte avec 4× moins de tokens, +4.7 pts en raisonnement mathématique transférable à 5 modèles non vus, et la première place parmi les agents Claude Haiku 4.5 sur TerminalBench-2.
Le harness compte autant que le modèle
Pensez à un orchestre : un excellent violoniste peut sonner mauvais avec un mauvais chef d’orchestre, et un musicien moyen peut briller dans la bonne configuration. Le LLM est le musicien ; le harness est le chef d’orchestre — c’est lui qui décide quand parler, à qui demander quoi, comment combiner les apports. Meta-Harness automatise le travail de ce chef d’orchestre.
Un harness désigne l’ensemble du code qui détermine ce qu’un modèle reçoit à chaque étape d’une tâche : sélection des exemples few-shot, stratégie de retrieval, format des prompts, gestion de la mémoire, logique de branchement. Ce code est rarement optimisé de façon systématique — il est conçu manuellement, par itérations ad hoc, en modifiant souvent plusieurs dimensions à la fois sans isoler les effets.
Les auteurs documentent un écart de 6× entre le harness le moins performant et le meilleur sur un même benchmark, avec le même modèle de base. Cet écart dépasse en amplitude ce que produisent la plupart des choix de modèles. Le problème du design manuel est structurel : l’espace des harnesses est trop large pour une exploration humaine exhaustive, et les méthodes d’optimisation de texte existantes (OPRO, TextGrad, AlphaEvolve) ne s’y appliquent pas directement — elles optimisent des chaînes de caractères ou des paramètres discrets, pas des programmes arbitraires.
En clair : changer le harness peut multiplier les performances par 6 — un effet plus grand que de changer de modèle. Mais ce harness est du code arbitraire (des programmes Python de 100-1000 lignes), pas un prompt ou un paramètre simple. Aucune méthode existante ne savait l’optimiser systématiquement.
Comment fonctionne Meta-Harness
La boucle propose-evaluate-log
Meta-Harness est un système outer-loop. À chaque itération, un coding agent (le proposer) génère un ou plusieurs harnesses candidats sous forme de fichiers Python single-file. Chaque harness est évalué sur un ensemble d’exemples, et ses résultats — code source, scores, et traces d’exécution complètes — sont archivés dans un répertoire dédié sur le filesystem. La boucle recommence, le proposer ayant accès à l’ensemble de cet historique.
Un run typique évalue entre 40 et 109 harnesses candidats sur 20 à 40 itérations, avec 3 candidats proposés par itération en classification de texte. Le harness évalué est un programme entre 100 et 1 000 lignes de code, qui peut modifier le prompting, la retrieval, la mémoire et l’orchestration spécifiques à la tâche. Le modèle de base reste frozen — seul le code autour de lui varie.
Le filesystem comme canal de feedback
Le choix de conception central est de stocker le feedback sur le filesystem plutôt que dans un prompt. Chaque harness évalué contribue un répertoire contenant son code source, ses scores, et ses traces d’exécution (prompts, appels d’outils, sorties modèle, mises à jour d’état). Le proposer interroge ce filesystem via des outils terminal standards — grep, cat — plutôt qu’en ingérant tout en contexte.
Cela permet une échelle de feedback qualitativement différente des méthodes existantes. Selon les auteurs, un seul token d’évaluation peut produire jusqu’à 10 millions de tokens d’information diagnostique — trois ordres de grandeur au-delà des budgets de feedback de TextGrad (0,015 MTok/iter) ou d’AlphaEvolve (0,022 MTok/iter), contre 10,0 MTok/iter pour Meta-Harness.
En clair : au lieu de mémoriser ce qui a marché et ce qui n’a pas marché, Meta-Harness garde sur disque toutes les traces d’exécution — chaque prompt, chaque appel d’outil, chaque sortie. Le proposer fait du
grepet ducatcomme un humain qui débogue, plutôt que de tout charger en mémoire. Cela explique le facteur 1000× sur le volume de feedback exploitable.
Le coding agent proposer
Le proposer est Claude Code avec Opus 4.6, guidé par un skill domain-spécifique minimal décrivant où écrire les nouveaux harnesses, comment inspecter les harnesses précédents et leurs traces, et quels fichiers il peut ou ne peut pas modifier. Il ne dispose pas de règle de sélection de parent : il est libre d’inspecter n’importe quel harness précédent. La population maintient une frontière de Pareto sur les harnesses évalués — lorsque plusieurs objectifs sont actifs (précision et coût de contexte), la recherche explore librement cette frontière sans contrainte hard-codée.
Résultats
Classification de texte
Sur trois datasets (USPTO-50k, Symptom2Disease, LawBench), Meta-Harness atteint 48,6% de précision moyenne contre 40,9% pour ACE, soit +7,7 points. L’efficience de contexte est simultanément meilleure : 11,4K tokens en moyenne contre 50,8K pour ACE (+4,5×) et 28,5K pour MCE (+2,5×). Meta-Harness occupe la position dominante sur la frontière Pareto accuracy–context.
En termes de vitesse de convergence, Meta-Harness atteint la performance finale de OpenEvolve et TTT-Discover dès la 4e évaluation (sur 40 au total), et dépasse ces méthodes de plus de 10 points en fin de recherche. Sur les 9 datasets hors-distribution non vus pendant la recherche, le gain se maintient : 73,1% contre 70,2% pour ACE (+2,9 points), avec 7,3K tokens contre 11,7K.
Raisonnement mathématique
Un seul harness découvert par Meta-Harness améliore de +4,7 points en moyenne la précision pass@1 sur 200 problèmes de niveau IMO, sur 5 modèles de base non vus pendant la recherche — de 34,1% (sans retriever) à 38,8%. Les gains individuels varient de +1,6 à +8,7 points selon le modèle. Meta-Harness dépasse BM25 retrieval de +1,3 points en moyenne (38,8% vs 37,5%), sans encodeur dense supplémentaire.
Coding agentique (TerminalBench-2)
Avec Claude Haiku 4.5 comme modèle de base, Meta-Harness atteint 37,6% sur TerminalBench-2, premier rang parmi tous les agents Haiku 4.5 rapportés — devant Goose (35,5%), Terminus-KIRA (33,7%), Mini-SWE-Agent (29,8%) et Claude Code (27,5%). Avec Opus 4.6, Meta-Harness atteint 76,4%, deuxième rang derrière ForgeCode (81,8%) — les auteurs notent qu’ils n’ont pas pu reproduire ce score depuis le code public de ForgeCode, suggérant des composants non publiés.
Pourquoi ça marche : les traces complètes
L’ablation qui tranche
L’élément déterminant n’est pas la boucle d’optimisation en elle-même, mais l’accès aux traces d’exécution brutes. L’ablation (Table 3) est nette : scores seuls → médiane 34,6 / meilleur 41,3 ; scores + résumés LLM → médiane 34,9 / meilleur 38,7 ; Meta-Harness complet avec traces → médiane 50,0 / meilleur 56,7. Le nombre de runs dépassant la baseline zero-shot passe de 26 (scores) à 23 (scores+résumés) à 39 (traces complètes).
Les résumés ne récupèrent pas le signal manquant — ils peuvent même nuire en compressant des détails diagnostiquement utiles. La richesse brute des traces est irremplaçable.
En clair : compresser les traces avec un LLM (résumés) détruit le signal exploitable autant que de ne donner que les scores. Le détail brut — le nom exact d’une fonction qui a échoué, l’ordre précis des appels — est ce qui permet au proposer de comprendre POURQUOI une approche a échoué, pas juste qu’elle a échoué.
Comportement non-markovien
Le proposer n’optimise pas en chaîne de Markov. Lors du run TerminalBench-2, il lit en médiane 82 fichiers par itération (plage 69–99), répartis en 41% de code source de harnesses, 40% de traces d’exécution, 6% de fichiers score/résumé, 13% autres. Il référence plus de 20 candidats précédents par itération — pas seulement le parent immédiat. Cette exploration globale de l’historique est un comportement émergent, non prescrit par le skill.
Raisonnement causal
L’analyse qualitative du run TerminalBench-2 illustre un raisonnement structuré. À l’itération 3, le proposer identifie un confound entre modifications de prompt et bugfixes structurels, isole les changements causaux, et pivote vers une modification additive (environment bootstrapping) après 6 régressions consécutives. À l’itération 10, il référence des résultats d’un run de recherche distinct antérieur, effectuant un transfert cross-run explicite. Le harness math découvert fusionne de façon autonome deux lignées de recherche réussies identifiées dans l’historique.
Quand utiliser Meta-Harness vs alternatives
| Contexte | Recommandation | Pourquoi |
|---|---|---|
| Tâche stable, budget API limité (< $1k) | Optimisation manuelle ou OPRO/TextGrad | Meta-Harness coûte 10 MTok/iter — ROI faible si tâche peu valuable |
| Tâche à fort volume production (millions d’appels/mois) | Meta-Harness | Gain de 7,7 pts ou 4× tokens amorti vite à l’échelle |
| Domaine nouveau, harness humain non documenté | Meta-Harness exploratoire | L’historique large compense l’absence de baseline humain |
| Modèle de base récent ou peu connu | Meta-Harness avec proposer Opus | Le système découvre des patterns spécifiques au modèle, transférables à 5 modèles non vus |
Limites et questions ouvertes
Un seul proposer testé. Toutes les expériences utilisent Claude Code avec Opus 4.6 comme proposer. L’effet de la variation de proposer (Sonnet, Haiku, autre modèle) reste non mesuré.
Coût computationnel élevé. Meta-Harness génère ~10 MTok/iter, contre 0,002 à 0,026 MTok/iter pour les méthodes comparées. Le coût API d’un run complet de recherche n’est pas reporté explicitement dans le paper — seul le coût des harnesses évalués est disponible, pas celui du proposer lui-même.
Méthodologie d’évaluation sur TerminalBench-2. Le même benchmark sert à la recherche et à l’évaluation finale, faute de split séparé (benchmark trop petit et coûteux). Les auteurs vérifient l’absence d’overfitting par inspection manuelle et audits regex, mais cette méthodologie reste exposée à une critique d’évaluation non indépendante.
Co-évolution non traitée. Le modèle de base reste frozen pendant toute la recherche. Les auteurs identifient la co-évolution du harness et des poids du modèle comme une direction naturelle, non couverte par ce travail.
Qualité du skill comme levier principal. Les auteurs notent que la qualité du skill text (la description donnée au proposer) est le facteur dominant pour la qualité de la recherche — plus importante que le nombre d’itérations ou la taille de la population. Cette sensibilité au prompt du proposer introduit une dépendance à un paramètre difficile à spécifier de façon optimale.
Ce qu’il faut retenir
- Le harness (code entourant le LLM) peut produire un gap de 6× sur le même benchmark avec le même modèle ; Meta-Harness automatise l’exploration de cet espace.
- L’accès aux traces d’exécution brutes est l’ingrédient clé : les résumés LLM-générés obtiennent des performances comparables aux scores seuls, et bien inférieures aux traces complètes (médiane 34,9 vs 50,0).
- Le système atteint +7,7 pts en classification de texte avec 4× moins de tokens que la baseline ACE, et produit un harness transférable à 5 modèles non vus en raisonnement mathématique.
- Le proposer présente un comportement non-markovien émergent : il consulte l’ensemble de l’historique (médiane 82 fichiers/itération) plutôt que de suivre uniquement la dernière itération.
- Limites principales : un seul proposer testé, coût computationnel de 10 MTok/iter, et absence d’évaluation indépendante sur TerminalBench-2.