SoL-Pi : moins de tokens pour les agents de code, un gain à mesurer

SoL-Pi modifie le fonctionnement des agents de code : dans le benchmark de ses auteurs, il réduit le trafic de tokens avec des performances comparables au système de référence. Cette analyse, actualisée le 28 octobre 2026, part de l'article publié le 17 septembre et distingue ses résultats des vérifications nécessaires avant de l'utiliser sur le code d'une entreprise.

Quatre mécanismes, un seul harnais

SoL-Pi regroupe quatre techniques qui, selon les chercheurs, ont résisté aux tests dans un ensemble croissant d'environnements de développement : Action Fusion, ObservationPack, Evidence-Preserving Reducer et Online Context Compact. Ensemble, elles ciblent la manière dont un agent exécute des actions, compacte le contexte, traite la sortie des outils et décide ce qu'il doit relire, plutôt que de modifier le modèle de langage sous-jacent qui effectue le raisonnement.

Ce que le benchmark a montré

Sur EdgeBench, une évaluation de 51 tâches, les auteurs indiquent que SoL-Pi égale les performances de son harnais de référence, Pi, avec deux modèles sous-jacents différents, tout en réduisant le trafic de jetons enregistré de 44,7 % à 49,0 % et en diminuant le coût API d'environ un tiers. Il s'agit des chiffres rapportés par l'article sur son propre benchmark — un signal utile de ce qui est possible, et non une garantie des mêmes économies sur une base de code ou une chaîne d'outils différente.

Ce que cela signifie pour les équipes d'ingénierie

Le code est publié en open source sur github.com/NVlabs/SoL-Pi, de sorte que les équipes qui exécutent des agents de codage à grande échelle peuvent tester le harnais sur leurs propres dépôts et outils plutôt que de prendre les chiffres du benchmark de l'article pour argent comptant. L'intérêt précoce sur GitHub n'équivaut pas à une adoption en production, et un gain d'efficacité au niveau du harnais ne change pas ce que le modèle sous-jacent peut ou ne peut pas faire — il change le coût de son exécution. Toute personne s'appuyant sur ce travail devrait mesurer les économies de jetons et de coûts sur ses propres charges de travail avant de citer les chiffres de l'article dans une proposition client.

Pourquoi c'est important : mesurer le travail terminé

Pour un essai utile, choisissez des tâches réellement effectuées par l'équipe : corriger un bug, ajouter une petite fonctionnalité ou mettre à jour une dépendance avec ses tests. Répétez la comparaison avec le même modèle, le même dépôt, les mêmes consignes et critères d'acceptation. Comptez également les tentatives infructueuses, les attentes et les corrections manuelles : une session moins gourmande en tokens qui ne termine pas le travail ne constitue pas une économie. Conservez l'état initial pour comparer et annuler les modifications.

Mesurez séparément les tokens entrants et sortants, le coût facturé, la durée et les tâches acceptées après révision. Le prix dépend du modèle et des conditions du fournisseur : une baisse du trafic ne produit pas automatiquement la même réduction sur la facture. Un MSP doit distinguer les mesures par projet, sans copier les contenus d'un client dans les journaux ou les essais d'un autre. La comparaison doit rester reproductible après une mise à jour, avec une configuration précisément documentée.

Le traitement des observations mérite une vérification spécifique. Une erreur de compilation, un test échoué ou un avertissement de sécurité doivent rester accessibles après la réduction du contexte. Définissez où sont conservées les archives, qui peut les consulter et quand elles seront supprimées. Avant d'activer un modèle supplémentaire pour résumer les journaux, vérifiez les flux de données et les identifiants utilisés. Un résumé utile doit préserver les éléments nécessaires à la révision, y compris ceux qui contredisent une réponse finale apparemment réussie.

Commencez avec une copie isolée du dépôt et des données de test, sans accès à la production. Fixez un plafond de dépenses et une condition d'arrêt, puis élargissez le périmètre seulement si la qualité et les délais restent acceptables. La décision porte sur le coût d'une tâche terminée et vérifiée, pas sur un compteur isolé. Pour inscrire cette évaluation dans les processus de l'entreprise, les services d'intelligence artificielle d'Altovar constituent un point de départ, avec des objectifs et une responsabilité de révision clairement définis.

Sources : arXiv, GitHub.