Il collo di bottiglia più subdolo per un agente LLM non è la generazione dei token, ma l'attesa. Compilatori, suite di test e comandi di repository possono richiedere da secondi a minuti, durante i quali l'agente resta fermo. Questa "observation stall" è la stessa tensione che ha spinto i progettisti di processori verso l'esecuzione fuori ordine: un'interfaccia sequenziale nasconde lavoro che potrebbe essere previsto e avviato prima, ma un risultato speculativo può diventare visibile solo dopo essere stato validato insieme a tutti i passi precedenti.

TomasuLLM è un runtime che porta questa logica agli agenti LLM. Invece di eseguire le chiamate agli strumenti nell'ordine della traiettoria, "abbozza" azioni future, le esegue in sandbox isolate copy-on-write, traccia dipendenze ed effetti, e committa i risultati nell'ordine originale solo dopo la validazione contro lo stato già consolidato. Su tre benchmark che coprono chiamate da frazioni di secondo a minuti, il runtime migliora le medie riportate: 1,31x su 100 task SWE-bench Verified, 1,35x su 28 task Terminal-Bench 2.0, e 1,27x di progresso abbinato su 18 sessioni SWE-Marathon. Su 4.010 record di validazione controllati, non si registra alcun falso positivo.

La prima implicazione è chiara: il fuori ordine riduce il tempo in cui l'hardware resta inattivo in attesa di uno strumento lento. Per chi gestisce deployment self-hosted o on-premise, questo ha un riflesso diretto sul TCO. Non si tratta di aggiungere più GPU o di passare a modelli più piccoli con quantization spinta: si tratta di estrarre più lavoro dallo stesso hardware, senza rinunciare alla correttezza. I sandbox copy-on-write permettono di eseguire più rami speculativi in isolamento, senza duplicare lo stato completo a ogni tentativo: un vincolo tipico per chi vuole mantenere dati sensibili dentro il perimetro locale.

La seconda implicazione è strutturale. L'ottimizzazione non sta più nel modello, ma nel runtime che lo orchestra. È un segnale che il settore si sta spostando dalla rincorsa ai parametri alla progettazione di sistemi di esecuzione. Per gli utenti che valutano deployment on-premise, questo sposta l'attenzione dal semplice throughput di inference alla capacità di coordinare tool e agenti in modo efficiente e verificabile. Non basta più chiedersi quanti token al secondo produce un LLM; serve chiedersi quanto lavoro utile un agente completa per unità di tempo e con quale garanzia di correttezza.

C'è anche un punto di fiducia. Il fatto che TomasuLLM registri zero falsi positivi su oltre quattromila record non è un dettaglio: significa che la speculazione non compromette la traiettoria consolidata. In contesti dove gli errori hanno costi reali (test di regressione, comandi di repository, pipeline di compilazione), la validazione prima del commit è una condizione necessaria per adottare questo tipo di esecuzione fuori ordine.

Chi beneficia di più? I team che eseguono agenti su infrastruttura propria, dove i tempi morti delle chiamate a strumenti lenti si traducono in capacità inutilizzata. Anche chi gestisce pipeline di sviluppo software con compilazioni o test di lunga durata può vedere miglioramenti nell'ordine del 30% senza cambiare modelli o hardware. Chi perde, invece, sono i fornitori che spingono soluzioni cloud dove il costo è legato al tempo di occupazione della macchina: se un runtime locale riduce il tempo di attesa, la convenienza del cloud per carichi di questo tipo si restringe ulteriormente.

In definitiva, TomasuLLM non è solo un'ottimizzazione: è un promemoria che il collo di bottiglia degli agenti LLM non è sempre il modello, ma il modo in cui il sistema gestisce il tempo e le dipendenze. Per chi valuta deployment on-premise, questa è una variabile da tenere d'occhio nelle analisi di TCO e di sovranità dei dati.