GPT-6.1 Sol su COBOL: 86,6% contro 5,4%, e solo uno dei due test può essere rieseguito

Il 19 ottobre 2026, O​penAI ha pubblicato due valutazioni di coding per lingue a basse risorse, e il numero da copertina appartiene a GPT-6.1 Sol: l'86,6% delle attività di migrazione COBOL è stato superato con uno sforzo di ragionamento basso, contro il 5,4% di GPT-5.6 Sol con la stessa impostazione, che sale al 97,9% quando lo sforzo aumenta. La seconda valutazione, MultiLangBench, racconta la storia di un altro modello — GPT-6 Astra ha totalizzato in media l'87,4% su venti lingue con lo sforzo massimo — ma è la metà più utile del rilascio, perché O​penAI ha messo il suo harness su GitHub con licenza Apache-2.0 e puoi eseguirlo tu stesso questo pomeriggio. La valutazione sulla migrazione COBOL, quella che porta l'86,6%, è una questione diversa: i suoi test sono nascosti, il criterio di superamento è una parità di output byte per byte rispetto a casi che nessuno al di fuori di O​penAI ha visto, e nessuna terza parte l'ha riprodotta. Questa asimmetria è tutta la storia, e vale la pena affermarlo chiaramente prima che uno dei due numeri venga citato in un business case di migrazione. I fallimenti documentati dell'IA e gli incidenti degli agenti dietro rilasci come questo sono raccolti in l'OrcaRouter AI Incident Archive dove ogni voce riporta le proprie fonti, la gravità, il grado di confidenza e il flag di contestazione.

Una data da tenere a mente. GPT-6.1 Sol stesso risale al 29 settembre 2026 — questa non è un lancio, e nulla qui cambia i pesi, il prezzo o il tariffario del modello. Ciò che è successo il 19 ottobre è che OpenAI ha pubblicato prove su ciò che il modello può fare in una categoria che non aveva documentato in precedenza, e ha rilasciato un benchmark che chiunque può rieseguire. Questo è l'evento di cui tratta questo articolo.

Che cosa è stato effettivamente pubblicato e a cosa serve ciascuna delle due metà

Le due valutazioni rispondono a domande diverse, e la stessa impostazione di OpenAI le separa. MultiLangBench chiede se un modello può costruire qualcosa in un linguaggio su cui nessuno addestra: implementare SQLite 3.40.1 da zero in uno di venti linguaggi di programmazione, quindi superare una suite di conformità per database. La valutazione sulla migrazione COBOL chiede se un modello può spostare qualcosa: tradurre programmi COBOL in C++, Java, Kotlin, Python o Rust preservando esattamente il comportamento osservabile.

Il primo è un test di soglia di capacità. Il secondo è quello che interessa davvero alle imprese, perché COBOL non è una curiosità da benchmark — le stime di lunga data di IBM collocano COBOL dietro oltre il 40% dei sistemi di banking online e circa il 95% delle transazioni ATM, e il codice è mantenuto da una forza lavoro che non viene sostituita.

• MultiLangBench, massimo impegno — GPT-6 Astra 87,4%, GPT-6 Luna 40,3%, GPT-5.6 Sol 26,8%. Astra ha superato l'83% in 19 lingue su 20; COBOL è stata la sua peggiore con il 72,1% contro il 10,9% di GPT-5.6 Sol, il che dimostra che la lingua più difficile del set è ancora quella con gli strumenti più vecchi.

• Migrazione COBOL, impegno ridotto — GPT-6.1 Sol 86,6%, GPT-5.6 Sol 5,4%, a un costo API stimato pari al 61% di quello del modello precedente per l'esecuzione della valutazione, ovvero il 39% in meno.

• Migrazione COBOL, impegno maggiore — GPT-6.1 Sol 97,9%, che OpenAI descrive come prossimo alla saturazione.

