GPT-6.1 Sol på COBOL: 86,6 % mot 5,4 %, och endast ett av de två testerna kan köras om

Den 19 oktober 2026 publicerade O​penAI två kodningsevalueringar för lågresursspråk, och den mest uppmärksammade siffran tillhör GPT-6.1 Sol: 86,6 % av COBOL-migreringsuppgifterna klarades vid låg resonemangsansträngning, mot 5,4 % för GPT-5.6 Sol vid samma inställning, och den stiger till 97,9 % när ansträngningen höjs. Den andra evalueringen, MultiLangBench, är en annan models historia – GPT-6 Astra hade i genomsnitt 87,4 % över tjugo språk vid maximal ansträngning – men det är den mer användbara halvan av lanseringen, eftersom O​penAI lade sitt testramverk på GitHub under Apache-2.0 och du kan köra det själv i eftermiddag. COBOL-migreringsevalueringen, den som står för de 86,6 %, är en annan sak: dess tester är dolda, dess godkännandekriterium är byte-för-byte-utdataparitet mot fall som ingen utanför O​penAI har sett, och ingen tredje part har reproducerat den. Den asymmetrin är hela historien, och det är värt att säga rakt ut innan någon av siffrorna citeras i ett affärsärende för migrering. De dokumenterade AI-felen och agentincidenterna bakom lanseringar som den här samlas i OrcaRouter AI Incident Archive där varje post har sina egna källor, allvarlighetsgrad, konfidensbetyg och flagga för omstridd.

Ett datum att hålla reda på. GPT-6.1 Sol i sig är från 29 september 2026 — det här är inte en lansering, och ingenting här ändrar modellens vikter, pris eller prislista. Det som hände den 19 oktober var att OpenAI publicerade bevis för vad modellen kan göra i en kategori som företaget inte tidigare hade dokumenterat, och släppte ett benchmark som alla kan köra om. Det är händelsen som den här artikeln handlar om.

Vad som faktiskt publicerades, och vad varje hälft är till för

De två utvärderingarna besvarar olika frågor, och OpenAI:s egen formulering skiljer dem åt. MultiLangBench frågar om en modell kan bygga något på ett språk som ingen tränar på: implementera SQLite 3.40.1 från grunden i ett av tjugo programmeringsspråk och sedan klara en databaskonformitetssvit. Utvärderingen av COBOL-migrering frågar om en modell kan flytta något: översätta COBOL-program till C++, Java, Kotlin, Python eller Rust samtidigt som det observerbara beteendet bevaras exakt.

Den första är ett test av kapacitetsgolvet. Den andra är den som företagen faktiskt bryr sig om, eftersom COBOL inte är en benchmarkkuriositet – IBMs långvariga uppskattningar visar att COBOL ligger bakom mer än 40 % av onlinebanksystemen och cirka 95 % av bankomattransaktionerna, och koden underhålls av en arbetsstyrka som inte ersätts.

• MultiLangBench, maximal insats — GPT-6 Astra 87,4 %, GPT-6 Luna 40,3 %, GPT-5.6 Sol 26,8 %. Astra klarade 83 % i 19 av 20 språk; COBOL var dess svagaste på 72,1 % mot GPT-5.6 Sols 10,9 %, vilket visar att det svåraste språket i uppsättningen fortfarande är det med de äldsta verktygen.

• COBOL-migrering, låg insats — GPT-6.1 Sol 86,6 %, GPT-5.6 Sol 5,4 %, till en uppskattad kostnad av 61 % av den äldre modellens API-kostnad för utvärderingskörningen, eller 39 % mindre.

• COBOL-migrering, högre arbetsinsats — GPT-6.1 Sol 97,9 %, som OpenAI beskriver som nära mättnad.

• Detaljer per språk som OpenAI faktiskt publicerade — Fortran 83,5 % för Astra mot 21,4 % för GPT-5.6 Sol; Visual Basic 89,4 % mot 27,5 %; OCaml 85,8 % mot 25,6 %; GPT-6 Luna på 17,1 % för COBOL, 31,4 % för Fortran, 34,1 % för OCaml och 41,6 % för Visual Basic.

• Kostnad per prov på MultiLangBench — uppskattningsvis 0,77 USD för GPT-6 Luna mot 3,48 USD för GPT-5.6 Sol, cirka 78 % lägre, vilket är siffran som gör den svagaste modellen på tavlan till den intressanta för en build-genereringspipeline.

Utvärderingen du kan köra om: vad MultiLangBench faktiskt efterfrågar

Repositoriet finns på github.com/openai/MultiLangBench, Apache-2.0, och att läsa testramverket är mer informativt än att läsa resultattavlan. Uppgiften är tillräckligt specifik för att en modell inte ska kunna bluffa sig igenom den: producera en körbar fil som tar en databassökväg som kommandoradsargument, läser en SQL-fråga från stdin och beter sig som SQLite 3.40.1. Testerna kommer från SQLites egen TCL-svit – cirka 51 000 tester totalt, varav ungefär 24 000 konverterades till de tripletter som testramverket använder: en initial databas, en användarfråga och en valideringsfråga. Testnamnen är SHA-256-hashar av dessa komponenter, så sviten kan inte memoreras utifrån namn.

