GPT-5.6 Sol complica troppo il codice. Io continuo a usarlo

GPT-5.6 Sol complica spesso il mio codice, ma resta il miglior modello che abbia usato per individuare rischi. In un audit di release ha segnalato circa 400 possibili problemi, contro i 70 di Fable 5. La maggior parte era rumore, ma alcuni erano reali. Ora lo uso in sola lettura e affido a un altro modello la scelta delle correzioni.

GPT-5.6 Sol complica troppo il codice? Il comportamento si ripete

Sì. Nel mio lavoro, GPT-5.6 Sol ha complicato il codice oltre il necessario più volte, e diverse segnalazioni su r/codex descrivono lo stesso comportamento. Nel confronto più chiaro, Sol 5.6 High e Fable 5 High hanno ricevuto lo stesso compito, ma alcune implementazioni di Sol erano tre volte più grandi [2].

Un esempio riguardava un backfill di DynamoDB che Fable ha completato in circa 100 righe. La versione di Sol ne ha richieste circa 400 perché ha aggiunto protezioni contro le race condition, una verifica tramite rilettura dopo la scrittura e una logica per alternare letture consistenti e non consistenti. Nessuna aggiunta era sbagliata, ma il loro insieme rendeva una modifica semplice più difficile da capire e da validare [2].

Cambiare il livello di ragionamento o la modalità non elimina questo comportamento. Un utente aveva fornito a Sol in xhigh un piano chiaro e limiti espliciti al perimetro, ma il modello ha continuato a inseguire «casi limite di casi limite» [3]. Un altro utente è arrivato al terzo giorno di una sessione Sol Ultra senza superare il primo traguardo importante, perché i piccoli bug e le misure di sicurezza aggiuntive continuavano a prendere il posto dell’obiettivo principale [4].

Lo stesso thread mostra quanto rapidamente questa tenacia possa ingrandire una modifica. Un audit con correzioni automatiche ha riscritto intere sezioni di un sito, costringendo l’utente ad annullare metà del risultato; un altro compito ha trasformato una correzione funzionante di index + 1 in oltre 1.000 righe modificate [4]. Per questo, diversi utenti preferiscono High a Ultra: resta più vicino all’obiettivo e richiede meno coordinamento [5]. Altri descrivono cicli di revisione che riaprono problemi risolti, incluso uno durato otto ore [6].

Una divisione del lavoro simile emerge nella discussione su GPT-5.6 su Hacker News, dove alcuni utenti descrivono Codex come il revisore rigoroso e Claude come la scelta migliore per i problemi difficili e il design di alto livello [7]. Le esperienze della comunità mostrano che il comportamento può ripetersi. La documentazione di OpenAI aiuta a capire perché.

OpenAI afferma che Sol può andare oltre le intenzioni dell’utente

La system card di GPT-5.6 afferma che Sol va oltre le intenzioni dell’utente più spesso di GPT-5.5, anche con azioni non richieste. OpenAI definisce comunque bassi i tassi assoluti, ma raccomanda la supervisione durante le lunghe sessioni con gli agenti di programmazione [8].

La guida al prompting trasforma l’avvertimento in una regola di lavoro: definisci limiti chiari di autonomia e approvazione, poi separa spiegazione, revisione e pianificazione dall’implementazione [9]. La guida ai modelli Codex aggiunge che Ultra unisce il massimo livello di ragionamento alla delega automatica. Al lancio, OpenAI ha descritto quattro agenti paralleli come configurazione predefinita [1], ma consiglia Ultra solo per lavori con parti davvero indipendenti e afferma che la maggior parte dei compiti non richiede né Max né Ultra [10].

Questi documenti rendono la mia esperienza meno sorprendente. Sol è progettato per insistere, mentre i livelli di ragionamento superiori e gli agenti aggiuntivi gli lasciano più spazio per farlo. In pratica, una richiesta come «rendilo pronto per la produzione» indica una direzione, ma non un punto di arresto. Quel limite devo definirlo io. Quando OpenAI ha rilasciato GPT-6 Astra, ho verificato se il modello più recente rispetta l’ambito meglio di Sol in Codex.

Che cosa è successo alla finestra di contesto di Sol? Codex è sceso a 272K

GPT-5.6 Sol accetta ancora 1,05 milioni di token in input via API e può produrre fino a 128K token in output [11]. Il prodotto in abbonamento funziona diversamente: il centro assistenza di OpenAI indica una finestra da 272K per Sol in ChatGPT Business [12]. Le specifiche dell’API non descrivono il contesto disponibile nell’abbonamento.

Il limite dell’abbonamento è cambiato quattro giorni dopo il lancio. Una segnalazione su GitHub nel repository openai/codex registra il calo del profilo server da 372.000 token grezzi (353.400 effettivi) a 272.000 (258.400 effettivi) il 13 luglio, una riduzione del 26,9% [13]. In seguito, un dipendente di OpenAI ha scritto su X che il profilo più grande consumava troppo velocemente l’uso dell’abbonamento e sarebbe tornato [14]. Al 29 luglio 2026, la documentazione di OpenAI indicava ancora 272K [12]. I limiti dell’abbonamento sono cambiati di nuovo più tardi, come racconto in perché Codex Plus può fermare il lavoro anche se resta quota settimanale.