• Dettaglio per linguaggio che OpenAI ha pubblicato — Fortran 83,5% per Astra contro 21,4% per GPT-5.6 Sol; Visual Basic 89,4% contro 27,5%; OCaml 85,8% contro 25,6%; GPT-6 Luna al 17,1% su COBOL, 31,4% su Fortran, 34,1% su OCaml e 41,6% su Visual Basic.

• Costo per campione su MultiLangBench — una stima di $0,77 per GPT-6 Luna contro $3,48 per GPT-5.6 Sol, circa il 78% in meno, che è il numero che rende il modello più debole della classifica quello interessante per una pipeline di generazione di build.

La valutazione che puoi rieseguire: cosa chiede realmente MultiLangBench

Il repository è github.com/openai/MultiLangBench, Apache-2.0, e leggere l'harness è più informativo che leggere la classifica. Il task è sufficientemente specifico da non permettere a un modello di bluffare: produrre un eseguibile che accetta un percorso di database come argomento da riga di comando, legge una query SQL da stdin e si comporta come SQLite 3.40.1. I test provengono dalla suite TCL di SQLite stessa — circa 51.000 test in totale, di cui circa 24.000 sono stati convertiti nelle triplette usate dall'harness: un database iniziale, una query utente e una query di validazione. I nomi dei test sono hash SHA-256 di tali componenti, quindi la suite non è memorizzabile per nome.

Le regole sono dove risiede la difficoltà, e ciascuna chiude una scorciatoia:

• Niente internet e nessun SQLite da nessuna parte nell'ambiente. L'harness dice di eliminare prima ogni traccia di SQLite. Un modello non può invocare il motore reale tramite shell e non può scaricare un'implementazione.

• La validazione viene eseguita su SQLite 3.40.1 reale. La tua implementazione modifica il database; l'harness lo estrae e lo verifica con l'originale autentico. Un comportamento approssimativo fallisce.

• Sessanta secondi per test, e una risposta nella lingua sbagliata vale zero. Mescolare le lingue fallisce, e l'ambiente di test segnala che potrebbe essere usato un altro modello per controllare in quale lingua hai effettivamente scritto. Quest'ultima regola esiste perché il trucco ovvio — scriverlo in Python e incapsularlo — è la prima cosa che prova un modello capace.

• L'esecuzione rapida prevede 272 test, non 24.000. Il README consiglia di eseguire solo i test i cui nomi iniziano con 00, 01 o 02 quando vuoi un numero comparabile. Questo è il dettaglio da notare prima di confrontare il tuo punteggio con quello di OpenAI: un'esecuzione dell'intera suite e un'esecuzione rapida non sono la stessa misurazione, e il README lo dice.

Questo è un benchmark reale e verificabile. Inoltre ti dice qualcosa che la copertura della stampa non ha detto: il dato dell'87,4% è stato misurato su una suite che puoi usare per mettere alla prova il tuo modello, cosa abbastanza rara da valere il download.

La valutazione che non puoi rieseguire, e perché non è automaticamente uno scandalo

La valutazione della migrazione COBOL è progettata, eseguita e valutata da OpenAI, e i suoi casi di test non sono pubblicati. La soglia di superamento è enunciata con precisione — una migrazione è valida solo se ogni test nascosto produce un output osservabile identico byte per byte — e proprio questa precisione è ciò che rende il risultato non verificabile dall'esterno: l'86,6% è la misurazione di OpenAI rispetto ai casi nascosti della stessa OpenAI. Solo una delle due valutazioni presenti nella release è qualcosa che un lettore può riprodurre.

Non rendere pubblici i test di migrazione non è una scelta indifendibile. Il corpus è presumibilmente ricavato da programmi legacy reali, e pubblicarlo può far trapelare codice dei clienti o consegnare ai modelli futuri un set di addestramento. Anche la parità byte per byte è un criterio genuinamente conservativo, più rigoroso della maggior parte delle valutazioni dei fornitori: non premia una traduzione che sia soltanto vicina.

