← Tutte le news
ARTICOLO
22 settembre 2026 Aggiornato il 28 ottobre 2026 3 min di lettura

SoL-Pi: meno token negli agenti di coding, ma il risparmio va misurato

SoL-Pi riduce il traffico di token nel benchmark degli autori. Cosa misurare su costi, qualità e gestione dei dati prima di usarlo nei repository aziendali.

In questo articolo
  1. Quattro meccanismi, un solo harness
  2. Cosa ha mostrato il benchmark
  3. Cosa significa per i team di ingegneria
  4. Perché ti interessa: misurare gli agenti di coding

SoL-Pi interviene sul funzionamento degli agenti di coding: nel benchmark degli autori riduce il traffico di token senza peggiorare il risultato rispetto al sistema di riferimento. Questa analisi, aggiornata il 28 ottobre 2026, parte dal paper pubblicato il 17 settembre e distingue i risultati della ricerca dalle verifiche necessarie prima di usarlo sul codice di un'azienda.

Mani che digitano sulla tastiera di un portatile, con righe di codice sorgente sullo schermo e una tazza scura sullo sfondo
Foto: Free-Photos from Pixabay (CC0), Wikimedia Commons. Ritaglio 16:9.

Quattro meccanismi, un solo harness

SoL-Pi combina quattro tecniche che, secondo i ricercatori, hanno superato i test in un insieme crescente di ambienti di sviluppo: Action Fusion, ObservationPack, un Evidence-Preserving Reducer e Online Context Compact. Insieme agiscono su come un agente esegue le azioni, compatta il contesto, gestisce l'output degli strumenti e decide cosa deve rileggere, anziché modificare il modello linguistico sottostante che svolge il ragionamento.

Cosa ha mostrato il benchmark

Su EdgeBench, una valutazione da 51 task, gli autori riferiscono che SoL-Pi eguaglia le prestazioni del suo harness di riferimento Pi con due diversi modelli di supporto, riducendo al contempo il traffico di token registrato dal 44,7% al 49,0% e il costo API di circa un terzo. Si tratta dei numeri riportati dall'articolo sul proprio benchmark — un segnale utile di ciò che è possibile, non una garanzia degli stessi risparmi su una codebase o su una toolchain diversa.

Cosa significa per i team di ingegneria

Il codice è open source su github.com/NVlabs/SoL-Pi, quindi i team che eseguono agenti di coding su larga scala possono testare l'harness sui propri repository e sulla propria strumentazione invece di prendere per buoni i numeri del benchmark indicati nell'articolo. L'interesse iniziale su GitHub non equivale all'adozione in produzione e un guadagno di efficienza a livello di harness non cambia ciò che il modello sottostante può o non può fare — cambia quanto ti costa eseguirlo. Chiunque costruisca su questa base dovrebbe misurare il risparmio di token e di costi sui propri carichi di lavoro prima di citare le cifre dell'articolo in una proposta per un cliente.

Perché ti interessa: misurare gli agenti di coding

Per una prova utile scegli attività che il team svolge davvero: correggere un bug, aggiungere una piccola funzionalità o aggiornare una dipendenza con i relativi test. Ripeti il confronto mantenendo uguali modello, repository, istruzioni e criteri di accettazione. Conta anche tentativi falliti, attese e correzioni manuali: una sessione che consuma meno token ma lascia il lavoro incompleto non rappresenta un risparmio. Conserva il risultato di partenza per poter confrontare le modifiche e annullarle.

Registra separatamente token in ingresso e in uscita, costo fatturato, durata e numero di attività accettate dopo la revisione. Il prezzo dipende dal modello e dalle condizioni del provider: una riduzione del traffico non si traduce automaticamente nella stessa percentuale di sconto. Per un MSP è utile separare le misure per progetto, senza copiare i contenuti di un cliente nei log o nelle prove di un altro. Il confronto deve restare ripetibile anche dopo un aggiornamento.

La gestione delle osservazioni merita un controllo dedicato. Verifica che un errore di compilazione, un test fallito o un avviso di sicurezza restino recuperabili dopo la riduzione del contesto. Definisci dove vengono conservati gli archivi e chi può leggerli, con tempi di cancellazione coerenti con il progetto. Prima di attivare un modello aggiuntivo per sintetizzare i log, controlla il percorso dei dati e le credenziali coinvolte. Un riepilogo utile non deve nascondere le prove necessarie alla revisione.

Parti da una copia isolata del repository e da dati di prova, senza credenziali di produzione. Stabilisci un limite di spesa e una condizione di arresto, poi aumenta il perimetro soltanto se qualità e tempi restano accettabili. La decisione riguarda il costo di un'attività completata e verificata, non un singolo contatore. Per inquadrare questo tipo di valutazione nei processi aziendali, puoi partire dai servizi di intelligenza artificiale di Altovar.

Fonti: arXiv, GitHub.