Evidence · August 2026 · 4 min read

A benchmark just audited itself, and lost

OpenAI withdrew its own recommendation of a leading coding benchmark after finding roughly 30% of its tasks were broken. The finding is specific and checkable. What it implies about every other benchmark chart in a vendor's launch post is the part worth sitting with.

In July 2026, OpenAI did something a benchmark’s biggest booster rarely does: it published an audit of SWE-Bench Pro, the coding benchmark it had itself been steering the research community towards only five months earlier, and formally withdrew its recommendation. The finding was specific. Using model-based investigator agents alongside independent review from five experienced software engineers, OpenAI found that roughly 30% of the benchmark’s public tasks were broken: some contained hidden requirements or contradictory instructions, others graded correct solutions as failures because their tests enforced implementation details the task never specified, and still others could leak into training data simply by being public.

A benchmark is a test suite, and test suites decay

The specific failure mode is worth sitting with because it is mundane rather than exotic. SWE-Bench Pro’s tasks are harvested from real repository history, and the tests attached to them were written to validate one particular pull request, not to define an implementation-agnostic standard of correctness. A model that solves the underlying problem in a different, equally valid way still fails the test, and gets scored as if it could not code. That is not a flaw unique to this benchmark. It is what happens to any fixed test suite built from real-world artefacts once enough of the field starts optimising against it: the tasks that were once representative examples become a specific, gradually stale target, and the gap between “scores well on this suite” and “is actually good at this work” widens quietly until someone bothers to check.

The retraction is the unusual part, not the rot

Benchmarks decaying is not news. A lab that had recommended one, found it wanting on its own audit, and said so publicly with the method and the numbers attached, five months after recommending it, is the less common event, and it is worth crediting as such. It is also, on its own, evidence for exactly one benchmark. It does not tell an organisation whether the specific chart in this week’s launch post, from any lab, was built on a suite in similarly good or bad health. The honest reading of a retraction like this is not “ignore benchmarks”. It is “a benchmark score is a claim about a specific, ageing test suite, not a fact about the model”, and that claim has a shelf life a launch post never mentions.

What a serious buyer checks instead

The practical implication is not to distrust every number a lab publishes. It is to treat a vendor-chosen benchmark chart as the start of a question rather than the end of one: what tasks make up the suite, how old are they, has anyone audited whether the grading still matches genuine correctness, and, most usefully, how does the model perform against cases the buying organisation already trusts the answer to, rather than cases a lab selected to make its own model look good. The field is already fragmenting in response. Alongside SWE-Bench Pro, Cursor has used a proprietary internal benchmark, and Cognition and Databricks have introduced their own alternatives, which means the era of a single trusted leaderboard number is ending regardless of what any one benchmark does next. That makes an organisation’s own trusted test cases, not the newest chart, the more durable thing to build.

Written by Anthony Smith, Chief Technology Officer, Ballista.

Talking beats reading.

If a procurement decision is leaning on a benchmark chart from a launch post, describe the decision. We will help you work out what the chart actually establishes, and what it does not.

Your message goes to the people who would do the work.