Ma il criterio è anche il punto in cui iniziano i problemi pratici, e le stesse avvertenze di OpenAI lo evidenziano. L'output della migrazione necessita ancora di revisione esperta e di test rispetto alle regole di business e alle dipendenze di sistema prima della produzione. E la parità byte per byte è difficile esattamente nei punti in cui COBOL è difficile: il linguaggio tronca e arrotonda l'aritmetica in virgola fissa in modi che la maggior parte dei linguaggi di destinazione non adotta, quindi una traduzione può sembrare corretta, superare una suite che verifica "abbastanza vicino" e comunque spostare un saldo di un centesimo. Una suite nascosta che richiede uguaglianza esatta se ne occupa; anche il tuo processo di revisione deve occuparsene, perché il punteggio del modello non è un giudizio sui tuoi programmi.

La cifra dei costi richiede la stessa attenzione. Il risparmio del 39% è una stima per l’esecuzione della valutazione — token in ingresso e in uscita dal benchmark — non il costo di sostituzione di un sistema di produzione, che è dominato da discovery, revisione esperta, test di integrazione e dagli anni di comportamenti non documentati che nessuna valutazione campiona.

Che cosa dovrebbero cambiare 86,6% e 97,9% in una decisione

La lettura onesta è più ristretta di quanto dicano i titoli e più utile di essi. Un baseline del 5,4% non è un modello che funziona a metà; è un modello che quasi mai produce una traduzione che preserva il comportamento, quindi la generazione precedente non è mai stata un candidato per questo lavoro. GPT-6.1 Sol all'86,6% rientra nell'intervallo in cui l'economia si inverte: uno strumento che abbozza la maggior parte di una traduzione e lascia a un revisore il compito di verificarla è un prodotto diverso da uno che non produce nulla di utilizzabile.

Il 97,9% con sforzo maggiore è il dato di cui essere scettici, non perché sia sbagliato ma perché è saturo. Una volta che un benchmark è vicino al suo tetto, smette di discriminare tra i modelli e inizia a misurare la suite, e OpenAI lo dice apertamente. Per la pianificazione, considera l'86,6% con sforzo ridotto come punto operativo economico e il 97,9% come il tetto di ciò che la valutazione può mostrarti — non come una promessa di accuratezza per la tua base di codice.

C'è anche una verifica incrociata che vale la pena fare, e va contro l'entusiasmo. Nel test di build, COBOL è rimasto il linguaggio più debole di GPT-6 Astra al 72,1%, anche se Astra è il modello complessivamente più forte, con una media dell'87,4%. Il linguaggio è difficile in entrambe le direzioni. Un modello che migra bene il COBOL in una valutazione nascosta non è per questo bravo in COBOL; è bravo negli schemi campionati dalla valutazione.

L'altra cosa che è successa questa settimana: l'affermazione sulla traccia di ragionamento

Un post ampiamente condiviso del 21 ottobre affermava che le tracce di ragionamento di GPT-6.1 Sol sono "totalmente leggibili, niente di cui preoccuparsi". Nulla nella pubblicazione di OpenAI del 19 ottobre, e nulla nella pagina di documentazione del modello stesso, suffraga che ciò rappresenti un cambiamento in ciò che restituisce l'API. La guida al ragionamento di OpenAI è esplicita sul fatto che i token di ragionamento grezzi non vengono esposti — gli elementi di ragionamento restano opachi — e che ciò che puoi richiedere è un riepilogo del ragionamento tramite il parametro summary, con il contenuto di ragionamento cifrato riprodotto tra i turni. GPT-6.1 Sol supporta la forma all_turns di quella riproduzione. Un canale di riepilogo non è una traccia leggibile, e trattare le due cose come la stessa è il modo in cui si formula un'affermazione sulla sicurezza con uno screenshot.

