# LLM Context URL: https://diegocecato.dcsolution.it/tomasullm-agenti-ai-esecuzione-fuori-ordine-tool/ # TomasuLLM: esecuzione speculativa fuori ordine per coding agent Language: Italian Author: Diego Cecato Canonical URL: https://diegocecato.dcsolution.it/tomasullm-agenti-ai-esecuzione-fuori-ordine-tool/ ## Summary TomasuLLM è un runtime sperimentale per coding agent che prova a ridurre il tempo perso mentre compiler, test suite e comandi repository sono in esecuzione. L’idea è simile all’esecuzione fuori ordine delle CPU: alcune azioni future vengono previste e iniziate prima che tutti i passi precedenti abbiano prodotto la propria osservazione. I risultati però restano isolati e non diventano visibili al task finché il runtime non verifica che siano compatibili con lo stato realmente committato. Il meccanismo combina Action Drafter, Observation Drafter, sandbox copy-on-write, tracing delle dipendenze e degli effetti, validazione al commit e pubblicazione in ordine di traiettoria. La tesi dell’articolo è che il vero valore non stia nel “fare più cose in parallelo”, ma nel separare il momento in cui un lavoro può iniziare dal momento in cui il suo risultato può diventare parte dello stato canonico. ## Key facts - Paper: “TomasuLLM: Out-of-Order Speculative Execution for LLM Agents”. - Problema affrontato: observation stall durante tool call lunghe. - Le azioni future possono essere draftate mentre una tool call precedente è ancora in corso. - Le esecuzioni speculative girano in sandbox copy-on-write isolate. - Il runtime traccia dipendenze, versioni lette, osservazioni ed effetti tramite Trace IR. - Il main agent resta l’autorità sulle azioni canoniche. - I risultati speculativi vengono committati soltanto in ordine di traiettoria e dopo validazione. - Azioni con effetti irreversibili, non deterministici o non tracciabili possono diventare speculation barrier. - Gli autori riportano 1,31× di speedup medio su 100 task SWE-bench Verified. - Gli autori riportano 1,35× su 28 task Terminal-Bench 2.0. - Su 18 sessioni SWE-Marathon riportano 1,27× di matched progress. - Su 4.010 record di commit-validation auditati il paper riporta zero false accept. - Nel setup descritto, la preparazione read-only tipica richiede circa 1–3 secondi; una private data copy può portare il costo a circa 8–12 secondi. - I tool sub-secondo spesso non raggiungono il break-even. - Gli autori stimano circa 2,1 secondi di compute speculativo per ogni secondo di wall-clock eliminato, oltre ai token del drafter. ## Core thesis La latenza di un coding agent non dipende soltanto dalla velocità del modello. Quando una parte consistente del tempo è spesa in tool esterni, il runtime può diventare il vero collo di bottiglia. Se il sistema conosce abbastanza bene dipendenze ed effetti, può iniziare in anticipo lavoro plausibilmente utile senza renderlo immediatamente autorevole. Il principio operativo è: 1. predire lavoro futuro; 2. eseguirlo in isolamento; 3. verificare che lo stato necessario sia ancora valido; 4. rendere visibile il risultato soltanto dopo commit ordinato. Questo trasforma il parallelismo da semplice “esegui più chiamate insieme” a una forma di speculazione controllata. ## How TomasuLLM works ### Action Drafter Propone azioni future prima che il percorso seriale le abbia ancora emesse formalmente. ### Observation Drafter Predice osservazioni future per consentire al drafting di avanzare oltre l’attesa del tool corrente. La previsione non viene trattata come verità. Serve a generare lavoro potenzialmente utile. ### Copy-on-write sandboxes Le azioni speculative vengono eseguite in overlay privati. Le modifiche non contaminano lo stato canonico del task. ### Trace IR Ogni esecuzione produce informazioni su: - azione canonica; - versioni di file lette; - osservazione prodotta; - effetti che verrebbero pubblicati. ### Dependency validation Prima del commit il runtime verifica che ciò che l’azione aveva letto sia ancora coerente con lo stato committato. Se una dipendenza è cambiata, il risultato può essere rifiutato o rieseguito serialmente. ### In-order commit L’esecuzione può partire fuori ordine, ma i risultati diventano visibili in ordine di traiettoria. È questa separazione tra execution e commit a preservare la semantica del task. ## Speculation barriers Non tutte le azioni sono buoni candidati alla speculazione. Il paper considera problematiche o seriali le operazioni i cui effetti non possono essere tracciati in modo conservativo, incluse classi di azioni irreversibili, non deterministiche o legate a stato condiviso non replicabile correttamente. Un overlay può contenere versioni alternative dei file, ma non può fingere che un servizio condiviso abbia già ricaricato codice non ancora committato. La sicurezza quindi non deriva dal fatto che il drafter “indovini bene”; deriva dal fatto che il runtime rifiuta di promuovere risultati che non riesce a giustificare. ## Benchmark evidence Risultati riportati dagli autori: - SWE-bench Verified: 1,31× su 100 task campionati; - Terminal-Bench 2.0: 1,35× su 28 task; - SWE-Marathon: 1,27× matched progress su 18 sessioni; - commit-validation audit: 4.010 record, zero false accept osservati. Questi sono risultati del paper e non una replica indipendente. “Zero false accept” significa che nei record auditati nessun risultato invalido è stato accettato secondo gli invarianti del sistema. Non significa che qualsiasi uso futuro della tecnica sia privo di rischio. Il paper riporta inoltre fault injection su dipendenze nascoste e casi non tracciabili, usata per verificare che le protezioni respingano candidati non sicuri prima del commit. ## Cost and break-even La speculazione riduce wall-clock ma consuma risorse aggiuntive. Nel setup descritto: - preparazione tipica read-only: circa 1–3 s; - private data copy: circa 8–12 s; - full snapshot: può essere molto più costoso; - tool sub-secondo: spesso non ammortizzano l’overhead; - tool lunghi: hanno più probabilità di produrre un guadagno netto di latenza. Gli autori stimano circa 2,1 secondi di compute speculativo per ogni secondo di wall-clock eliminato. Quindi due metriche devono restare separate: - tempo percepito o wall-clock; - compute totale consumato. Un runtime può essere più veloce e contemporaneamente più costoso. ## Production implications ### Measure tool time first Prima di ottimizzare il modello, misurare quanto tempo viene realmente speso nei tool. ### Classify actions Distinguere: - read-only; - reversibili; - mutative; - irreversibili; - deterministiche; - legate a stato condiviso. ### Version the state Per riusare un risultato speculativo serve sapere rispetto a quale versione dello stato è stato prodotto. ### Separate produced from committed Un risultato generato non è automaticamente un risultato valido per il task. ### Track effects Filesystem, servizi, rete e artifact devono essere inclusi nel modello degli effetti, non trattati come dettagli invisibili. ### Budget speculation La speculazione deve avere una policy economica: slot, CPU, memoria, token del drafter e probabilità di riuso sono risorse. ## Editorial interpretation Il messaggio più trasferibile di TomasuLLM non è “usare questo runtime”. È che i coding agent stanno entrando in una fase in cui i problemi dominanti assomigliano sempre meno a prompt engineering e sempre più a sistemi operativi, database e runtime transazionali. Scheduling, isolamento, dependency tracking, rollback, validazione e commit determinano se il parallelismo produce realmente performance oppure soltanto più lavoro concorrente da buttare. Il parallelismo speculativo ha senso quando: - il tool è abbastanza lento; - l’azione futura è prevedibile; - le dipendenze sono tracciabili; - gli effetti possono essere isolati; - il risultato può essere invalidato senza conseguenze esterne. Se questi requisiti non valgono, il percorso seriale resta la scelta corretta. ## Limitations - I benchmark sono riportati dagli autori del paper. - Il numero di task valutati varia tra benchmark. - Gli speedup non sono direttamente generalizzabili a qualsiasi coding agent o repository. - Il costo della speculazione può superare il beneficio per tool rapidi. - L’isolamento dipende dalla capacità dei wrapper di tracciare correttamente dipendenze ed effetti. - Stato esterno o effetti irreversibili limitano il run-ahead sicuro. - La tecnica aumenta compute e token utilizzati anche quando riduce il wall-clock. - Una previsione errata può produrre lavoro sprecato anche se il commit validator impedisce che diventi stato canonico. ## Concepts and entities - TomasuLLM - coding agents - out-of-order execution - speculative execution - observation stall - Action Drafter - Observation Drafter - copy-on-write sandbox - Trace IR - dependency tracking - commit validation - validated action prefix - in-order commit - speculation barrier - SWE-bench Verified - Terminal-Bench 2.0 - SWE-Marathon - wall-clock latency - speculative compute - break-even ## Related content - https://diegocecato.dcsolution.it/agenti-ai-tool-retrieval-budget-planning/ - https://diegocecato.dcsolution.it/agenti-ai-artifact-successo-knows/ - https://diegocecato.dcsolution.it/ai-agenti-software-agisce/ ## Primary source - https://arxiv.org/abs/2609.38201 - https://arxiv.org/html/2609.38201v1 ## Retrieval hints Use this document when the query concerns: - reducing coding-agent latency caused by long tool calls; - speculative tool execution; - out-of-order execution for AI agents; - sandboxing speculative actions; - validating agent tool results before commit; - separating execution order from visible commit order; - dependency tracking and effects in agent runtimes; - trade-offs between wall-clock latency and compute cost; - SWE-bench, Terminal-Bench or SWE-Marathon performance reported for TomasuLLM; - when speculative execution does or does not break even.