OpenAI says its new models finally get COBOL, Fortran and Visual Basic

Most of the AI coding conversation is about Python, JavaScript and TypeScript, the languages with mountains of public code for models to learn from. The software that moves your money is often written in something much older. On 19 October 2026, OpenAI published a research post saying its newest models have made a large jump in exactly those older, rarer languages: COBOL, Fortran, OCaml and Visual Basic. The headline number comes from a COBOL migration test, where GPT-6.1 Sol went from almost never succeeding to almost always succeeding.

This article is based on OpenAI's post "Advancing coding in low resource programming languages" and the public MultiLangBench repository on GitHub, with reporting from Engadget and Dataconomy. All benchmark results below are OpenAI's own, measured on evaluations OpenAI designed. No outside group has reproduced them yet.

The numbers in one paragraph

OpenAI built two evaluations. The first, a COBOL migration test, asks a model to rewrite existing COBOL programs in C++, Java, Kotlin, Python or Rust without changing what they do. At low reasoning effort, the older GPT-5.6 Sol passed 5.4 percent of these migrations. GPT-6.1 Sol passed 86.6 percent at the same setting, and OpenAI says it did so at 61 percent of the older model's API cost. With more reasoning effort, GPT-6.1 Sol reached 97.9 percent, which OpenAI describes as close to saturating the test. The second evaluation, MultiLangBench, asks a model to build a working SQLite compatible database engine from scratch in one of 20 languages. GPT-6 Astra passed 87.4 percent of tests on average, against 26.8 percent for GPT-5.6 Sol.

What a low resource language is

In machine learning, "low resource" means there is little training data. A language like Python has decades of open source projects, tutorials, Stack Overflow answers and documentation on the public web. COBOL, created in 1959, mostly lives inside banks, insurers and government agencies, behind firewalls, in codebases that were never published. Fortran is older still and dominates scientific computing. OCaml has a loyal but small community, and Visual Basic powers huge numbers of internal business tools that nobody ever put on GitHub.

The result is a mismatch. These languages run systems that matter a great deal, yet models see very little of them during training. OpenAI says its developers and enterprise customers told it directly that coding models often struggle here, and the company frames the new work as a response to that feedback.

Why this matters outside of tech

OpenAI cites a few figures to explain the stakes. COBOL, it says, supports more than 40 percent of online banking systems, 80 percent of in person credit card transactions and 95 percent of ATM transactions. Fortran is used in weather forecasting and in safety analysis for nuclear reactors. These numbers have circulated in the industry for years and come from older surveys, so treat them as an order of magnitude rather than a precise current count. Even so, the picture is clear: a lot of everyday infrastructure depends on code that fewer and fewer people can read.

Maintaining that code is hard for reasons that have nothing to do with AI. Documentation is often incomplete. The people who wrote the original programs have retired or left. And important business rules may exist only in the code itself, never written down anywhere else. When a bank wants to move off a mainframe, it is not just translating syntax. It is trying to keep thousands of small decisions intact, many of which nobody alive remembers making.

Test one: migrating COBOL without breaking anything

The COBOL migration evaluation is the more practical of the two. A model receives an existing COBOL program and must produce an equivalent program in one of five modern languages. The new program is then run against hidden tests that require byte for byte parity on everything the program outputs. A migration only counts as successful if every single test passes. There is no partial credit.

OpenAI gives a good example of why this is tricky. COBOL uses fixed point arithmetic, and by default it simply discards extra decimal digits unless the code explicitly asks for rounding. A modern rewrite that rounds those values instead will compile, run without a single error and look perfectly reasonable, yet produce different financial results. Across millions of transactions, a difference of one cent here and there is not a rounding error in the casual sense. It is a bug in a bank. The same applies to how a program handles missing records, how it formats output and how it treats edge cases that only show up once a year.

On this test, GPT-5.6 Sol at low reasoning effort managed 5.4 percent. That is effectively a failure: you could not use it for real migration work without rewriting almost everything by hand. GPT-6.1 Sol at the same low effort reached 86.6 percent, at 39 percent lower API cost. Turning reasoning effort up pushed it to 97.9 percent.

Test two: rebuilding SQLite in 20 languages

MultiLangBench is the more ambitious test, and OpenAI has published it as open source under the Apache 2.0 license. The task sounds almost absurd: build a database engine compatible with SQLite version 3.40.1, from scratch, in a language you are told to use. The model receives SQLite's documentation and nothing else. According to the repository's README, there is no internet access, and every copy of SQLite must be removed from the environment first, including libraries and copies embedded in other programs, so the model cannot cheat by calling the real thing.

Grading uses database files as a shared interface, which is a clever way to compare implementations across very different languages. Each test starts with an initial database and a SQL query. The model's program runs the query and writes out a modified database. Then the real SQLite 3.40.1 runs a validation query on that output, and the test passes only if the result exactly matches the expected string. A crash, a wrong answer or a run longer than 60 seconds counts as a fail. If the model writes the solution in the wrong language, or mixes languages, the whole attempt scores zero.

