Faire progresser un agent IA ne signifie pas forcément entraîner un meilleur modèle. Une part importante de son efficacité dépend du logiciel qui l’entoure : la manière dont il appelle ses outils, conserve son contexte, relit les résultats et vérifie son travail.
C’est précisément le terrain de SoL-Pi, un projet open source développé par NVIDIA avec des chercheurs de NTU et du MIT. Au lieu de modifier les poids du LLM, SoL-Pi optimise le harness de l’agent, son environnement d’exécution, afin de réduire les répétitions inutiles.
Sur EdgeBench, la configuration orientée efficacité conserve 93,7 % du score moyen de Pi, tout en réduisant le trafic de tokens de 49,0 % et le coût API de 33,2 % avec GPT-5.6 Sol. Ce compromis est prometteur, mais il faut le lire entièrement : le score passe de 44,8 à 42,0. Une meilleure efficacité ne signifie donc pas automatiquement une meilleure qualité.
Cet article reprend les points clés de notre vidéo, les confronte au papier SoL-Pi, au site du projet NVIDIA et surtout au code source officiel sur GitHub.
SoL-Pi en bref
SoL-Pi est une extension autonome du coding agent Pi. Elle ajoute quatre mécanismes indépendants qui cherchent chacun une source de dépense évitable : un tour de modèle prévisible, un historique devenu trop long, une observation répétée ou un journal d’exécution surdimensionné.
| Élément | Ce qu’il faut retenir |
|---|---|
| Objet optimisé | Le harness de l’agent, pas les poids du modèle |
| Projet amont | Pi, utilisé via ses interfaces publiques |
| Mécanismes | Action Fusion, ObservationPack, Evidence-Preserving Reducer et Online Context Compact |
| Activation | Chaque mécanisme est optionnel et désactivé par défaut |
| Licence | MIT |
| Évaluation principale | EdgeBench, 51 tâches publiques de travail agentique long |
| Résultat clé | Jusqu’à 49 % de tokens et 33,2 % de coût API en moins face à Pi, avec une baisse de score de 6,3 % |
Le README GitHub de SoL-Pi insiste sur quatre principes : aucune modification de Pi, une activation explicite, la conservation des preuves originales et le respect des choix d’exécution de Pi. Cette architecture est aussi importante que les résultats : le projet n’est pas un nouveau modèle, mais une couche logicielle installée au-dessus d’un agent existant.
Modèle, agent et harness : trois couches différentes
Les discussions sur les agents mélangent souvent trois objets.
Le modèle de langage transforme un contexte en texte ou en appel d’outil. Ses poids déterminent une grande partie de ses capacités, mais le modèle ne décide pas seul de la façon dont les fichiers sont modifiés, les commandes exécutées ou l’historique conservé.
L’agent poursuit un objectif en alternant décisions, actions et observations. Il lit un dépôt, modifie du code, lance des tests, interprète les erreurs puis choisit la suite.
Le harness organise cette boucle. Il expose les outils, construit le contexte envoyé au modèle, stocke l’état de la session, exécute les actions et renvoie leurs résultats. Deux agents utilisant le même modèle peuvent donc afficher des coûts et des performances très différents si leur harness n’organise pas le travail de la même façon.
SoL-Pi agit sur cette troisième couche. C’est un déplacement intéressant : au lieu de demander au modèle de « mieux réfléchir », le système réduit le travail qu’il doit refaire.
Comment les chercheurs ont obtenu ces quatre mécanismes
SoL-Pi vient d’une démarche d’auto-recherche. Les auteurs ont soumis 152 directions à des boucles d’expérimentation automatisées. Chaque piste devait produire une modification exécutable du harness, puis être évaluée selon des critères fixés à l’avance. Quatre mécanismes ont survécu à cette sélection.
Pour éviter d’optimiser directement sur le benchmark final, les tâches publiques d’EdgeBench ont été isolées du processus de recherche. Onze tâches ont servi à une acceptation à sens unique des candidats figés ; les quarante restantes ont été réservées à l’évaluation finale. Un échec sur cet ensemble n’alimentait pas une nouvelle vague d’optimisation.
Cette séparation ne supprime pas tous les risques de surajustement, mais elle rend le résultat plus crédible qu’une boucle qui verrait continuellement les mêmes tâches et leurs erreurs.
Les quatre mécanismes de SoL-Pi
1. Action Fusion : fusionner une action et sa vérification
Après avoir modifié un fichier, un agent lance souvent une commande déjà prévisible : un test ciblé, un linter ou une compilation. Dans une boucle classique, cela exige deux échanges distincts avec le modèle.
Action Fusion permet à l’outil d’édition ou d’écriture d’exécuter immédiatement la commande de validation prévue. Le modèle reçoit ensemble le résultat de la modification et celui du contrôle. Un aller-retour est supprimé lorsque la seconde action ne dépend pas d’une nouvelle décision.
La nuance est essentielle : si le choix de la commande dépend du résultat de l’édition, la fusion ne doit pas court-circuiter le raisonnement intermédiaire.
2. ObservationPack : ne pas rejouer les grandes sorties
Les sorties d’outils volumineuses, comme les fichiers, les logs ou les résultats de recherche, peuvent rester dans l’historique pendant des dizaines de tours. Le modèle paie alors pour relire le même contenu, même lorsque quelques passages suffiraient.
ObservationPack archive localement les grandes observations. Après leur utilisation initiale, le contexte peut contenir une référence stable et un extrait plutôt que le document complet. L’agent conserve un outil de rappel paginé pour retrouver exactement la source si nécessaire.
Il ne s’agit donc pas d’un résumé irréversible. L’information originale demeure disponible ; seule sa projection systématique dans le contexte est évitée.
3. Evidence-Preserving Reducer : réduire un log sans perdre les preuves
Un long journal de test peut contenir des milliers de lignes alors que quelques erreurs déterminent la prochaine action. Le lire avec le modèle principal est coûteux.
Evidence-Preserving Reducer délègue cette première lecture à un modèle configuré pour extraire un reçu compact. Les citations conservées doivent correspondre au journal archivé, et le statut de sortie reste attaché au résultat. Si la réduction ou sa vérification échoue, SoL-Pi renvoie le log d’origine inchangé.
La vérification garantit la fidélité textuelle des extraits, pas l’exhaustivité du diagnostic. Une citation exacte peut encore omettre une information importante : la décision finale reste donc du ressort de l’agent principal.
4. Online Context Compact : compacter au bon moment
La compaction remplace une partie de l’historique par un état plus court : ce qui a été accompli, les preuves importantes et ce qu’il reste à faire. Une compaction trop tardive gaspille des lectures ; une compaction trop précoce peut coûter plus cher qu’elle ne rapporte.
Online Context Compact observe notamment la pression sur la fenêtre de contexte, les étapes terminées et l’horizon estimé de la tâche. Il déclenche la compaction seulement si les lectures futures devraient amortir son coût. Après une compaction réussie, Pi ouvre un nouveau tour et reconstruit le plan à partir de l’état conservé.
Les détails de ces comportements, les valeurs par défaut et leur intégration à Pi sont documentés dans le schéma de configuration GitHub.
Les résultats EdgeBench : coût, tokens et qualité
Les auteurs publient deux profils distincts. SoL-Pi Efficiency active les quatre mécanismes et vise l’économie de tokens. SoL-Pi Performance utilise seulement le mécanisme obtenant le meilleur score pour chaque backend : ObservationPack avec GPT-5.6 Sol, Action Fusion avec Opus 5.
| Backend et harness | Tokens totaux | Coût API | Score moyen |
|---|---|---|---|
| GPT-5.6 Sol · Pi | 2,1538 Md | 1 339 $ | 44,833 |
| GPT-5.6 Sol · SoL-Pi Efficiency | 1,0990 Md | 894 $ | 42,003 |
| GPT-5.6 Sol · SoL-Pi Performance | 2,0224 Md | 1 271 $ | 47,208 |
| Opus 5 · Pi | 2,3697 Md | 1 741 $ | 44,756 |
| Opus 5 · SoL-Pi Efficiency | 1,3101 Md | 1 158 $ | 42,224 |
| Opus 5 · SoL-Pi Performance | 2,1016 Md | 1 605 $ | 50,482 |
Avec GPT-5.6 Sol, le profil Efficiency réduit donc le volume total de tokens de 49,0 % et le coût de 33,2 %, tout en perdant 6,3 % de score face à Pi. Le profil Performance produit le mouvement inverse : +5,3 % de score, avec 6,1 % de tokens en moins.
Le transfert vers Opus 5 est un autre signal intéressant. Les mécanismes ont été recherchés avec GPT-5.6 Sol, puis appliqués à Opus 5 sans nouvelle recherche ni adaptation. Le profil Efficiency conserve 94,3 % du score de Pi, réduit le trafic de tokens de 44,7 % et le coût de 33,5 %.
Ces chiffres sont les résultats rapportés par les auteurs, pas nos propres mesures. Les montants utilisent les prix API du 17 août 2026 et ne doivent pas être lus comme des tarifs actuels. Le score EdgeBench n’est pas non plus un simple taux de tâches réussies.
Une économie peut masquer davantage d’échecs
Terminal-Bench 4 montre pourquoi il faut suivre la qualité et le coût simultanément. Sur 63 tâches ne nécessitant pas de GPU, Pi en résout 18 et SoL-Pi 15. Le coût total passe néanmoins de 286,45 $ à 211,12 $, et le coût par tâche résolue de 15,91 $ à 14,07 $.
SoL-Pi est donc plus économique selon cette métrique, mais il laisse trois tâches supplémentaires non résolues. Selon le contexte métier, ces échecs peuvent coûter beaucoup plus cher que les tokens économisés.
L’évaluation sur six problèmes de l’IMO 2026, formalisés et vérifiés en Lean 4, aboutit à trois problèmes réussis pour Pi comme pour SoL-Pi. Le coût descend de 75,95 $ à 62,69 $, soit 20,90 $ par problème validé contre 25,32 $ pour Pi. Ici encore, l’échantillon est trop petit pour établir une règle générale.
La bonne métrique n’est donc pas « combien de tokens avons-nous économisés ? », mais quel est le coût total d’une tâche correctement terminée, vérifiée et exploitable ?
Ce que montre l’expérience d’essaim d’agents
Les chercheurs ont aussi comparé trois configurations pendant deux heures : un agent GPT-5.6 Sol seul, un coordinateur Sol pilotant vingt agents Luna équipés de Pi, et le même essaim équipé de SoL-Pi.
Les vingt workers étaient répartis en cinq groupes de quatre. Chaque groupe partageait un tableau de preuves, tandis que le coordinateur transmettait les découvertes utiles entre groupes. Une amélioration ne devenait la nouvelle référence qu’après soumission d’un instantané immuable et vérification indépendante.
Sur la tâche d’optimisation de kernel, l’essaim SoL-Pi atteint 1 127 cycles pour 60,11 $, contre 1 366 cycles pour 82,12 $ avec l’essaim Pi. Cela représente 17,5 % de cycles en moins et 26,8 % de coût en moins. L’agent seul reste toutefois moins cher, avec 39,20 $ pour un résultat à 1 333 cycles.
Ce test illustre l’intérêt d’un harness plus efficace lorsque le nombre d’agents augmente. Mais il ne comporte qu’une exécution de deux heures par condition : il ne mesure ni la variance ni la probabilité de reproduire le même classement.
Installer SoL-Pi et comprendre ses réglages
Le dépôt officiel demande Node.js 22.19 ou plus récent et la version testée de Pi. L’installation documentée est courte :
npm install --global @earendil-works/pi-coding-agent@0.85.1
pi install git:github.com/NVlabs/SoL-Pi
Le fichier sol-pi.json peut être placé dans .pi/ pour un projet approuvé ou dans le répertoire global de l’agent. Les configurations ne sont pas fusionnées : le fichier du projet, lorsqu’il est autorisé, remplace le fichier global.
Une configuration prudente peut commencer par les deux mécanismes locaux qui n’appellent aucun modèle supplémentaire :
{
"version": 1,
"actionFusion": true,
"observationPack": true,
"evidencePreservingReducer": false,
"onlineContextCompact": false,
"cacheWriteReadRatio": 12.5
}
Le fichier d’exemple du dépôt laisse les quatre fonctions à false. Ce choix est sain : une optimisation du harness modifie la façon dont l’agent exécute les actions et gère ses données. Elle doit être testée sur un corpus interne avant d’être activée largement.
Sécurité : ce qu’il faut vérifier avant la production
SoL-Pi n’est pas une sandbox. D’après sa politique de sécurité GitHub, l’extension hérite des accès au système de fichiers, aux processus, au réseau et aux identifiants accordés au processus Pi.
Quatre précautions en découlent :
- Action Fusion peut modifier des fichiers et lancer des commandes ; les permissions du processus doivent rester minimales.
- ObservationPack conserve des résultats d’outils dans le répertoire de session ; leur cycle de rétention doit être gouverné.
- Evidence-Preserving Reducer peut envoyer des logs à un modèle distant lorsqu’il est activé. Son détecteur de secrets est une précaution, pas une garantie d’étanchéité.
- Online Context Compact stocke le plan, des chemins, des commandes et des notes dans le journal de session ; ces données sont aussi sensibles que la conversation.
Pour une adoption en entreprise, nous commencerions par un environnement isolé, des tâches représentatives et un jeu d’évaluation gelé. Il faut mesurer au minimum le taux de tâches terminées, le coût par réussite, les erreurs d’outils, les régressions de contexte et la capacité à retrouver une preuve archivée.
Le lien avec l’auto-amélioration récursive
SoL-Pi s’inscrit dans une famille de travaux sur le Recursive Self-Improvement : un système améliore son propre fonctionnement, puis la version améliorée participe au cycle suivant. La récursion ne suppose pas nécessairement de réentraîner le modèle ; elle peut porter sur le code, les outils et l’organisation du travail.
La Darwin Gödel Machine rend cette auto-référence plus directe. L’agent modifie sa propre implémentation, évalue le descendant sur des benchmarks et conserve plusieurs variantes dans une archive. Dans le papier de 2025, le meilleur agent passe de 20 % à 50 % sur un sous-ensemble de 200 tâches SWE-bench Verified, et de 14,2 % à 30,7 % sur le benchmark Polyglot complet, sans modification des poids du modèle. Le dépôt officiel DGM publie le code et avertit explicitement des risques liés à l’exécution de code généré par un modèle.
SoL-Pi ne démontre pas une amélioration récursive illimitée. Les auteurs formulent plutôt l’hypothèse d’une Recursive Efficient Improvement : si un harness moins coûteux permet de financer davantage d’expériences dans la boucle de recherche suivante, celle-ci pourrait découvrir un successeur encore plus efficace. Le papier présente clairement cette idée comme une perspective de long terme, pas comme un effet cumulatif déjà observé.
Notre lecture de SoL-Pi
La contribution la plus utile de SoL-Pi n’est pas un pourcentage isolé. Le projet montre que le coût d’un agent vient aussi de son organisation : combien de fois il relit la même information, combien de tours il consomme pour une action prévisible et comment il transforme les résultats d’outils en preuves exploitables.
Les quatre mécanismes sont concrets, inspectables et disponibles sous licence MIT. Ils dessinent aussi une méthode applicable au-delà de Pi : observer les traces réelles, identifier les répétitions, modifier une seule couche du harness, puis comparer qualité, coût et robustesse sur des tâches tenues à l’écart de la recherche.
La limite est tout aussi claire. Économiser des tokens n’a de valeur que si le système termine encore les tâches qui comptent. Le bon déploiement ne consiste donc pas à activer toutes les optimisations, mais à choisir un profil, définir un seuil de qualité et vérifier le coût par résultat utile.
