GPT-6.1 Sol op COBOL: 86,6% tegenover 5,4%, en slechts één van de twee tests kan opnieuw worden uitgevoerd

Op 19 oktober 2026 publiceerde O​penAI twee code-evaluaties voor talen met weinig hulpbronnen, en het cijfer dat de aandacht trekt is van GPT-6.1 Sol: 86,6% van de COBOL-migratietaken werd gehaald bij lage reasoning-inspanning, tegenover 5,4% voor GPT-5.6 Sol bij dezelfde instelling, oplopend tot 97,9% wanneer de inspanning omhooggaat. De tweede evaluatie, MultiLangBench, vertelt het verhaal van een ander model — GPT-6 Astra scoorde gemiddeld 87,4% over twintig talen bij maximale inspanning — maar dat is het nuttigere deel van de release, omdat O​penAI de harness op GitHub heeft gezet onder Apache-2.0 en je die vanmiddag zelf kunt draaien. De COBOL-migratie-eval, degene met de 86,6%, is een ander verhaal: de tests zijn verborgen, het slaagcriterium is byte-voor-byte uitvoerpariteit met gevallen die niemand buiten O​penAI heeft gezien, en geen enkele derde partij heeft die gereproduceerd. Die asymmetrie is het hele verhaal, en het is de moeite waard om dat ronduit te zeggen voordat een van beide cijfers in een migratiebusinesscase wordt geciteerd. De gedocumenteerde AI-fouten en agentincidenten achter releases zoals deze zijn verzameld in het OrcaRouter AI Incident Archive waar elke vermelding haar eigen bronnen, ernst, betrouwbaarheidsgraad en betwist-vlag heeft.

Eén datum om goed uit elkaar te houden. GPT-6.1 Sol zelf is van 29 september 2026 — dit is geen lancering, en niets hier verandert de gewichten, prijs of tariefkaart van het model. Wat er op 19 oktober gebeurde, is dat OpenAI bewijs publiceerde over wat het model kan in een categorie die het niet eerder had gedocumenteerd, en een benchmark uitbracht die iedereen opnieuw kan uitvoeren. Dat is de gebeurtenis waar dit stuk over gaat.

Wat er daadwerkelijk is gepubliceerd, en waar elke helft voor dient

De twee evaluaties beantwoorden verschillende vragen, en OpenAI's eigen framing scheidt ze van elkaar. MultiLangBench vraagt of een model in staat is om iets te bouwen in een taal waarop niemand traint: implementeer SQLite 3.40.1 vanaf nul in een van twintig programmeertalen en slaag daarna voor een database-conformiteitssuite. De COBOL-migratie-evaluatie vraagt of een model in staat is om iets te verplaatsen: vertaal COBOL-programma's naar C++, Java, Kotlin, Python of Rust met exact behoud van waarneembaar gedrag.

De eerste is een test van het minimale capaciteitsniveau. De tweede is degene waar ondernemingen echt om geven, omdat COBOL geen benchmarkcuriositeit is — al lang bestaande schattingen van IBM plaatsen COBOL achter meer dan 40% van de onlinebankingsystemen en ongeveer 95% van de ATM-transacties, en de code wordt onderhouden door een beroepsbevolking die niet wordt vervangen.

• MultiLangBench, maximale inspanning — GPT-6 Astra 87,4%, GPT-6 Luna 40,3%, GPT-5.6 Sol 26,8%. Astra haalde 83% in 19 van de 20 talen; COBOL was met 72,1% zijn zwakste punt, tegenover 10,9% voor GPT-5.6 Sol, wat laat zien dat de moeilijkste taal in de set nog steeds degene is met de oudste tooling.

• COBOL-migratie, weinig inspanning — GPT-6.1 Sol 86,6%, GPT-5.6 Sol 5,4%, tegen naar schatting 61% van de API-kosten van het oudere model voor de evaluatierun, ofwel 39% minder.

• COBOL-migratie, hogere inspanning — GPT-6.1 Sol 97,9%, wat OpenAI omschrijft als dicht bij verzadiging.

