HarnessTax : l'impact réel du harness sur les agents de code
En bref
- Une étude examine si le choix du harness (l'infrastructure d'exécution et de contexte) influe vraiment sur la performance des agents de code, ou si le modèle sous-jacent prime.
- Les résultats suggèrent que les différences entre harnesses sont moins décisives qu'attendu, mais que l'adéquation harness-modèle compte davantage que la notoriété du couple.
- La vraie variable cachée est la gestion du contexte : deux harnesses peuvent faire le même nombre d'appels modèle en consommant des quantités très différentes de tokens.
- Les harnesses propriétaires (Claude Code, Codex) bénéficient d'une fine-tuning continue, ce qui les rend difficiles à comparer de façon stable.
Ce que dit la source
L'étude pose une question pratique : quel poids réel a le harness (la couche d'orchestration, d'exécution et de gestion du contexte) dans la performance d'un agent de code ? Les harnesses propriétaires (Claude Code, OpenAI Codex) présument d'être optimisés pour leurs modèles respectifs, mais est-ce vérifié empiriquement ? Et inversement, un harness open source générique peut-il surpasser un harness propriétaire dédié ?
- Les harnesses sont critiques pour éviter les erreurs d'édition et les appels d'outils échoués, mais n'améliorent pas significativement l'intelligence brute du modèle.
- Les modèles plus récents semblent moins sensibles au harness spécifique du fournisseur et mieux réagir aux outils natifs, mais pires avec les outils personnalisés qui ressemblent à des outils par défaut.
- Un harness optimisé pour un modèle (ex. Edit() pour Claude vs apply_patch() pour GPT) performe mieux que l'inverse, même avec des alternatives réputées.
- La vraie variable cachée est la gestion du contexte, pas le nombre d'appels modèle : deux harnesses identiques en appels peuvent consommer 2× le contexte l'un de l'autre.
- Les harnesses propriétaires facturent des system prompts gonflés avec des instructions de sécurité et d'autres charges que l'utilisateur ne souhaite pas forcement payer.
- Pi (un harness minimaliste) atteindrait une efficacité tokens comparable à Claude Code ou Codex, ce qui contredit l'hypothèse que la complexité propriétaire justifie le surcoût.
- Les harnesses propriétaires changent plusieurs fois par semaine et fine-tune continuellement leur inférence, rendant tout benchmark statique obsolète rapidement.
Dans les commentaires
Débat partagé et substantiel. Une moitié valorise la minimalité et l'interopérabilité, l'autre reconnaît que le tuning spécifique au modèle reste crucial, mais surtout sur des dimensions cachées (contexte, inférence continue) plutôt que sur la sophistication du harness lui-même.
- Plusieurs commentateurs contestent la pertinence de benchmarker un harness seul : les variables qui comptent vraiment sont l'exécution parallèle, la délégation à des sous-agents et l'adaptation du harness au modèle utilisé, non la structure générale du harness.
- Une part du fil dénonce l'instabilité : les harnesses propriétaires changent trop souvent (plusieurs fois par semaine) et affinent continuellement l'inférence pour que tout benchmark statique soit fiable au-delà de quelques jours.
- Quelques commentateurs signalent que le comparer les harnesses ignore le facteur décisif : si vous payez l'API, presque tout harness open source beat les propriétaires en coût, sauf si vous avez besoin de la continuité UI/UX du propriétaire.
- Un argument récurrent : la minimité du harness aide à la compréhension et à l'adaptation personnelle bien davantage que sa richesse fonctionnelle, surtout en usage headless ou via API.
- L'interopérabilité (pouvoir changer de modèle et de fournisseur sans refonte) émerge comme priorité oubliée, systématiquement sacrifiée par les harnesses propriétaires.
Alternatives citées : OpenCode (harness open source générique), Pydantic-AI (wrapper Python minimaliste pour plusieurs modèles), Claude Code (Anthropic), Codex (OpenAI), GLM (par Alibaba/Zhipu), ZCode (avec affinité GLM)
Notre lecture
Intéressant pour les équipes qui déploient des agents de code en production, moins décisif qu'il n'y paraît. Le harness a un rôle, mais trois points surtout : (1) l'adéquation harness-modèle compte plus que la notoriété du couple, (2) le vrai coût caché est la gestion du contexte, pas le nombre d'appels, (3) les harnesses propriétaires ne restent jamais stables longtemps. Pour une DSI, l'arbitrage n'est pas tant harness A vs B que build lean + propriétaire vs build lean + interopérable. La recherche suggère que le minimalisme beats complexité, sauf si votre workflow nécessite l'UI du propriétaire, auquel cas vous payez une rente, pas une performance.