GPT-6 Astra per programmare

Sul coding l'annuncio di GPT-6 Astra è netto: «il miglior modello per l'ingegneria del software fino a oggi». Le tabelle raccontano una storia più articolata, e vale la pena leggerla per intero prima di cambiare gli strumenti del team.

Dati verificati il 4 settembre 2026 sull'annuncio ufficiale OpenAI.

I numeri, per intero

Il quadro è chiaro se si separano due cose.

Sui compiti da terminale — configurazione di sistema, analisi dati, ingegneria del software eseguita da riga di comando — Astra è primo con margini reali: 2,1 punti su Fable 5.1 e 5,3 su Opus 5, oltre a un +20,6 sulla propria generazione precedente.

Sulla programmazione misurata in senso ampio il primato sparisce: su entrambe le varianti di FrontierCode è Fable 5 in testa, e sull'indice di coding di Artificial Analysis — una misura di terza parte — è primo Opus 5.

Il dato che conta più del punteggio

Su Terminal-Bench 4.0 OpenAI dichiara che il 57,9% arriva a circa il 9% di costo stimato in meno rispetto a Sol e circa il 63% in meno rispetto a Fable 5.1.

La seconda cifra è quella importante: a parità di listino con Fable 5.1 — entrambi 10 e 50 dollari per milione di token — un costo per task inferiore del 63% significa che il modello consuma molto meno per arrivare allo stesso punto. Su un team che lavora tutto il giorno, quella differenza vale più di due punti di benchmark.

Va detto che è una stima del produttore su un singolo test, non una regola generale. Ma è verificabile: bastano cinquanta problemi reali eseguiti su entrambi, contando i token effettivamente fatturati.

Cosa cambia in Codex

Insieme ad Astra, OpenAI ha aggiornato l'impalcatura Codex dichiarando un completamento dei task 1,9 volte più veloce rispetto all'esperienza con GPT-5.6 Sol sul benchmark Mind2Web.

C'è poi una novità architetturale interessante per chi lavora su sessioni lunghe. Storicamente, quando la finestra di contesto si riempie, i modelli usano la compattazione: riassumono il lavoro fatto. Ogni compattazione però può perdere dettagli su perché una correzione non ha funzionato o su come si comporta un componente.

Con Astra, Codex può tenere note attraverso finestre di contesto diverse, preservando i dettagli accumulati senza comprimerli ogni volta in un unico riassunto. Le finestre precedenti restano consultabili, quindi il modello può ritrovare requisiti o risultati di test da messaggi passati anche se non erano stati catturati nelle note.

È una funzione sperimentale, da abilitare nella configurazione di Codex, che OpenAI dichiara diventerà predefinita per Astra nelle settimane successive.

Quale fascia serve, per quale uso

La colonna di destra copre una quota consistente delle richieste quotidiane di un team. Per i suggerimenti in tempo reale conta la velocità più della capacità: un completamento che arriva dopo tre secondi non serve a nessuno, per quanto sia buono.

Un team maturo usa modelli diversi per i tre modi d'uso — completamento, discussione, agente autonomo — invece di sceglierne uno solo. Il criterio è in miglior modello AI per programmare, e il modo corretto di leggere i benchmark di coding in SWE-bench e i benchmark di coding.

Esempi pratici

Team che automatizza migrazioni di database. Sulle migrazioni interne il distacco è di 6,1 punti su Fable 5.1 e di 21,2 su Sol. È l'area più distintiva insieme al terminale.

Software house che valuta l'assistente quotidiano. Qui il verdetto è aperto: su FrontierCode e sull'indice di Artificial Analysis siamo in parità con Claude, e Opus 5 costa la metà. Vale la prova su dieci problemi reali già risolti dal team.

Progetto con sessioni di debug molto lunghe. Le note fra contesti sono pensate esattamente per questo. È la funzione da provare per prima, tenendo presente che è sperimentale.

Errori da evitare

• Leggere "miglior modello per il software" come "vince ovunque".
• Usarlo per il completamento, dove serve velocità e costa troppo.
• Ignorare l'indice di Artificial Analysis, che è di terza parte.
• Confrontare punteggi ottenuti con impalcature diverse.
• Attivare le note fra contesti in produzione senza provarle: sono sperimentali.
• Dimenticare la soglia dei 272K token nelle sessioni lunghe.

Come applicarlo in azienda

Per un team di sviluppo il percorso ha tre passaggi, e il primo è quello che quasi nessuno fa.

Separa i tre modi d'uso. Completamento mentre si scrive, assistente conversazionale, agente autonomo. Hanno requisiti opposti — il primo ha bisogno di velocità, il terzo di capacità — e trattarli come un unico problema fa spendere troppo per ottenere poco.

Prova sul tuo codice. Dieci problemi reali già risolti dal team, di cui almeno tre interventi su codice esistente e non file nuovi. Scrivere una funzione da zero è un compito che tutti i modelli moderni svolgono; modificare codice con convenzioni accumulate negli anni è il lavoro vero.

Valuta due cose separatamente. Se il codice funziona e se è codice che accetteresti in revisione. Solo la prima la misura un benchmark.

