1. Home
2. News
3. OpenAI

OpenAI says GPT-6.1 Sol scores 86.6% on its COBOL migration test, up from 5.4%

The test only passes a rewrite whose output matches the old program byte for byte, down to how it rounds money.

By Think Facility · October 20, 2026 · OpenAI AI models Save

On October 19, 2026, OpenAI published results showing its newest models are far better at old programming languages like COBOL, Fortran and Visual Basic. On OpenAI's own test of moving COBOL programs into another language, GPT-6.1 Sol got 86.6% right at low reasoning effort. GPT-5.6 Sol managed 5.4%.

That's a jump from almost never to most of the time, in one model generation. It's also a test OpenAI built and scores itself, and its migration tests aren't public.

Published

October 19, 2026

COBOL migration, GPT-6.1 Sol

86.6% at low reasoning effort

Same test, GPT-5.6 Sol

5.4%

Higher effort, GPT-6.1 Sol

97.9%

MultiLangBench, GPT-6 Astra

87.4% across 20 languages

What OpenAI tested

There are two tests. The first, MultiLangBench, asks a model to build a database engine that works like SQLite, from scratch, in one of 20 languages, then checks it with tests adapted from SQLite's own suite. GPT-6 Astra averaged 87.4% at maximum reasoning effort, up from 26.8% for GPT-5.6 Sol.

COBOL stayed the hardest of the 20, at 72.1% (it was 10.9%). Fortran went from 21.4% to 83.5%. The cheaper GPT-6 Luna got to 40.3%, at an estimated $0.77 a sample against $3.48 for GPT-5.6 Sol.

The second test is the one a bank would care about. A model moves COBOL programs into C++, Java, Kotlin, Python or Rust, and it only passes if every hidden test matches the old output byte for byte. At higher reasoning effort GPT-6.1 Sol reached 97.9%, which OpenAI says brings the test close to saturation.

OpenAI gives a concrete example of what can go wrong.

I think that's the most useful line in the post. A rewrite that crashes gets caught on day one. One that rounds a little differently might not, and that's the failure this test was built to find. OpenAI adds that using this on real production software still needs expert review and testing against the system's business rules.

Why banks and governments care

OpenAI's post cites outside figures that COBOL supports more than 40% of online banking systems, 80% of in-person credit card transactions and 95% of ATM transactions. Fortran, it says, is used in weather forecasting and nuclear reactor safety analysis.

The US government has the same problem, and it's been written down. In July 2025 the Government Accountability Office listed the 11 federal legacy systems most in need of modernization. Eight of them use outdated languages. Both Treasury systems on the list support tax processing, and both run on COBOL and assembly, languages with "a dwindling number of people available with the skills needed to support them."

Progress has been slow. Of the ten critical systems GAO flagged back in 2019, agencies had finished modernizing three as of February 2025. One at Health and Human Services isn't due until the end of fiscal year 2035.

1. June 2019GAO flags ten critical legacy systems
2. February 2025three of the ten modernized
3. July 2025GAO names the 11 most critical
4. October 19, 2026OpenAI posts its COBOL results

So for people who never write code, the stake is the plumbing behind their bank card and their tax return. If a model can move that code across without changing what it does, the shortage of COBOL programmers matters a lot less. That's a big if, and OpenAI's own warning about expert review still applies.

OpenAI isn't alone in chasing this work. A post on Anthropic's Claude blog makes the same pitch for Claude Code, noting that the developers who built these systems retired years ago and that COBOL is taught at only a handful of universities.

What happens next

OpenAI is putting MultiLangBench's setup, test suite and per-language results on GitHub, so anyone can run it against other models. The COBOL migration test isn't part of that release. In its post on X, OpenAI asked teams working on these systems to tell it which languages and workflows to tackle next.