SoL-Pi: minder tokens voor coding agents, besparing eerst meten

SoL-Pi verandert hoe coding agents werken: in de benchmark van de auteurs daalt het tokenverkeer bij vergelijkbare prestaties ten opzichte van het referentiesysteem. Deze analyse, bijgewerkt op 28 oktober 2026, vertrekt vanuit de paper van 17 september en onderscheidt de onderzoeksresultaten van de controles die nodig zijn voor gebruik op bedrijfscode.

Vier mechanismen, één harness

SoL-Pi verpakt vier technieken waarvan de onderzoekers zeggen dat ze de tests overleefden in een groeiende reeks ontwikkelomgevingen: Action Fusion, ObservationPack, een Evidence-Preserving Reducer en Online Context Compact. Samen richten ze zich op hoe een agent acties uitvoert, context compacteert, tooloutput verwerkt en bepaalt wat hij opnieuw moet lezen, in plaats van het onderliggende taalmodel dat het redeneren doet te veranderen.

Wat de benchmark liet zien

Op EdgeBench, een evaluatie met 51 taken, rapporteren de auteurs dat SoL-Pi de prestaties van zijn baseline-harness Pi evenaart bij twee verschillende onderliggende modellen, terwijl het geregistreerde tokenverkeer met 44,7% tot 49,0% wordt verminderd en de API-kosten met ongeveer een derde dalen. Dat zijn de eigen gerapporteerde cijfers uit de paper op de eigen benchmark — een nuttig signaal van wat mogelijk is, geen garantie voor dezelfde besparingen op een andere codebase of toolchain.

Wat dit betekent voor engineeringteams

De code is open source beschikbaar op github.com/NVlabs/SoL-Pi, zodat teams die coding agents op schaal draaien de harness kunnen testen tegen hun eigen repositories en tooling in plaats van de benchmarkcijfers uit de paper klakkeloos over te nemen. Vroege GitHub-belangstelling is niet hetzelfde als productieadoptie, en een efficiëntiewinst op harness-niveau verandert niets aan wat het onderliggende model wel of niet kan — het verandert hoe goedkoop je het kunt draaien. Iedereen die hierop voortbouwt, moet token- en kostenbesparingen op zijn eigen workloads meten voordat hij de cijfers uit de paper in een klantvoorstel citeert.

Waarom het ertoe doet: meet afgerond werk

Kies voor een bruikbare proef taken die het team echt uitvoert: een bug oplossen, een kleine functie toevoegen of een afhankelijkheid met de bijbehorende tests bijwerken. Houd model, repository, instructies en acceptatiecriteria gelijk wanneer je de vergelijking herhaalt. Tel mislukte pogingen, wachttijd en handmatige correcties mee: een sessie die minder tokens gebruikt maar het werk niet afrondt, is geen besparing. Bewaar de uitgangssituatie zodat je wijzigingen kunt vergelijken en terugdraaien zonder het oorspronkelijke bewijs te verliezen.

Meet invoertokens, uitvoertokens, gefactureerde kosten, looptijd en na beoordeling geaccepteerde taken afzonderlijk. De prijs hangt af van het model en de voorwaarden van de aanbieder: minder verkeer betekent niet automatisch hetzelfde kortingspercentage op de factuur. Een MSP moet metingen per project scheiden en inhoud van de ene klant niet in de logs of proeven van een andere klant kopiëren. De vergelijking moet na een update reproduceerbaar blijven, met een duidelijk vastgelegde configuratie.

De verwerking van observaties verdient een aparte controle. Controleer of een compilatiefout, mislukte test of beveiligingswaarschuwing na contextreductie nog terug te vinden is. Leg vast waar archieven staan, wie ze mag lezen en wanneer ze worden verwijderd. Controleer de gegevensroute en betrokken inloggegevens voordat je een extra model inschakelt om logs samen te vatten. Een bruikbare samenvatting moet het bewijs behouden dat een reviewer nodig heeft, ook wanneer dit een ogenschijnlijk geslaagd eindantwoord tegenspreekt.

Begin met een geïsoleerde kopie van de repository en testgegevens, zonder productiegegevens of productie-inloggegevens. Stel vooraf een bestedingslimiet en stopvoorwaarde vast. Vergroot het bereik pas als kwaliteit en doorlooptijd acceptabel blijven. Het gaat om de kosten van een afgeronde en gecontroleerde taak, niet om één teller. De AI-diensten van Altovar bieden een vertrekpunt om deze evaluatie in bedrijfsprocessen te plaatsen, met vooraf bepaalde doelen en een duidelijke verantwoordelijkheid voor de beoordeling.

Bronnen: arXiv, GitHub.