Infine, conta i tentativi: un modello che costa il doppio ma chiude al primo colpo invece che al quarto conviene, e su questa fascia è il calcolo che decide.

Cosa dicono i team che l'hanno provato

L'annuncio riporta giudizi di aziende che hanno avuto accesso anticipato. Sono testimonianze raccolte da OpenAI, quindi selezionate, ma contengono osservazioni concrete che vale la pena riportare.

Da Cognition, che integra Astra nell'impalcatura di Devin, viene segnalato che l'uso del computer, la scrittura e la comprensione della base di codice hanno migliorato i test «da subito», con video più facili da seguire e report più chiari e concisi.

Da Jane Street arriva l'osservazione forse più utile per un team: usato per il coding agentico, Astra «comunica in un modo più facile da seguire per gli sviluppatori e produce codice che richiede meno iterazioni per raggiungere la qualità di produzione».

Quest'ultimo punto tocca esattamente ciò che i benchmark non misurano. Un modello che produce codice accettabile al primo giro fa risparmiare più di uno che ottiene un punteggio più alto ma richiede tre passaggi di revisione — sia in costo API sia, soprattutto, in tempo delle persone.

Una nota metodologica su FrontierCode

Sulle due righe di FrontierCode c'è una footnote che cambia la lettura del risultato.

OpenAI dichiara che su quel benchmark Astra è stato eseguito con un messaggio di sistema simile a una sezione del suo messaggio in Codex, che chiede in sostanza: evitare di creare file di test superflui, riutilizzare le utilità esistenti, leggere le convenzioni del repository e ispezionare codice, test e documentazione vicini, con l'obiettivo di produrre codice pulito e integrabile.

OpenAI precisa che il prompt non era ottimizzato per quel test. Ma resta il fatto che il risultato è stato ottenuto con istruzioni specifiche sul comportamento atteso, e che quelle istruzioni descrivono buone pratiche di sviluppo.

È un'informazione utile in due modi. Primo: ridimensiona il confronto diretto, perché non tutti i modelli in tabella hanno ricevuto lo stesso trattamento. Secondo, e più pratico: suggerisce che istruzioni di questo tipo migliorano il risultato, il che è replicabile sul proprio ambiente indipendentemente dal modello scelto.

Il costo di un team di sviluppo

Facciamo un conto realistico. Un team di cinque persone che usa un assistente agentico tutto il giorno può generare volumi consistenti, perché il codice come contesto è pesante.

Ipotizziamo 400 richieste al giorno complessive, con 15.000 token di input (file pertinenti, storico della sessione) e 2.000 di output.

Due leve cambiano radicalmente questo conto, ed entrambe sono più efficaci di un cambio di modello.

La prima è la cache: su Astra l'input letto dalla cache costa 1 dollaro invece di 10. Su un contesto di progetto stabile riletto decine di volte al giorno, è la differenza fra 1.320 e poche centinaia di dollari.

La seconda è la selezione dei file: uno strumento che individua i tre file pertinenti costa una frazione di uno che manda l'intero repository, e produce anche risposte migliori perché il modello non deve cercare l'ago nel pagliaio.

Il rischio specifico del codice generato

Un ultimo avvertimento che vale per qualunque modello, incluso questo.

Un modello che genera codice palesemente rotto non fa danni: il test fallisce, qualcuno se ne accorge, si corregge. Un modello che genera codice che funziona sui casi previsti ma sbaglia su quelli non testati produce un problema che emergerà in produzione, magari mesi dopo.

Più il modello è capace, più questo rischio cresce, perché il codice prodotto è plausibile e supera la revisione superficiale. La contromisura non è tecnica ma di processo: chiedere sempre di spiegare la modifica e di dichiarare le assunzioni fatte. Un modello che scrive «ho assunto che questo campo sia sempre valorizzato» ti sta dando l'informazione per verificare; uno che non lo dichiara ha fatto la stessa assunzione in silenzio.

Per andare più a fondo. Se stai valutando l’adozione, parti da GPT-6 Astra: cos'è e cosa cambia. Il calcolo della spesa reale — quella che comprende ragionamento, tentativi e revisione umana — è in GPT-6 Astra: prezzi e come si paga, mentre i limiti dichiarati sono raccolti in GPT-6 Astra: tutti i benchmark ufficiali.

Conclusione

Su Terminal-Bench 4.0, migrazioni di database e compiti da terminale, GPT-6 Astra è primo con margini reali e — secondo OpenAI — a un costo per task sensibilmente inferiore rispetto a Fable 5.1.

Sulla programmazione misurata in senso ampio il quadro è di parità: su FrontierCode Fable 5 è avanti di frazioni di punto, e sull'indice di coding di Artificial Analysis è primo Opus 5, che costa la metà.

Il verdetto pratico dipende quindi da cosa somiglia di più al tuo lavoro. E per il completamento quotidiano, nessuno di questi modelli è la risposta giusta.

Se vuoi integrare l'AI nel flusso di sviluppo della tua azienda, Giallo Studio progetta soluzioni su misura e le mette in produzione.

Schema consigliato: Article + FAQPage + BreadcrumbList