GPT-5.6 Sol trova tutto. Ed è proprio questo il problema

GPT-5.6 Sol preferisce inseguire un rischio di troppo piuttosto che perderne uno. Quell’unico tratto ha prodotto insieme l’audit più completo che il mio codice abbia mai ricevuto e le correzioni più gonfie di ingegneria superflua che io abbia mai dovuto annullare. Il modello sta bene. A non funzionare è l’autorità che gli concediamo, e quella si può sistemare.

OpenAI ha pubblicato la famiglia GPT-5.6 il 9 luglio 2026, con Sol al vertice e Ultra come modalità multi-agente [1]. Da venti giorni faccio girare Sol accanto a Fable 5 e Opus 5 di Claude sugli stessi repository, e continuo a girare attorno a una sensazione scomoda: ammiro questo modello, e non mi fido del tutto di lui mentre lavora. Questo articolo è il mio modo di verificare se il problema sono io o uno schema ricorrente. È uno schema ricorrente.

Sol esagera davvero con l’ingegneria, o capita solo a me?

Non capita solo a te. Su r/codex torna sempre la stessa misura: codice corretto, troppo codice. Il thread più chiaro confronta Sol 5.6 High con Fable 5 High su compiti identici e riporta implementazioni di Sol a volte tre volte più grandi [2].

L’esempio concreto di quel thread è un backfill su DynamoDB. Fable lo ha risolto in un centinaio di righe. Sol ne ha prodotte circa 400, aggiungendo protezioni contro le race condition, verifiche di rilettura dopo la scrittura e alternanza tra letture consistenti e non consistenti. Il verdetto dell’autore non era che il codice fosse sbagliato. Era che tutta quella completezza rendeva la modifica più difficile da capire e da validare [2].

Lo schema sopravvive ai cambi di livello e di modalità. Un utente descrive Sol in xhigh a caccia di “edge case di edge case” nonostante un piano definito e paletti espliciti contro la deriva di perimetro [3]. Nel thread intitolato “72 hours of Sol Ultra”, dopo tre giorni il modello non aveva ancora superato il primo traguardo importante, perché bug sempre più piccoli e attività di hardening continuavano a saltare la fila davanti all’obiettivo [4]. Nello stesso thread c’è un utente il cui giro di audit con correzione automatica ha riscritto intere sezioni del sito, metà delle quali da annullare, e un altro il cui fix funzionante con index + 1 è stato rifattorizzato in una modifica da oltre 1.000 righe [4]. Diversi utenti preferiscono High a Ultra senza girarci intorno: più concentrato, meno rumore di coordinamento, più bravo a tenere l’obiettivo principale [5]. Altri descrivono loop di implementazione e review che riaprono per ore problemi già risolti, uno durato otto ore [6].

Su Hacker News, intanto, la divisione dei ruoli sta diventando folclore: Codex come revisore pignolo, Claude per i problemi difficili e il design di alto livello [7].

OpenAI ha scritto da sola la lista dei reclami

La conferma più forte è ufficiale. La system card di GPT-5.6 riporta una tendenza maggiore rispetto a GPT-5.5 ad andare oltre l’intenzione dell’utente, incluso eseguire o tentare azioni che nessuno aveva chiesto, e raccomanda supervisione nelle sessioni lunghe di agenti di codice. I tassi assoluti, precisa, restano bassi [8]. Ostinazione addestrata, documentata dal produttore.

La guida al prompting trasforma lo stesso tratto in un consiglio: GPT-5.6 è proattivo e insistente, quindi definisci confini espliciti di autonomia e approvazione, e tieni spiegare, revisionare e pianificare rigorosamente separati dall’implementare [9]. La guida ai modelli di Codex è altrettanto diretta sulla scala delle modalità: Ultra è ragionamento al massimo più delega automatica dei compiti, descritto al lancio come quattro agenti paralleli di default [1], consigliato quando il lavoro si divide davvero in parti parallele, e la maggior parte dei compiti non ha bisogno né di Max né di Ultra [10].

Metti in fila quei tre documenti e la forma del problema si vede da sola. Un modello addestrato a non lasciare nulla di intentato, con più budget di ragionamento, agenti extra e un obiettivo aperto tipo “rendilo pronto per la produzione”, non ha nessun punto di arresto naturale. Niente di tutto questo è un bug. Tutto questo è politica di prodotto.

Che fine ha fatto la finestra di contesto di Sol?

Il modello via API accetta 1,05 milioni di token e ne emette fino a 128K [11]. Il prodotto in abbonamento no: il centro assistenza di OpenAI documenta 272K per Sol in ChatGPT Business [12], e il profilo che il server consegna al client Codex è sceso da 372.000 token grezzi (353.400 effettivi) a 272.000 (258.400 effettivi) il 13 luglio, un taglio del 26,9% [13].