Det är i reglerna svårigheten ligger, och varje regel stänger en genväg:

• Ingen internetanslutning och ingen SQLite någonstans i miljön. Testramverket säger att man först ska ta bort varje spår av SQLite. En modell kan inte anropa den riktiga motorn via skalet, och den kan inte hämta en implementation.

• Validering körs mot riktig SQLite 3.40.1. Din implementering ändrar databasen; testramverket extraherar den och kontrollerar den mot den äkta varan. Ungefärligt beteende misslyckas.

• Sextio sekunder per test, och ett svar på fel språk ger noll poäng. Att blanda språk misslyckas, och testramverket noterar att en annan modell kan användas för att kontrollera vilket språk du faktiskt skrev på. Den sista regeln finns eftersom det uppenbara fusket – att skriva det i Python och wrappa det – är det första en kapabel modell försöker sig på.

• Snabbkörningen är 272 tester, inte 24 000. README rekommenderar att bara köra de tester vars namn börjar med 00, 01 eller 02 när du vill ha en jämförbar siffra. Det är detaljen att lägga märke till innan du jämför din egen poäng med OpenAIs: en körning av hela sviten och en snabbkörning är inte samma mätning, och det står i README.

Det är ett verkligt, kontrollerbart benchmark. Det säger också något som pressbevakningen inte gjorde: att rubriksiffran 87,4 % mättes på en testsvit som du kan köra din egen modell mot, vilket är ovanligt nog att vara värt nedladdningen.

Utvärderingen du inte kan köra om, och varför det inte automatiskt är en skandal

Utvärderingen av COBOL-migreringen är designad, genomförd och poängsatt av OpenAI, och dess testfall publiceras inte. Godkännandegränsen anges exakt – en migrering räknas bara om varje dolt test ger byte-för-byte identisk observerbar utdata – och just den precisionen är det som gör resultatet omöjligt att verifiera utifrån: 86,6 % är OpenAIs mätning mot OpenAIs egna dolda fall. Endast en av de två utvärderingarna i utgåvan är något en läsare kan reproducera.

Att undanhålla migreringstester är inte oförsvarligt. Korpusen är förmodligen hämtad från riktiga äldre program, och att publicera den kan läcka kundkod eller ge framtida modeller en träningsuppsättning. Byte-för-byte-paritet är också ett genuint konservativt kriterium, strängare än de flesta leverantörsutvärderingar: det belönar inte en översättning som bara är nära.

Men kriteriet är också där de praktiska problemen börjar, och OpenAI:s egna förbehåll pekar på det. Migreringsresultat behöver fortfarande expertgranskning och testning mot affärsregler och systemberoenden innan produktion. Och byte-paritet är svårt på precis de ställen där COBOL är svårt: språket trunkerar och avrundar fixpunktsaritmetik på sätt som de flesta målspråk inte gör, så en översättning kan se korrekt ut, klara en testsvit som kontrollerar "tillräckligt nära" och ändå flytta ett saldo med en cent. En dold testsvit som kräver exakt likhet hanterar det; din egen granskningsprocess måste också hantera det, eftersom modellens poäng inte är ett uttalande om dina program.

Kostnadssiffran kräver samma omsorg. Besparingen på 39 % är en uppskattning för utvärderingskörningen – token in och ut ur benchmarken – inte kostnaden för att ersätta ett produktionssystem, som domineras av kartläggning, expertgranskning, integrationstestning och de år av odokumenterat beteende som ingen utvärdering fångar.

Vad 86,6 % och 97,9 % bör ändra i ett beslut

Den ärliga tolkningen är snävare än rubrikerna och mer användbar än dem. En baslinje på 5,4 % är inte en modell som fungerar halvt; det är en modell som nästan aldrig producerar en beteendebevarande översättning, så den äldre generationen var aldrig aktuell för det här arbetet. GPT-6.1 Sol på 86,6 % ligger i intervallet där ekonomin inverteras: ett verktyg som tar fram större delen av en översättning och låter en granskare kontrollera den är en annan produkt än ett som inte producerar något användbart.

97,9 % vid högre ansträngningsnivå är siffran man bör vara skeptisk mot, inte för att den är fel utan för att den är mättad. När ett benchmark är nära sitt tak slutar det skilja mellan modeller och börjar mäta testsviten, och det är precis vad OpenAI säger. Vid planering bör du betrakta 86,6 % vid låg ansträngningsnivå som den billiga driftpunkten och 97,9 % som taket för vad utvärderingen kan visa dig – inte som ett löfte om träffsäkerhet för din kodbas.

Det finns också en korskontroll som är värd att göra, och den talar emot hypen. I byggtestet förblev COBOL GPT-6 Astras svagaste språk på 72,1 % trots att Astra är den starkare modellen totalt sett med ett snitt på 87,4 %. Språket är svårt åt båda hållen. En modell som migrerar COBOL väl i en dold utvärdering är inte därmed bra på COBOL; den är bra på det mönster som utvärderingen samplar.