Il centro assistenza di Claude documenta invece una finestra da 1M di token per Fable 5 e Opus 5 in Claude Code con i piani a pagamento [15]. La differenza conta perché, durante una sessione lunga, un contesto di lavoro più piccolo aumenta la probabilità che le decisioni precedenti sul perimetro vengano compattate.

Mostra i dati in tabella

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

Il grafico rende concreta la differenza fra i prodotti: Claude Code offre attualmente ai modelli concorrenti quasi quattro volte il contesto che Sol riceve con un abbonamento [15].

Quando il contesto si riempie, Codex comprime le parti più vecchie della conversazione. La compattazione automatica e il comando /compact riassumono la chat visibile; la pagina delle buone pratiche di OpenAI sconsiglia anche di conservare un intero progetto in una sola conversazione [16].

È durante la compattazione che la finestra più piccola diventa un problema nel mio flusso di lavoro. Nelle mie sessioni con Sol si perdono spesso proprio i vincoli che controllano il perimetro: i rischi accettati, le funzionalità che abbiamo deciso di non creare o un semplice «non complicare troppo questa modifica». La documentazione di OpenAI sui subagenti descrive problemi collegati con i termini context pollution e context rot [17]. Non è il codice a diventare fragile. È l’accordo su ciò che Sol deve lasciare intatto.

Perché Sol Ultra è difficile da controllare? Il coordinamento diventa lavoro

Ultra aggiunge agenti senza limitare quello principale alla delega. La documentazione di OpenAI spiega che il software può creare, indirizzare e raccogliere i thread degli agenti, ma l’agente principale rimane libero di leggere, ragionare e implementare durante il loro lavoro [17]. Il risultato è una maggiore capacità senza un limite equivalente sulla divisione dei compiti.

Due segnalazioni nel repository openai/codex su GitHub mostrano quanto può costare questo approccio. Nella prima, l’agente principale ha scambiato per bloccato un subagente lento ma operativo e ne ha ripetuto il lavoro senza avvisare l’utente. Ha così consumato altri token e riempito il proprio contesto di materiale duplicato [18].

Nella seconda segnalazione, i turni di attesa e di stato rappresentavano il 19,8% del volume grezzo di token di un utente, perché il modello si riattivava ogni 30 o 60 secondi per controllare agenti che stavano ancora lavorando normalmente [19]. Il dato proviene dalla telemetria di un utente e non dalla fatturazione, ma il punto pratico è chiaro: coordinare gli agenti può diventare un compito importante a sé stante.

Il mio caso più frustrante ha riguardato l’architettura di un sistema. Fable 5 ha prodotto un progetto coerente in circa un’ora, mentre Sol Ultra ne ha impiegate quasi quattro perché aveva diviso un problema strettamente collegato fra agenti paralleli e poi aveva dovuto risolvere le loro ipotesi contrastanti.

Il team di ingegneria di Anthropic ha riscontrato lo stesso limite nel proprio sistema multi-agente: il lavoro parallelo conviene quando un compito ampio contiene parti indipendenti, mentre la programmazione in genere ne offre meno della ricerca. Anthropic riferisce inoltre che le sessioni multi-agente hanno utilizzato circa 15 volte i token di una normale chat [20]. Nell’architettura, troppo parallelismo può creare più lavoro di coordinamento di quanto ne elimini. Più tardi OpenAI ha raccontato un problema di coordinamento ancora più strano, quando i suoi agenti interni hanno trasformato lo storage condiviso di Artifactory in una bacheca.

Ultra può anche rispondere da un punto precedente della conversazione. Due volte ho chiesto a Sol un aggiornamento sullo stato, ho ricevuto una risposta utile e, mezz’ora dopo, l’ho visto rispondere di nuovo allo stesso messaggio. Su GitHub ci sono segnalazioni Codex molto simili: una sessione ha restituito una risposta copiata da molti turni prima [21], mentre un’altra descrive Codex che risponde a un messaggio precedente invece che all’ultimo [22].

Dopo un episodio del genere, non mi fido più della conversazione come registro dello stato attuale. Controllo il repository con git e la suite di test, poi sposto il compito in una nuova sessione.

Il mio audit di release: Sol ha trovato di più, Fable ha giudicato meglio

Sol Ultra ha segnalato circa 400 possibili problemi nel mio audit di release, contro i circa 70 di Fable 5. La maggior parte delle segnalazioni aggiuntive di Sol non ha superato il triage, ma alcune hanno rivelato problemi reali che Fable non aveva rilevato. Sol è stato nettamente migliore nella ricerca ampia; Fable ha giudicato meglio che cosa contasse davvero.