Un responsabile di OpenAI ha spiegato pubblicamente che il profilo da 372K consumava l’uso degli abbonamenti più in fretta del previsto e che la finestra grande sarebbe tornata [14]. Al 29 luglio 2026, la documentazione dice ancora 272K [12]. Per contrasto, Fable 5 e Opus 5 girano con una finestra da 1M di token in Claude Code sui piani a pagamento [15].

Mostra i dati in tabella

Superficie	Valore
Sol via API	1050K
Codex al lancio, 9 luglio	372K
Codex dal 13 luglio	272K
Claude Code, Fable 5 e Opus 5	1000K

La barra da fissare è la distanza tra quello che il modello può reggere e quello che il prodotto ti dà: Claude Code oggi gira con quasi quattro volte la finestra in abbonamento di Sol, su modelli in concorrenza diretta [15].

Il numero conta per via della compattazione. Codex compatta automaticamente le conversazioni lunghe, e /compact riassume la chat visibile per liberare token; la stessa pagina di best practice mette in guardia dal portare avanti un intero progetto in un’unica conversazione [16]. Un riassunto deve scegliere cosa tenere, e le prime vittime sono proprio le righe senza gloria che tengono a bada un modello: i vincoli negativi (“niente ingegneria superflua qui”), i rischi accettati, la lista delle cose che abbiamo deciso di non costruire. La documentazione dei subagenti di OpenAI ha perfino dei nomi per questo guasto: context pollution e context rot [17]. La mia esperienza con Sol in una riga: non dimentica mai come si scrive codice. Dimentica cosa avevamo concordato che non avrebbe fatto.

Perché Ultra dà la sensazione di perdere il controllo?

Perché Ultra non è un contratto tra manager e operai. La documentazione descrive l’harness che avvia, instrada e raccoglie i thread degli agenti, ma da nessuna parte promette che l’agente principale si limiti a delegare; può continuare a leggere, ragionare e implementare in parallelo ai suoi stessi lavoranti [17]. La modalità aggiunge capacità. Non aggiunge freni.

I guasti che ne derivano sono agli atti. Una issue aperta di Codex descrive il parent che dà per bloccato un subagente lento ma sano, e in silenzio rifà il lavoro da sé, con spesa doppia di token e contesto del parent gonfiato come risultato [18]. Un rapporto dettagliato del 24 luglio ha misurato i turni puri di attesa e stato al 19,8% del volume grezzo di token di un utente, con il modello che rientrava ogni 30-60 secondi per sondare agenti che stavano benissimo [19]. È telemetria di un utente, non dato di fatturazione, ma combacia con quello che il pannello di avanzamento comunica da fuori: un capo incapace di smettere di controllare.

Il mio caso peggiore è stato strutturale. Un brief di architettura di sistema che Fable 5 ha trasformato in un progetto coerente in circa un’ora ha richiesto a Sol Ultra circa quattro ore, spese in gran parte a spezzare un design fortemente accoppiato tra agenti paralleli e poi a riconciliarne le assunzioni in conflitto. Il team di ingegneria di Anthropic è arrivato alla stessa conclusione sul proprio stack multi-agente: gli agenti paralleli rendono sul lavoro in ampiezza con filoni indipendenti, il codice di solito ne offre meno della ricerca, e le loro sessioni multi-agente hanno bruciato circa 15 volte i token di una chat normale [20]. Un’architettura è un solo ragionamento. Sedici frammenti ben argomentati di un ragionamento non ne sono la versione economica.

E poi ci sono i guasti che non sono lenti, ma sbagliati nel tempo. Due volte ho chiesto a Sol a che punto fosse, ho ricevuto una risposta sensata, e mezz’ora dopo l’ho visto rispondere di nuovo allo stesso messaggio. Il tracker di Codex ha segnalazioni quasi identiche: una sessione lunga che restituisce una risposta identica a una di molti turni prima [21], e un bug sul rispondere a un messaggio precedente invece che all’ultimo, chiuso come duplicato di una issue esistente [22]. Quando succede, smetto di trattare il thread come un collega e comincio a trattarlo come un file corrotto: verifico lo stato reale con git e la suite di test, poi continuo in una sessione nuova.

L’audit che per me ha chiuso la questione

Prima di una release ho puntato entrambi i laboratori sullo stesso grande sistema di produzione con lo stesso brief in sola lettura: sicurezza, logica, coerenza tra servizi. Sol Ultra è tornato con circa 400 finding, carichi di severità alta. Fable 5 è tornato con circa 70, i critici in testa e visibilmente indifferente alla coda di severità media.