Ciò che è misurabile è adiacente e più interessante per chiunque sottoponga a audit un agente. La valutazione di GPT-6.1 Sol condotta da Sonar il 9 ottobre, eseguita contro GPT-6 Sol con impegno medio su 4.444 attività Java, ha rilevato che i token di ragionamento sono calati del 51,4% — da 2,64M a 1,28M — mentre la quota del ragionamento sull'output è scesa dal 41,8% al 19,5%, l'output è aumentato e il tasso di superamento funzionale è migliorato dall'83,09% all'85,29%. La stessa esecuzione ha rilevato una densità di vulnerabilità inferiore del 32,4%, ma riscontri di affidabilità di gravità critica saliti da 21 a 46, con i bug di concorrenza come categoria più ampia a 196 riscontri. Questo è un compromesso su cui un revisore può agire. "Le tracce sono leggibili" non lo è, perché le tracce non sono ciò che viene restituito.

Per un progetto di migrazione questo conta in un modo concreto: la tua traccia di audit è il diff e l'output dei test, non la narrazione del modello. Dimensiona di conseguenza la capacità di revisione — il dato di Sonar secondo cui il 39,4% in più di codice generato ha prodotto 12.982 segnalazioni totali contro 9.859 è la forma del costo che si nasconde dietro un punteggio di benchmark.

Gestire entrambi i bracci da soli

Il problema pratico di un confronto come questo è che il braccio baseline e il nuovo braccio sono di solito due contratti, due chiavi e due relazioni di fatturazione, una frizione sufficiente perché nessuno esegua il baseline. Entrambi i modelli si trovano nel nostro catalogo dietro un'unica chiave: openai/gpt-6.1-sol e openai/gpt-5.6-sol, ai prezzi di listino di OpenAI con 0% di ricarico, quindi gli stessi $2,00 di input e $10,00 di output per milione di token che pagheresti al fornitore, con input in cache a $0,10 e scritture in cache a $2,50, e il livello oltre 272K applicato a $4,00, $0,20, $5,00 e $15,00. Una variazione delle tariffe del fornitore è attiva qui il giorno in cui viene pubblicata anziché alla successiva revisione contrattuale.

Quel pass-through è ciò che rende economico eseguire un benchmark nello stesso giorno: indirizza la quick suite di MultiLangBench su entrambi i modelli, paga il prezzo di listino per ciascuno e ottieni un numero che riguarda la tua toolchain, non quella di OpenAI. Il failover automatico è l'altra metà della questione: se il modello più recente degrada a metà esecuzione o una route subisce rate limiting, la richiesta non fallisce insieme a esso, ed è questo che ti consente di mettere un modello non ancora collaudato davanti a una pipeline di migrazione prima di avere prove tue.

Il harness MultiLangBench è pubblico e i casi di migrazione COBOL non lo sono, quindi l'unico test onesto dell'86,6% è quello che costruisci tu: campiona qualche centinaio dei tuoi programmi COBOL, traducili e confronta l'output byte per byte con il comportamento originale. È una settimana di lavoro e vale più della tabella del fornitore.

Cosa guardare dopo

Tre cose cambierebbero questo quadro, e nessuna è ancora accaduta. Se O​penAI pubblicasse i casi di migrazione COBOL, o un laboratorio indipendente li rieseguisse, un numero dichiarato da un fornitore diventerebbe una misurazione. Se una terza parte riproducesse la tabella per lingua di MultiLangBench, sapremmo se il 72,1% di COBOL è una proprietà del linguaggio o della suite. E il record indipendente del modello sui benchmark — Artificial Analysis attualmente colloca GPT-6.1 Sol a un Intelligence Index di 52, dodicesimo su 214 modelli, a 55,2 token di output al secondo e 0,72 $ per attività dell'indice — è il controllo che non dipende affatto dalle valutazioni interne di O​penAI.

Fino ad allora, il riassunto utile è breve. GPT-6.1 Sol è un modello del 29 settembre la cui capacità sul codice legacy è stata documentata il 19 ottobre, in una valutazione che puoi eseguire e una che non puoi. Quella eseguibile dice che la nuova generazione è di un'altra categoria sulle lingue a basse risorse. Quella non eseguibile dice che la migrazione COBOL ora vale un progetto pilota. Solo la tua base di codice può trasformare l'una o l'altra in una decisione.