GPT-5.6 Sol chiude un altro problema aperto: l'architettura degli agenti conta più del modello
Due thread su Hacker News raccontano la stessa storia da due angoli. Il primo, da 204 punti, documenta come GPT-5.6 Sol abbia chiuso un problema aperto da circa 30 anni nell’ottimizzazione convessa, usando un prompt e sottoagenti in parallelo. Sei giorni prima, il 12 luglio, avevamo raccontato la dimostrazione della Cycle Double Cover Conjecture: stesso modello, stesso pattern.
Il secondo thread, da 121 punti, è il test di Charles Azam. Ha messo Fable 5 e GPT-5.6 Sol sullo stesso problema NP-hard, la progettazione di una rete in fibra ottica con uno spazio di ricerca stimato intorno a 10^1223 soluzioni, con 30 minuti di budget ciascuno. Il risultato è istruttivo per chi orchesttra agenti.
Perché ti riguarda. Fable 5 ha battuto Sol in configurazione standard (media 32.386 contro 34.261) con una varianza molto più stretta: 319 punti di escursione contro 1.958. Il modello più forte su carta ha perso. Azam mostra anche che il comando /goal, presente in Claude Code e Codex, ristruttura il ciclo di controllo invece di intensificarlo. In Claude Code delega a un modello valutatore separato che legge la conversazione e dice sì o no. In Codex diventa stato persistente in SQLite, con strumenti dedicati. Due architetture diverse sotto lo stesso comando.
L’orchestrazione conta più del modello. Se stai delegando compiti difficili a un agente, è nel ciclo di controllo che si vince o si perde.
Nel dettaglio
Il thread Reddit non dà il testo completo della dimostrazione, ma il titolo e la discussione su Hacker News (204 punti, 106 commenti) indicano che GPT-5.6 Sol ha prodotto una prova chiusa per un problema di ottimizzazione convessa rimasto aperto circa 30 anni. La struttura è la stessa del risultato del 12 luglio sulla Cycle Double Cover Conjecture: il modello orchestra sottoagenti in parallelo, ciascuno con un frammento del problema, e combina i risultati in una dimostrazione verificata da un matematico.
Il test di Azam scende nel pratico. Il problema KIRO è reale: progettare una rete in fibra ottica per Grenoble, Nizza e Parigi, dove ogni torre appare una sola volta, i loop devono restare sotto 30 terminali e l’obiettivo è minimizzare la lunghezza del cavo. Azam lo aveva risolto in C++ nel 2018, quindi ha un baseline umano. Lo spazio di ricerca, anche in una versione semplificata (19 loop da 28 terminali, senza rami), è dell’ordine di 10^1223.
I numeri dicono due cose. Primo, Fable 5 è stato più consistente: in tre run senza /goal, i risultati stanno in un range di 319 punti (da 32.197 a 32.516). Sol nello stesso esercizio spannia 1.958 punti (da 33.581 a 35.539). Secondo, /goal ha vinto 4 run su 6 ma ha peggiorato la media per entrambi i modelli. A volte trova un bacino migliore, a volte dà tempo a un’idea sbagliata di maturare.
Il dettaglio più utile è sotto il cofano. /goal in Claude Code è uno Stop hook a livello sessione: dopo ogni turno del modello principale, un modello piccolo (Haiku) legge la conversazione e decide se l’obiettivo è raggiunto. Non può usare strumenti o ispezionare i file: giudica solo dal transcript. In Codex (versione 0.144.4, open source), /goal è stato persistente: il TUI salva l’obiettivo in SQLite con stato e budget, e il modello riceve strumenti dedicati (create_goal, get_goal, update_goal). Quando il thread diventa idle con un goal attivo, Codex inietta un turno di continuazione con un audit di completamento. Due filosofie: Claude delega a un altro modello, Codex mette lo stato nel sistema.
I limiti sono dichiarati. Azam ha testato un solo problema, con sei run per i due modelli top e 30 minuti di budget arbitrari. L’implementazione di Claude Code è closed source, quindi si basa su ciò che Anthropic documenta. Per chi costruisce agenti, la conseguenza pratica è chiara: prima di cercare il modello più forte, valuta come il tuo ciclo di controllo gestisce l’obiettivo. Il corso su come orchestrare più agenti e il playbook per delegare un compito multi-passo costruiscono esattamente questa competenza.