OSWorld 2.0: il benchmark che misura un pomeriggio di lavoro reale
108 task, oltre 300 passi, 31 applicazioni: sul lavoro reale gli agenti falliscono 4 task su 5. Non è questione di intelligenza, ma di architettura.
Misuriamo gli agenti su compiti da trenta passi: apri una issue, scrivi una patch, chiudi. Poi li mettiamo davanti a un pomeriggio vero. Recuperare una ricevuta su Gmail, incrociarla con l'estratto conto, compilare un rimborso spese, seguire un tutorial video, controllare che il codice non trascini con sé una chiave API. Lì il numero cambia. Su OSWorld 2.0, il benchmark che misura esattamente quel pomeriggio, il miglior agente valutato nel paper completa 1 task su 5.
Cosa dice letteralmente: 108 task, 300 passi, un'ora e mezza
Il paper di XLANG Lab definisce il benchmark con pochi numeri, e sono numeri che scelgono una direzione. 108 task completi, non singole azioni dentro una sola applicazione. Una traiettoria media supera i 300 passi (il paper parla di una media di 318 tool call con Claude Opus 4.7), contro i circa 30 di OSWorld 1.0. Il tempo umano mediano per portare a termine un task è di circa 1,6 ore, e il 69,6% dei task richiede a un esperto più di un'ora. I task girano su 31 siti web self-hosted e applicazioni desktop, valutati con punteggio parziale su una media di 27,25 checkpoint per task invece del solo pass/fail.
Il repo è aperto: xlang-ai/OSWorld-V2 contiene l'ambiente, i runner dei modelli e il codice dei 31 siti self-hosted. Le classi dei task sono distribuite tramite un dataset Hugging Face ad accesso controllato, per ridurre il rischio che un agente trovi le risposte online mentre sta eseguendo il task.
I fenomeni che i task mettono alla prova sono dieci, e vanno dal ragionamento tra fonti diverse all'inferenza di uno stato implicito, dagli ambienti dinamici all'interazione in streaming, fino alla precisione visuo-spaziale. Ogni task parte da artefatti di input autentici e da profili utente realistici.
Il numero che conta: 20,6% di completamento binario
A 500 passi di budget, nel paper Claude Opus 4.8 con thinking massimo e tool call in batch completa il 20,6% dei task, con un punteggio parziale del 54,8%. GPT-5.5 si ferma attorno al 13% ma è molto più efficiente in token. La leaderboard live mostra il fronte che si è già spostato: Claude Opus 5 è al 31,43% binario e al 68,31% parziale.
Il punteggio parziale esiste per un motivo: su task così lunghi fallire non significa non aver fatto nulla, e i 27,25 checkpoint registrano quanta parte del lavoro è stata completata.
Dove inciampano gli agenti, il paper lo dice senza giri: non sul controllo della GUI o sulla scrittura di codice, ma sul resto. Perdono i vincoli del task, mancano le informazioni che arrivano a metà percorso, ipotizzano invece di chiedere all'utente, saltano la verifica. Il punto in cui falliscono di più è quando il task dipende da uno stato nascosto che devono ricostruire da soli.
Cosa il paper non dice: i benchmark corti non predicono il lavoro lungo
Il paper è esplicito sul fallimento, implicito sul perché i benchmark precedenti non lo vedevano. OSWorld 1.0 era vicino alla saturazione: i sistemi migliori superavano l'80% di accuratezza, e un benchmark risolto smette di dirti dove gli agenti si rompono davvero. La differenza non è di difficoltà, ma di struttura. In un task da trenta passi dentro una sola app, la memoria non ha il tempo di degradare e l'ambiente non cambia mentre lavori.
Su OSWorld 2.0 l'ambiente è dinamico: una notifica Gmail arriva a metà task e il piano va riscritto. Il benchmark mette a disposizione anche un utente simulato a cui l'agente può chiedere chiarimenti, e il dato che emerge è che gli agenti preferiscono indovinare. L'agente opera in un loop percettivo che Mengqi Yuan, al reading group di Snorkel, descrive come «chiudere gli occhi per pensare e riaprirli per agire»:
«Chiudere gli occhi per pensare e riaprirli per agire.»
Se il mondo cambia tra lo screenshot e l'azione, l'azione è corretta per lo stato che l'agente ha visto e sbagliata per quello che esiste quando la esegue. Qui arriva la lettura che le fonti non formulano. Un agente che passa un benchmark corto stile SWE-bench può fallire sistematicamente su un flusso multi-app a 300 passi.
Cosa si rompe: il punteggio parziale nasconde il divario
È qui che l'artefatto mostra la sua tensione interna. Il punteggio parziale di Opus 5 (68,31%) suona come un progresso solido, ma il completamento binario resta sotto un terzo (31,43%): più di due task su tre non arrivano in fondo. Il punteggio a checkpoint valuta lo stato finale della macchina virtuale, non la sequenza: un agente che sbaglia l'inizio ma indovina la fine può comunque accumulare credito sui checkpoint finali. In parallelo corre un audit di sicurezza su otto diagnostiche per traiettoria, valutato indipendentemente dal completamento del task.
Poi c'è la curva dei costi. La leaderboard registra che superare la soglia del 50% parziale richiede un ordine di grandezza in più di token rispetto al 25%: l'efficienza scala peggio della capacità. Claude Opus 4.7 costa 3.870 dollari per una run completa, GPT-5.5 costa 2.750 dollari, circa un terzo in meno, con risultati inferiori. Chiudere il divario tra il 31% e il 100% non si risolve aggiungendo token: serve un'architettura con memoria che non decade e un loop percettivo che non sia cieco tra un'azione e la successiva.
C'è anche un'obsolescenza più veloce, quella dei leaderboard stessi. Al reading group del 3 settembre, Mengqi Yuan ha mostrato che Claude Fable 5.1, rilasciato meno di 24 ore prima, aveva già portato il punteggio parziale sopra il 60% e il completamento binario sopra il 45%: il paper era stato scritto settimane prima e già non descriveva più lo stato dell'arte.
Per chi mette un agente in produzione, la conseguenza è concreta: il benchmark su cui è stato scelto il modello non misura il lavoro che dovrà fare davvero. Il divario emerge solo dopo, a trecento passi di distanza, quando l'agente non ritrova più il numero letto al passo trenta.
Further Reading
Mengqi Yuan
xlang-ai
Zhengyang (Jason) Qi
Alexis Sobel