• Per-taalgegevens die OpenAI wel publiceerde — Fortran 83,5% voor Astra tegenover 21,4% voor GPT-5.6 Sol; Visual Basic 89,4% tegenover 27,5%; OCaml 85,8% tegenover 25,6%; GPT-6 Luna op 17,1% bij COBOL, 31,4% bij Fortran, 34,1% bij OCaml en 41,6% bij Visual Basic.

• Kosten per sample op MultiLangBench — een geschatte $0,77 voor GPT-6 Luna tegenover $3,48 voor GPT-5.6 Sol, ongeveer 78% lager, en dat is het getal dat het zwakste model op het scorebord interessant maakt voor een build-generation-pipeline.

De evaluatie die je opnieuw kunt uitvoeren: waar MultiLangBench eigenlijk om vraagt

De repository is github.com/openai/MultiLangBench, Apache-2.0, en het lezen van de harness is informatiever dan het lezen van het leaderboard. De taak is specifiek genoeg dat een model er niet mee kan bluffen: produceer een uitvoerbaar bestand dat een databaselocatie als command-lineargument neemt, een SQL-query van stdin leest en zich gedraagt als SQLite 3.40.1. De tests komen uit SQLite's eigen TCL-suite — in totaal ongeveer 51.000 tests, waarvan er ruwweg 24.000 zijn omgezet naar de tripletten die de harness gebruikt: een initiële database, een gebruikersquery en een validatiequery. Testnamen zijn SHA-256-hashes van die onderdelen, dus de suite is niet op naam te memoriseren.

De moeilijkheid zit in de regels, en elke regel sluit een sluiproute af:

• Geen internet, en nergens in de omgeving SQLite.De harness zegt dat eerst elk spoor van SQLite moet worden verwijderd. Een model kan de echte engine niet via de shell aanroepen, en het kan geen implementatie ophalen.

• Validatie wordt uitgevoerd tegen echte SQLite 3.40.1. Je implementatie wijzigt de database; de harness haalt deze eruit en controleert deze met het echte exemplaar. Gedrag dat slechts bij benadering klopt, faalt.

• Zestig seconden per test, en een antwoord in de verkeerde taal levert nul punten op. Het mengen van talen mislukt, en de testomgeving merkt op dat een ander model kan worden gebruikt om te controleren in welke taal je daadwerkelijk hebt geschreven. Die laatste regel bestaat omdat de voor de hand liggende cheat — het in Python schrijven en inpakken — het eerste is dat een capabel model probeert.

• De snelle run bestaat uit 272 tests, niet 24.000. De README raadt aan alleen de tests te draaien waarvan de namen beginnen met 00, 01 of 02 als je een vergelijkbaar aantal wilt. Dat is het detail dat je moet onthouden voordat je je eigen score vergelijkt met die van O​penAI: een volledige suite-run en een snelle run zijn niet dezelfde meting, en dat staat in de README.

Dat is een echte, verifieerbare benchmark. Het vertelt je ook iets wat de media-aandacht niet deed: de 87,4%-kop was gebaseerd op een suite waarop je je eigen model kunt loslaten, wat zeldzaam genoeg is om de download waard te zijn.

De evaluatie die je niet opnieuw kunt uitvoeren, en waarom dat niet automatisch een schandaal is

De evaluatie van de COBOL-migratie is door OpenAI ontworpen, door OpenAI uitgevoerd en door OpenAI beoordeeld, en de testcases ervan zijn niet gepubliceerd. De slaagdrempel wordt precies vermeld — een migratie telt alleen als elke verborgen test byte-for-byte identieke waarneembare output oplevert — en juist die precisie maakt het resultaat van buitenaf niet verifieerbaar: de 86.6% is OpenAI's meting tegen OpenAI's eigen verborgen cases. Slechts een van de twee evaluaties in de release is iets dat een lezer kan reproduceren.

Het achterhouden van migratietests is niet onverdedigbaar. Het corpus is vermoedelijk afkomstig uit echte legacyprogramma's, en publicatie ervan kan klantcode lekken of toekomstige modellen een trainingsset aanreiken. Byte-for-byte-pariteit is ook een oprecht conservatief criterium, strenger dan de meeste leveranciersevaluaties: het beloont een vertaling die slechts bij benadering klopt niet.