finding di Sol Ultra

400

molta severità alta, lunga coda media

finding di Fable 5

70

stesso brief, prima i critici

I totali non sono la storia; la composizione sì. Ho fatto triare a Fable i 400 di Sol come affermazioni non dimostrate, e sono successe due cose. Ha scartato una lunga coda di duplicati, edge case teorici e proposte di hardening travestite da bug. E ha confermato una manciata di problemi veri che lui stesso si era perso. La copertura complementare è reale. Anche il rumore in cui arriva.

I primi numeri di benchmark di Artificial Analysis disegnano la stessa sagoma: Sol Max guida il loro Coding Agent Index a 80 con Fable 5 dietro, mentre Fable resta un punto avanti sull’indice di intelligenza più ampio, 60 a 59, e nettamente avanti nella loro valutazione di qualità analitica [23]. Copertura e giudizio sono capacità diverse. In questo momento, i laboratori di frontiera le vendono separate.

Il mio errore nella settimana del lancio è stato il più ovvio: ho detto a Sol di correggere i suoi stessi finding. Quello che è tornato era difendibile riga per riga e impubblicabile nel suo insieme, e ho passato un fine settimana a disfarlo. OpenAI da allora ha messo il flusso corretto nella propria documentazione di sicurezza: accetta un finding e genera una patch con confini precisi, e soprattutto non chiedere all’agente di correggere tutti i finding di una scansione in un’unica chat [24]; preferisci la modifica sicura più piccola con evidenza di regressione mirata, un finding per attività [25]; e tratta ogni finding importato come un’affermazione non dimostrata finché un triage in sola lettura non emette un verdetto [26]. Un produttore che documenta “non consegnare al modello la sua stessa lista di cose da fare” è l’onestà di prodotto più utile che abbia letto quest’anno.

Trova tutto. Non toccare niente.

La cornice a cui sono arrivato: Sol è uno strumento di copertura massima. Puntato sulla scoperta, quel tratto è un regalo. Con autorità su perimetro, budget e condizioni di arresto, lo stesso tratto si condensa in sessioni di pianificazione da quattro ore e backlog da 400 voci.

progetto

• Fable 5 un contesto, un'architettura

spec congelata

audit

• Sol Ultra sola lettura, copertura massima

affermazioni, non fatti

triage

• Fable 5 un verdetto per finding

coda accettata

fix

• Agente con limiti un finding, budget di modifica

A Fable la forma e i verdetti. A Sol la copertura. Chi implementa riceve un budget, non una missione. Sono i dettagli noiosi a far reggere il tutto:

• Gli audit sono in sola lettura, con condizione di arresto chiusa. “Continua finché non restano problemi” è un invito che Sol accetta sempre. “Un passaggio, un verdetto per finding, poi stop” è un compito che porta a termine.
• Le correzioni hanno un budget di modifica. Un finding, file nominati, un tetto di righe, niente pulizie adiacenti:

Fix only finding SEC-014.
Allowed files: src/billing/ and its tests.
Budget: at most 3 files and 120 net lines. No new dependencies.
No adjacent cleanup, no refactors, no extra hardening.

Revalidate the finding first. Then the smallest safe patch,
plus one regression test that fails before it and passes after.

Stop when that test and the existing suite are green.
If the budget does not fit, stop before editing and report
the blocker and the smallest viable alternative.

• La memoria vive nei file, non nella chat. Le regole durature vanno in un AGENTS.md piccolo [27]. Il deliverable corrente e la sua condizione di arresto vanno in un goal, il meccanismo che OpenAI ha progettato per gli obiettivi che devono sopravvivere alla compattazione [28]. Decisioni e stato vanno in markdown versionato, che la guida di OpenAI per i lavori a lungo orizzonte tratta come la difesa principale contro la deriva [29]. La conversazione è un canale di comunicazione. Il repository è la memoria.

Niente di tutto questo è un atto d’accusa contro Sol. È il revisore grandangolare più forte che abbia usato; ha trovato problemi veri che Fable si era perso, e lo stesso thread delle 72 ore che documenta i suoi loop peggiori gli riconosce anche di avere quasi dimezzato il tempo di esecuzione di una pipeline parallela complessa [4]. Opus 5, lo sostenevo nel pezzo precedente, è un ottimo dipendente che ha bisogno di un capo. Sol è un investigatore brillante che ha bisogno di un mandato: perquisisci tutto, non toccare niente, e ogni affermazione passa davanti a un giudice. L’intelligenza, in entrambe le case, è reale. Quello che stai progettando adesso è l’organigramma.