The tests come from SQLite's own TCL test suite. Of roughly 51,000 tests, about 24,000 could be converted into this format. Because running all of them is expensive, the README says standard runs should use a subset of 272 tests. Scores are reported as a pair: API cost and test pass rate. That second dimension matters, because a model that is twice as accurate but ten times as expensive may not be the better choice for a real company.

How the models did, language by language

At maximum reasoning effort, GPT-6 Astra averaged an 87.4 percent pass rate across all 20 languages, compared with 26.8 percent for GPT-5.6 Sol. OpenAI says Astra improved in every language it tested and scored above 83 percent in 19 of the 20. COBOL remained the hardest, but the jump there was the most dramatic: from 10.9 percent to 72.1 percent. Fortran went from 21.4 to 83.5 percent, OCaml from 25.6 to 85.8 percent and Visual Basic from 27.5 to 89.4 percent.

GPT-6 Luna, OpenAI's cheaper model, sits in between. It averaged 40.3 percent, with COBOL at 17.1, OCaml at 34.1, Fortran at 31.4 and Visual Basic at 41.6 percent. That is far below Astra but still better than GPT-5.6 Sol in every language, and OpenAI puts its estimated average cost at 77 cents per sample, against 3.48 dollars for GPT-5.6 Sol. That is roughly 78 percent cheaper for better results. OpenAI did not publish a cost figure for Astra in the post.

What the results do not show

It is worth being precise about what these numbers mean, because they will get quoted loosely.

First, both evaluations were designed and run by OpenAI. That does not make them wrong, but it does mean nobody outside the company has checked the setup or the results. The MultiLangBench repository is public, so other labs and researchers can now run it themselves, which is a good sign. The COBOL migration test, as far as the post explains, is not public.

Second, SQLite is one of the most widely deployed and most documented pieces of software in the world, and its source code and tests are public. A model that has seen SQLite's C source during training may find it easier to rebuild the engine in another language than it would to build a truly unfamiliar system. The test hashes and the conversion step help, but contamination is a fair question for any benchmark built on famous open source code.

Third, a passing test suite is not the same as a safe production migration. OpenAI says this itself: applying these capabilities to real software "still requires expert review and testing against the system's business rules and dependencies." Real legacy systems are not single programs. They are webs of batch jobs, databases, job control scripts, screens and integrations, often running on mainframes, and the hardest part of a migration is usually understanding the whole system, not translating one file.

Fourth, the post compares OpenAI models only with other OpenAI models. There is no comparison with Anthropic, Google or open weight models, so it tells us how far OpenAI has come, not where it stands in the market.

Why OpenAI is talking about this now

Legacy modernization is one of the largest and least glamorous budgets in enterprise IT. Banks, insurers and governments spend heavily just to keep old systems running, and large migration projects have a history of running over time and over budget. Big consulting firms and mainframe vendors have been selling AI assisted modernization tools for a while, and other AI labs have pitched their models for this work too. A credible claim that a model can translate COBOL with near perfect behavioral accuracy is a direct pitch to some of the biggest customers in the world.

It also fits a broader pattern. AI coding tools started with autocomplete in popular languages, moved to whole features and agents, and are now moving into the corners of software that used to be considered too niche or too risky. OpenAI ends its post by asking developers to try the latest models on their own languages and report where they struggle, a sign that it wants real world data from exactly these enterprise users.

Dany's take

This is one of the most useful things an AI lab has published in a while, precisely because it is boring. Nobody gets excited about COBOL, but a lot of people get excited when their bank transfer goes through. A jump from 5 percent to 87 percent on a strict, all or nothing migration test is the difference between "a toy" and "a tool a team could actually use". I also like that OpenAI explains the fixed point rounding trap, because that is exactly the kind of quiet bug that makes these projects so dangerous. Still, I would wait for two things before calling it solved: independent runs of MultiLangBench by other labs, and real case studies from a bank or insurer that moved a production system with these models. Benchmarks are clean. Mainframes are not.

The bottom line

OpenAI says its newest models have gone from nearly useless to highly accurate at working in old and rare programming languages. GPT-6.1 Sol passed 86.6 percent of a strict COBOL migration test at low effort, up from 5.4 percent, and 97.9 percent with more reasoning. GPT-6 Astra passed 87.4 percent of tests on a new open benchmark that asks models to rebuild SQLite in 20 languages, and the cheaper GPT-6 Luna improved too while costing about 78 percent less than GPT-5.6 Sol. The results are self reported and the company itself says human review is still required, but if they hold up, the slow and expensive work of modernizing the software behind banks, cards and ATMs just got a serious new helper.