Maar het criterium is ook waar de praktische problemen beginnen, en de eigen waarschuwingen van O​penAI wijzen daarop. Migratie-output moet nog steeds door experts worden beoordeeld en getest tegen bedrijfsregels en systeemafhankelijkheden voordat het naar productie gaat. En bytepariteit is juist moeilijk op de plekken waar COBOL moeilijk is: de taal kapt en rondt fixed-point-rekenkunde af op manieren die de meeste do talen niet doen, waardoor een vertaling correct kan lijken, een suite kan halen die "goed genoeg" controleert, en toch een saldo met een cent kan verschuiven. Een verborgen suite die exacte gelijkheid vereist, vangt dat op; je eigen reviewproces moet dat ook opvangen, want de score van het model zegt niets over jouw programma's.

Het kostencijfer vraagt dezelfde zorgvuldigheid. De besparing van 39% is een schatting voor de evaluatierun — tokens die de benchmark in en uit gaan — niet de kosten van het vervangen van een productiesysteem, die worden gedomineerd door discovery, expertreview, integratietests en de jaren aan ongedocumenteerd gedrag die geen enkele eval bemonstert.

Wat 86,6% en 97,9% in een beslissing zouden moeten veranderen

De eerlijke lezing is beperkter dan de krantenkoppen en nuttiger dan die koppen. Een basislijn van 5,4% is geen model dat half werkt; het is een model dat bijna nooit een gedragsbehoudende vertaling oplevert, dus de oudere generatie was nooit een kandidaat voor dit werk. GPT-6.1 Sol op 86,6% zit in het bereik waarin de economische logica kantelt: een tool die het grootste deel van een vertaling opstelt en het aan een reviewer overlaat om die te controleren, is een ander product dan een tool die niets bruikbaars oplevert.

Het getal van 97,9% bij hogere inspanning is het getal waar je sceptisch over moet zijn, niet omdat het onjuist is, maar omdat het verzadigd is. Zodra een benchmark zijn plafond nadert, onderscheidt hij niet langer tussen modellen en begint hij de suite te meten, en O​penAI zegt dat zelf ook. Beschouw voor planning 86,6% bij lage inspanning als het goedkope werkpunt en 97,9% als het plafond van wat de evaluatie je kan laten zien — niet als een nauwkeurigheidsbelofte voor je codebase.

Er is ook een kruiscontrole de moeite waard, en die gaat tegen de hype in. In de buildtest bleef COBOL de zwakste taal van GPT-6 Astra op 72,1%, ook al is Astra het sterkere model overall met een gemiddelde van 87,4%. De taal is in beide richtingen lastig. Een model dat COBOL goed migreert in een verborgen eval, is daarmee nog niet goed in COBOL; het is goed in het patroon dat de eval bemonstert.

Het andere dat deze week gebeurde: de bewering over de redeneertrace

Een veel gedeelde post op 21 oktober stelde dat de redeneersporen van GPT-6.1 Sol "volledig leesbaar, niets om je zorgen over te maken" zijn. Niets in OpenAI's publicatie van 19 oktober, en niets op de eigen documentatiepagina van het model, ondersteunt dat als een wijziging in wat de API retourneert. De reasoninggids van OpenAI maakt expliciet dat ruwe reasoningtokens niet worden vrijgegeven — reasoningitems blijven ondoorzichtig — en dat wat je kunt opvragen een samenvatting van de redenering via de summary-parameter is, waarbij versleutelde reasoninginhoud over beurten heen opnieuw wordt afgespeeld. GPT-6.1 Sol ondersteunt de all_turnsvorm van die replay. Een samenvattingskanaal is geen leesbaar spoor, en de twee als hetzelfde behandelen is hoe een veiligheidsclaim via een screenshot wordt gemaakt.