Det andra som hände den här veckan: påståendet om resonemangsspåret

Ett mycket delat inlägg den 21 oktober påstod att GPT-6.1 Sols resonemangsspår är "helt läsbara, inget att oroa sig för." Inget i OpenAI:s publikation från den 19 oktober, och inget på modellens egen dokumentationssida, stöder att det skulle vara en förändring av vad API:et returnerar. OpenAI:s resonemangsguide är tydlig med att råa resonemangstoken inte exponeras – resonemangsobjekt förblir ogenomskinliga – och att det du kan begära är en sammanfattning av resonemanget via summary-parametern, med krypterat resonemangsinnehåll som spelas upp mellan turer. GPT-6.1 Sol stöder all_turns-formen av den uppspelningen. En sammanfattningskanal är inte ett läsbart spår, och att behandla de två som samma sak är hur ett säkerhetspåstående görs via en skärmbild.

Det som är mätbart ligger nära och är mer intressant för alla som granskar en agent. Sonars utvärdering den 9 oktober av GPT-6.1 Sol, som kördes mot GPT-6 Sol med medelhög ansträngning över 4 444 Java-uppgifter, fann att resonemangstokens minskade med 51,4 % – från 2,64M till 1,28M – medan resonemangets andel av utdata sjönk från 41,8 % till 19,5 %, utdata ökade och den funktionella godkännandegraden förbättrades från 83,09 % till 85,29 %. Samma körning fann att sårbarhetstätheten minskade med 32,4 %, men att tillförlitlighetsfynd med kritisk allvarlighetsgrad ökade från 21 till 46, där samtidighetsbuggar var den största kategorin med 196 fynd. Det är en avvägning som en granskare kan agera utifrån. "Spåren är läsbara" är det inte, eftersom spåren inte är det som returneras.

För ett migrationsprojekt spelar detta roll på ett konkret sätt: ditt revisionsspår är diffen och testutdata, inte modellens berättelse. Budgetera granskningskapacitet därefter — Sonars fynd att 39,4 % mer genererad kod gav 12 982 totala fynd mot 9 859 är formen på den kostnad som döljer sig bakom en benchmarkpoäng.

Att själv driva båda armarna

Det praktiska problemet med en sådan här jämförelse är att baslinjearmen och den nya armen vanligtvis är två kontrakt, två nycklar och två faktureringsrelationer, vilket är tillräckligt mycket friktion för att ingen kör baslinjen. Båda modellerna finns i vår katalog bakom en enda nyckel: openai/gpt-6.1-sol och openai/gpt-5.6-sol, till OpenAIs listpriser med 0 % påslag, så samma $2,00 för indata och $10,00 för utdata per miljon token som du skulle betala leverantören, med cachad indata på $0,10 och cache-skrivningar på $2,50, och nivån över 272K vidarefakturerad till $4,00, $0,20, $5,00 och $15,00. En ändring av leverantörens pris gäller här samma dag som den publiceras i stället för vid nästa kontraktsgenomgång.

Det är denna vidarebefordran som gör en benchmark som körs samma dag billig att genomföra: rikta MultiLangBench quick suite mot båda modellerna, betala listpris för var och en och du har en siffra om din egen verktygskedja snarare än OpenAIs. Automatisk failover är den andra halvan av argumentet – om den nyare modellen försämras under körningen eller en route blir ratebegränsad, misslyckas inte begäran tillsammans med den, vilket är det som gör att du kan sätta en obeprövad modell framför en migreringspipeline innan du har egna bevis.

MultiLangBench-testramverket är offentligt och COBOL-migreringsfallen är det inte, så det enda ärliga testet av 86,6 % är det du bygger själv: ta ett urval på några hundra av dina egna COBOL-program, översätt dem och jämför utdata byte för byte mot det ursprungliga beteendet. Det är en veckas arbete och det är värt mer än leverantörens tabell.

Vad du ska titta på härnäst

Tre saker skulle förändra bilden, och ingen av dem har hänt ännu. Att O​penAI publicerar COBOL-migreringsfallen, eller att ett oberoende labb kör om dem, skulle förvandla en leverantörssiffra till en mätning. Om en tredje part reproducerar MultiLangBench-tabellen per språk skulle det visa oss huruvida COBOLs 72,1 % är en egenskap hos språket eller hos testsviten. Och modellens oberoende benchmarkresultat – Artificial Analysis placerar för närvarande GPT-6.1 Sol på ett Intelligence Index på 52, på tolfte plats av 214 modeller, med 55,2 uttoken per sekund och 0,72 dollar per indexuppgift – är den kontroll som inte alls beror på O​penAIs egna utvärderingar.

Fram till dess är den användbara sammanfattningen kort. GPT-6.1 Sol är en modell från 29 september vars förmåga med äldre kod dokumenterades den 19 oktober, i en utvärdering du kan köra och en du inte kan. Den körbara säger att den nya generationen tillhör en annan klass när det gäller lågresursspråk. Den icke körbara säger att COBOL-migrering nu är värd en pilot. Bara din egen kodbas kan omvandla någon av dem till ett beslut.