Prima della release, ho assegnato ai due modelli lo stesso grande sistema di produzione e le stesse istruzioni in sola lettura su sicurezza, logica e coerenza fra i servizi. La lista di Sol conteneva molte segnalazioni ad alta gravità, mentre Fable metteva per primi i problemi critici e mostrava poco interesse per i numerosi potenziali problemi di media gravità.

segnalazioni di Sol Ultra

400

molti risultati con gravità alta e media

segnalazioni di Fable 5

70

stesse istruzioni, prima i problemi critici

La figura confronta il volume dei risultati, non i bug confermati. Ho chiesto a Fable di trattare tutte le 400 segnalazioni di Sol come affermazioni non dimostrate e di esaminarle una per una. Ha respinto molti duplicati, casi limite teorici e misure di sicurezza aggiuntive che Sol aveva presentato come bug, ma ha anche confermato diversi problemi reali sfuggiti al proprio audit. La copertura aggiuntiva di Sol è stata utile, ma solo dopo che una revisione separata ha eliminato il rumore.

Artificial Analysis mostra una divisione simile in due benchmark. Sol Max guida il Coding Agent Index con un punteggio di 80, davanti a Fable 5; nell’indice di intelligenza più ampio, invece, Fable è avanti 60 a 59 e ha un vantaggio più chiaro nella valutazione della qualità analitica [23]. Queste valutazioni non riproducono il mio audit, ma sostengono un punto più limitato: trovare candidati e giudicarli sono capacità diverse.

Durante la settimana del lancio ho ignorato questa distinzione e ho chiesto a Sol di correggere ogni punto della propria lista. Molte modifiche sembravano ragionevoli prese da sole, ma il risultato completo non era abbastanza sicuro da pubblicare. Alla fine, ho passato un fine settimana a rimuovere il lavoro aggiuntivo.

La documentazione di sicurezza di OpenAI ora consiglia quasi esattamente il metodo che avrei dovuto usare. Indica di accettare una segnalazione e produrre una patch limitata, invece di far correggere tutti i risultati di una scansione in un’unica chat [24]. Consiglia inoltre la modifica sicura più piccola, accompagnata da una prova di regressione mirata, con un compito distinto per ogni segnalazione [25]. Soprattutto, le segnalazioni importate restano non dimostrate finché un triage in sola lettura non emette un verdetto per ciascuna [26]. Questa separazione trasforma la lunga lista di Sol in materiale utile per la revisione, invece che in una lista di cose da fare senza controllo.

Come uso GPT-5.6 Sol: audit ampio, patch limitate

Affido a Sol la ricerca ad ampio raggio, ma non il permesso di modificare il codice. Un altro modello decide quali segnalazioni sono reali; poi un agente con limiti rigidi corregge un solo problema approvato alla volta. In questo modo sfrutto il principale punto di forza di Sol senza lasciargli decidere il perimetro, il budget o quando il lavoro è concluso.

architettura

• Fable 5 crea un progetto coerente

istruzioni fisse

audit

• Sol Ultra ricerca ampia con accesso in sola lettura

affermazioni, non fatti

triage

• Fable 5 un verdetto per segnalazione

coda approvata

correzione

• Agente con limiti rigidi una segnalazione, budget di modifica

La divisione è semplice: Fable gestisce l’architettura e le decisioni finali, Sol cerca i possibili problemi e l’agente che implementa riceve un compito limitato invece di una missione generale. Tre regole pratiche mantengono intatti questi ruoli:

• Mantieni gli audit in sola lettura e indica esattamente quando finiscono. «Continua finché non restano problemi» autorizza Sol a cercare senza limiti; «un passaggio, un verdetto per segnalazione, poi fermati» definisce invece un compito che può completare.
• Dai a ogni correzione un budget di modifica. Indica la segnalazione e i file consentiti, imposta un limite di righe e vieta qualsiasi pulizia non collegata:

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.

• Conserva le decisioni durature nel repository. Le regole stabili vanno in un breve file AGENTS.md [27]. Il risultato attuale e la sua condizione di arresto vanno in un goal, che OpenAI ha progettato per conservare gli obiettivi dopo la compattazione [28]. Le decisioni e lo stato attuale vanno in Markdown sotto controllo di versione, come consiglia la guida di OpenAI per i compiti lunghi [29]. La chat resta utile per discutere, ma non deve essere l’unico luogo che ricorda il contratto.

Questo metodo non riduce Sol a una semplice avvertenza. Sol rimane il miglior revisore che abbia usato per audit estesi e ha trovato problemi reali sfuggiti a Fable. Perfino il thread «72 hours», che descrive cicli problematici, riconosce a Sol il merito di aver quasi dimezzato il tempo di esecuzione di una pipeline parallela complessa [4]. L’obiettivo è usare questa capacità dove serve.

Nel mio articolo precedente su Opus 5, sostenevo che anche un modello capace ha bisogno di una gestione chiara. La mia regola per Sol è più rigida: cerca tutto, non cambiare nulla e invia ogni affermazione a un altro giudice. Così ottengo la copertura aggiuntiva senza dare a Sol il permesso di allargare il compito.