ARC-AGI-3 misurava l'harness, non solo il modello

Chi porta agenti in produzione scopre presto che ogni punteggio di benchmark misura anche le proprie impostazioni, quasi mai scelte in modo consapevole. Il 29 luglio 2026 OpenAI ha pubblicato che GPT-5.6 Sol è passato dal 13,3 % al 38,3 % sull'insieme pubblico di prove di ARC-AGI-3, senza alcuna modifica ai pesi del modello (OpenAI). Sono bastate due impostazioni dell'API. Qui si vede che cosa sia davvero cambiato, perché il confronto ripreso ovunque non regga e che cosa convenga verificare nel proprio stack.

ARC-AGI-3 è un benchmark in cui gli agenti devono capire da soli il funzionamento di giochi bidimensionali mai visti, senza ricevere alcuna istruzione ([ARC Prize](https://arcprize.org/competitions/2026/arc-agi-3)). La misura adottata, la Relative Human Action Efficiency, rapporta la prestazione a un riferimento umano invece che a una semplice percentuale di soluzioni.

Eseguiamo gli stessi carichi di lavoro agentici su modelli di fornitori diversi, e ognuna di queste esecuzioni passa attraverso un wrapper scritto da noi: nel nostro stack è quindi quel wrapper, e non la scheda del modello, a decidere che cosa sopravviva da un passaggio al successivo. È qui che la vicenda diventa interessante. Non si tratta di una disputa di classifica, ma di un problema di misurazione che con ogni probabilità esiste anche nel codice degli agenti di chi legge.

Che cosa ha modificato davvero OpenAI

Gli elementi modificati sono due soltanto: il ragionamento interno del modello viene conservato tra un'azione e l'altra invece di essere scartato, e al troncamento progressivo dell'harness subentra la compaction, che riassume il contesto vecchio anziché cancellarlo.

L'harness ufficiale di ARC-AGI-3 scartava il ragionamento interno dopo ogni azione di gioco. Al modello restava visibile l'elenco delle mosse compiute, ma non i piani né le ipotesi che le avevano generate, così ogni turno ricominciava con una ricostruzione da zero della logica del gioco. A questo si aggiungeva un secondo vincolo: superati i 175.000 caratteri di cronologia, i messaggi più vecchi venivano semplicemente eliminati (OpenAI). Nessun ragionamento persistente e un passato che si dissolve: per un benchmark il cui scopo è imparare un ambiente sconosciuto nel corso del tempo, è difficile immaginare una configurazione più sfavorevole.

Entrambe le sostituzioni sono normali impostazioni di prodotto, alla portata di qualunque sviluppatore: gli elementi di ragionamento mantenuti da un turno all'altro (documentazione OpenAI) e la compaction (documentazione OpenAI), entrambe attraverso l'API Responses invece della più datata interfaccia Chat Completions (guida alla migrazione). L'effetto dichiarato: circa il triplo del punteggio con all'incirca sei volte meno token prodotti. Che il risultato migliori e insieme costi meno è proprio ciò che lo rende credibile anziché di comodo. Un'impostazione che gonfiasse soltanto il punteggio sarebbe sospetta; una che riduce anche il conto dei token sta facendo un lavoro reale.

Perché il confronto più diffuso non regge

È qui che la copertura giornalistica ha sbandato, e l'errore è abbastanza sottile da meritare un enunciato preciso.

Il 38,3 % proviene dall'insieme pubblico di prove sotto l'harness di OpenAI. Il 30,2 % attribuito a Claude Opus 5 è un risultato verificato da ARC secondo il protocollo standardizzato di ARC Prize. Insiemi di prove diversi e harness diversi: da questi due numeri non nasce alcuna classifica.

Il risultato è stato riportato come « 38,3 per cento, battendo il 30,2 per cento di Opus 5 » (The Decoder) e come impostazioni capaci di portare Sol davanti a Opus 5 (AI Weekly). Nessuna delle due letture trova conferma. Nella tabella di ARC Prize, l'unica classifica con harness controllato, Opus 5 si colloca intorno al 30,2 % e Sol intorno al 7,8 % (classifica, analisi). In quella tabella il 29 luglio 2026 non si è mossa alcuna riga.

Due precisazioni completano il quadro. L'incremento realmente confrontabile va dal 13,3 % al 38,3 %, in entrambi i casi sull'insieme pubblico: è il fattore tre circa di cui parla OpenAI. Il 7,8 % appartiene a una misurazione diversa, semi-privata, e sommare mentalmente i due riferimenti produce un salto assai più vistoso e del tutto immaginario (Remio). Vi si aggiunge un dettaglio rivelatore: nella pubblicazione Opus 5 non compare mai. Il duello diretto è nato da un dipendente su X e poi dai titoli, non dal testo (analisi).

Manca poi quasi ovunque una cifra: anche il 38,3 % resta nettamente al di sotto del riferimento umano di circa il 48 % che OpenAI stima dai registri delle partite. La distanza colmata da quelle due impostazioni è reale. Quella che rimane è più ampia.

Le ragioni di un harness volutamente essenziale

La conclusione comoda sarebbe che l'harness di ARC fosse difettoso. Non lo era, e l'argomento contrario merita di essere esposto per intero.

ARC-AGI-3 adotta di proposito un harness essenziale, privo di tools e di funzioni legate a un singolo fornitore, nella convinzione che una struttura semplice renda visibili i limiti dei modelli e mantenga equi i confronti. I fornitori commerciali, al contrario, calibrano l'harness modello per modello; un benchmark che facesse lo stesso diventerebbe una gara fra squadre di ingegneri anziché fra modelli. Il codice è pubblico: chiunque può leggere che cosa faccia davvero (ARC-AGI-3-Agents) e provare di persona le stesse partite pubbliche (prove, interfaccia di gioco).

François Chollet traccia il confine dove lo tracceremmo anche noi. Sono esclusi gli harness « costruiti su misura per risolvere il benchmark o che contengono conoscenza del suo formato »; sono ammesse le impostazioni generali dell'API « che non sono state sviluppate per ARC-AGI-3 e che risultano disponibili a tutti gli utenti dell'API ». Chollet richiama « un lungo scambio con OpenAI su come testare al meglio i loro modelli, in particolare riguardo alla compaction » e riconosce che impostazioni differenti da fornitore a fornitore creano « un possibile problema di parità » — a suo giudizio accettabile « purché impostazioni e costi siano riportati con chiarezza » (The Decoder). Non è un laboratorio che difende il proprio territorio, ma il gestore di un benchmark che ammette una lacuna metodologica e ne descrive il rimedio.

Le due tesi reggono dunque insieme. La neutralità di ARC è un obiettivo di progettazione difendibile, eppure impostazioni predefinite neutre smettono di esserlo negli effetti quando i modelli di un fornitore sono addestrati a portarsi dietro il ragionamento e l'impostazione predefinita lo elimina in silenzio. Un harness essenziale non misura i modelli nel vuoto: li misura sotto una precisa regola di memoria, e quella regola è a sua volta una scelta.

Che cosa verificare nel proprio stack

L'aspetto scomodo è che quasi nessuno ha scelto consapevolmente la propria regola di memoria. È arrivata insieme alle impostazioni predefinite di un framework.

Tre domande meritano una risposta. La prima: il loop dell'agente trasporta il ragionamento da una chiamata di tool alla successiva, oppure ogni passaggio ricostruisce il piano da capo? La seconda: quando il contesto si riempie, si tronca o si compatta? Eliminare i turni più vecchi è la soluzione più rapida da scrivere e per questo quella che non viene mai riaperta. La terza: si lavora sull'interfaccia che il fornitore stesso usa in produzione, o su un vecchio endpoint Completions adottato una volta e mai migrato?

Nulla di tutto ciò è esotico. È la stessa lezione a cui arriviamo da direzioni diverse: la produttività di un sistema di agenti nasce dal macchinario che lo circonda, non dalla scelta di un modello migliore. Per questo è la capacità di revisione, e non il numero di agenti, a limitare il lavoro parallelo, per questo agli agenti serve una fabbrica e non un prompt migliore e per questo un harness minimo a volte batte quello massimo. Per la stessa ragione leggiamo il costo di verifica nascosto in un risultato di capacità anziché il titolo. Un punteggio di benchmark è una proprietà dell'intero sistema, e il modello ne è soltanto un componente.

La conclusione pratica non è che ARC-AGI-3 sbagli, né che un laboratorio abbia vinto. È che un numero prodotto da altri, dentro un harness mai ispezionato, non costituisce una prova su un modello. Prima che un risultato di benchmark modifichi una decisione nello stack, conviene sapere che cosa abbia fatto l'esecutore della memoria del modello. Per chi desidera far verificare seriamente questo livello, è esattamente il lavoro che svolgiamo.

Domande frequenti

GPT-5.6 Sol ha davvero battuto Claude Opus 5 su ARC-AGI-3? No. Nella tabella ufficiale di ARC Prize Opus 5 resta avanti, con circa il 30,2 % contro circa il 7,8 % (classifica). Il 38,3 % proviene da un altro insieme di prove sotto un altro harness e non è confrontabile.

Che cosa sono il ragionamento conservato e la compaction? Il ragionamento conservato trasporta gli elementi di ragionamento interno da un turno all'altro invece di scartarli dopo ogni azione. La compaction riassume il contesto più vecchio quando la finestra si riempie, anziché cancellare i messaggi meno recenti (documentazione OpenAI).

Ricorrere a queste impostazioni costituisce un vantaggio indebito? Il confine indicato da Chollet è questo: gli harness ritagliati sul benchmark sono esclusi, mentre le impostazioni generali dell'API accessibili a tutti sono ammesse, a condizione che impostazioni e costi vengano riportati con chiarezza (The Decoder).

Il risultato è stato verificato in modo indipendente? Non ancora. Il passaggio dal 13,3 % al 38,3 % si basa su dichiarazioni della stessa OpenAI e su dati di test pubblici (OpenAI). Non risulta pubblicata alcuna ripetizione indipendente sull'insieme semi-privato con impostazioni documentate e identiche.

ARC-AGI-3 misurava l'harness, non solo il modello