Wat meetbaar is, ligt daarnaast en is interessanter voor iedereen die een agent audit. Sonars evaluatie van 9 oktober van GPT-6.1 Sol, uitgevoerd tegen GPT-6 Sol bij medium inspanning over 4.444 Java-taken, vond dat reasoning-tokens met 51,4% daalden — van 2,64M naar 1,28M — terwijl het aandeel van reasoning in de output daalde van 41,8% naar 19,5%, de output steeg en de functionele slaagkans verbeterde van 83,09% naar 85,29%. Dezelfde run vond een daling van de kwetsbaarheidsdichtheid met 32,4%, maar het aantal betrouwbaarheidsbevindingen met kritieke ernst steeg van 21 naar 46, waarbij concurrencybugs de grootste categorie vormden met 196 bevindingen. Dat is een afweging waar een reviewer op kan handelen. "Traces zijn leesbaar" is dat niet, omdat de traces niet zijn wat er wordt geretourneerd.

Voor een migratieproject is dit op één concrete manier van belang: je audittrail is de diff en de testoutput, niet de vertelling van het model. Begroot de reviewcapaciteit daarop — Sonars bevinding dat 39,4% meer gegenereerde code 12.982 totale bevindingen opleverde tegenover 9.859, is de vorm van de kosten die achter een benchmarkscore schuilgaat.

Zelf beide armen uitvoeren

Het praktische probleem met een vergelijking als deze is dat de baseline-arm en de nieuwe arm meestal twee contracten, twee sleutels en twee factureringsrelaties zijn, wat genoeg wrijving oplevert dat niemand de baseline uitvoert. Beide modellen staan in onze catalogus achter één sleutel: openai/gpt-6.1-sol en openai/gpt-5.6-sol, tegen de lijstprijzen van OpenAI met 0% opslag, dus dezelfde $2,00 voor input en $10,00 voor output per miljoen tokens die je bij de leverancier zou betalen, met gecachte input tegen $0,10 en cache-schrijfacties tegen $2,50, en de tier boven 272K doorberekend tegen $4,00, $0,20, $5,00 en $15,00. Een tariefwijziging van de leverancier is hier live op de dag dat die wordt gepubliceerd, in plaats van bij de volgende contractbeoordeling.

Die pass-through is wat een benchmark van dezelfde dag goedkoop maakt om te draaien: richt de MultiLangBench quick suite op beide modellen, betaal de lijstprijs voor elk, en je hebt een getal over je eigen toolchain in plaats van dat van OpenAI. Automatische failover is de andere helft van het argument — als het nieuwere model tijdens de run degradeert of een route een rate limit krijgt, faalt het verzoek niet mee, en dat is wat je in staat stelt een onbewezen model voor een migratiepijplijn te zetten voordat je je eigen bewijs hebt.

De MultiLangBench-harness is openbaar en de COBOL-migratiecases niet, dus de enige eerlijke test van de 86,6% is degene die je zelf bouwt: neem een paar honderd van je eigen COBOL-programma's als steekproef, vertaal ze en vergelijk de uitvoer byte voor byte met het oorspronkelijke gedrag. Dat is een week werk en het is meer waard dan de leverancierstabel.

Wat nu te kijken

Drie dingen zouden dit beeld veranderen, en geen daarvan is tot nu toe gebeurd. Als O​penAI de COBOL-migratiecases publiceert, of een onafhankelijk lab ze opnieuw uitvoert, zou dat een leveranciersgetal in een meting veranderen. Een derde partij die de MultiLangBench-tabel per taal reproduceert, zou ons vertellen of COBOL's 72,1% een eigenschap van de taal is of van de suite. En de onafhankelijke benchmarkrecord van het model — Artificial Analysis plaatst GPT-6.1 Sol momenteel op een Intelligence Index van 52, twaalfde van 214 modellen, met 55,2 outputtokens per seconde en $0,72 per indextaak — is de controle die helemaal niet afhankelijk is van de eigen evaluaties van O​penAI.

Tot dan is de bruikbare samenvatting kort. GPT-6.1 Sol is een model van 29 september waarvan de legacy-codecapaciteit op 19 oktober werd gedocumenteerd, in één eval die je kunt uitvoeren en één die je niet kunt uitvoeren. De uitvoerbare zegt dat de nieuwe generatie in een andere klasse zit bij talen met weinig bronnen. De niet-uitvoerbare zegt dat COBOL-migratie nu een pilot waard is. Alleen je eigen codebase kan van elk daarvan een beslissing maken.