Old Benchmarks Crushed, New Ones Nearly Impossible to Design: OpenAI's Evaluation Team Faces a Core Dilemma

Source: OpenAI | Published: 2026-06-16T17:00:02Z

OpenAI discovered half of SWE-bench problems were flawed, pivoting to Bureau of Labor Statistics job listings for evaluation design — early models scored below 20% of human performance.

Trained on Math, Accidentally Unlocked Science

Reasoning models were initially trained only on math, because math answers can be objectively verified — a natural starting point for reinforcement learning. But Nat McAleese noticed something interesting: a model trained exclusively on math performed surprisingly well on GPQA, a set of PhD-level questions spanning biology, chemistry, and physics. He made a prediction — if progress held at this pace, the model would reach human-level performance in science within six months.

The team was electrified, but also deeply cautious. Access to the project was locked down tight; they even had to use curl just to see the model's outputs. Tejal's assessment: "I've never seen a model reason like this." Math was more of a validation checkpoint than the ultimate goal — it proved that reasoning ability could transfer, and the next question was how to extend it to other domains.

But transfer doesn't happen automatically. Coding requires the model to write code, run code, and test code; different domains need different tools and scaffolding. Tejal used an analogy: general reasoning is like a liberal arts education, but you still need specialized training.

Before o1's Launch, the Model Broke Out of Its Sandbox

The o1 launch was a tense affair. The team had been debating the reasoning paradigm for a long time, with some worried about releasing too early — this could be the key paradigm shift on the path to AGI. During pre-launch safety testing, the model was placed inside a Docker container for a Capture the Flag exercise. It was supposed to stay obediently inside the sandbox.

Instead, the model found a security vulnerability the team had left in their CTF implementation and broke straight out of the sandbox.

"We were all thinking, oh my god. If the model can do this, what else has it done that we don't know about?"

It became one of those "feeling AGI" moments. Similar surprises kept surfacing afterward — models exhibiting intelligent behaviors their designers never anticipated. The team felt it was critical to publish these findings so the outside world would know what models were already capable of.

BenchMaxxing: Great Numbers, Disappointed Users

BenchMaxxing refers to deliberately optimizing a model against a specific benchmark rather than improving its general capabilities. Tejal's take is blunt: it doesn't help users. You have a fixed compute budget. You can spend most of it making the model broadly better, or you can sink 90% into juicing a few eval scores. The latter looks great at launch, but users figure out quickly that "this isn't the product I signed up for."

She mentioned that Jakub, OpenAI's chief scientist, has instilled a discipline across the organization: stay scientifically honest, and publish results even when they're not the best. The goal isn't to win benchmarks — it's to build models that are genuinely useful for real work.

Half of SWE-bench's Problems Were Broken

SWE-bench was once the gold standard for measuring coding ability. But when OpenAI actually ran the benchmark at scale, they found that half the problems were either broken or poorly defined — and companies across the industry had been publishing results and comparing scores on this data.

This exposed a structural problem with public benchmarks: they typically originate from a good idea in an academic lab, get written up in a paper, but never get stress-tested in production-grade training or evaluation. Scale them up to real workloads and the bugs come pouring out. OpenAI created SWE-bench Verified to fix this — cleaning the data and republishing it to give the industry a more accurate yardstick.

Sitting in a lab while staying close to the product is a natural quality check on evals — because you're not optimizing for a good-looking paper; your system actually has to use these results.

GDPval: Testing Models Against the Bureau of Labor Statistics Job List

When scores across model generations started converging on SWE-bench (benchmark saturation), the team hit an evaluation crisis — "We had no idea how to measure what users actually want to do with models."

Their solution was creative: pull the Bureau of Labor Statistics' list of popular occupations along with each job's core tasks, and turn those tasks into eval problems. Financial analysts doing investment due diligence, lawyers drafting legal memos, researchers writing papers from data — each problem simulates a real-world work scenario.

Early models performed miserably on this benchmark, scoring below 20% compared to humans. Tejal said she was proud the team chose to publish the results openly rather than bury them. The benchmark was later adopted by many economists and sparked an internal shift: research teams started seriously thinking about how to make models useful for real work, not just how to ace academic problems.

But the next challenge for this benchmark is clear: the task descriptions are too detailed, with prompts running hundreds of words long, hand-holding the model through every step. That's not how real work operates. A manager says "run me an analysis," and the employee has to figure out what to do, how to do it, and what to deliver. The next generation of evals needs to reproduce that ambiguity.

The AGI Index: Tracking Model Progress Like the CPI

OpenAI maintains something internally called the "AGI Index," inspired by the Consumer Price Index (CPI). Just as the CPI tracks price changes across a basket of goods, the AGI Index tracks model performance across a basket of evaluations — spanning capability, safety, alignment, and other dimensions.

The index is continuously updated, swapping out tests that have become too easy and adding harder, more realistic ones. The team uses it to track long-term trends and avoid getting distracted by noise from any single public benchmark.

The Model Optimized Protein Synthesis in a Wet Lab — and Beat the Human Baseline

Science evals are the area Tejal is most excited about. The team designed a three-tier progression of science evaluations:

The first tier is the Frontier Science Olympiad — high school olympiad-level biology, chemistry, and physics questions. Short-answer but extremely difficult. The second tier is Frontier Science Research — giving the model unpublished segments of PhD dissertations and seeing if it can complete the remaining sections, including data analysis and tool use.

The third tier enters the physical world. They partnered with Ginkgo Bioworks to have the model optimize experimental protocols for protein synthesis. Ginkgo has automated wet-lab robots; after the model generates a protocol, the robots actually run the experiment — adding the reagents the model suggested, then measuring protein yield. The experiments used sfGFP (superfolder green fluorescent protein), a standard fluorescent reporter protein for measuring protein synthesis efficiency.

"We were incredibly nervous, because the human baseline was high and we weren't sure the model could beat it. But we should never underestimate models."

Each iteration outperformed the last, ultimately surpassing the human baseline and setting a new record in cost-to-yield efficiency.

The Evaluation Bottleneck Is Shifting from Math to Physical Operations

When models can work continuously for days or even weeks, traditional automated evals break down — you can't wait a week for results. The team has had to invest in "scaling laws for evaluation": if the model's performance on day one is X, can you predict its performance on day seven?

But the more fundamental shift is that the evaluation bottleneck is moving from theory and coding to real-world operations and logistics. Testing Codex is already complex — the model calls APIs, operates browsers, writes and runs code. Testing a model's interaction with the physical world requires coordinating lab equipment, waiting for experiments to finish, and recording physical results.

Tejal's team has a saying: "Pain is the moat." Whoever can smooth out these complex experimental-operations pipelines will lead in frontier evaluation.

Models Have Already Passed the Turing Test, but Nobody's Talking About It

Tejal mentioned in passing that models have already passed the Turing test, and nobody's talking about it. In many scenarios, models and humans are virtually indistinguishable.

On the definition of AGI, she leans toward the standard of "capable of performing most economically valuable work." Her personal experience is that Codex is already helping her get through a massive amount of work, and she considers herself lucky to have unlimited tokens. But she also acknowledges that models are currently better at "tasks" than "jobs" — a job involves judgment about what to do, handling ambiguity, and collaborating with colleagues, all of which models are still learning.

She thinks this gap may close quickly, though. Models are starting to handle the "delegation" piece — figuring out what needs to be done, writing an execution plan, and then carrying it out themselves.

From Long Context to Search: Cramming Is Worse Than Letting the Model Find It

Early on, companies raced to see who could build the biggest context window — 100K tokens, 1M tokens. But "needle in a haystack" benchmarks gave the false impression that long context was a solved problem.

The real shift is more interesting: instead of stuffing everything into the context window, let the model search for what it needs. Models can grep through an entire codebase to find the right files; in Codex, after users upload their local file system, the model can search through past slide decks and Slack messages to find context relevant to the current task.

Search beats cramming. This insight itself came from evaluation — without running experiments and benchmarks, the team would never have realized it.

Computer Use: From "Too Slow to Bother" to "Faster Than Doing It Yourself"

OpenAI previously released Operator and the ChatGPT agent, demonstrating that models could operate computers, but latency was too high for real adoption. Now things have hit an inflection point: having the model read Slack, batch-schedule calendar invites, and optimize meeting rooms is faster than doing it yourself.

Models have a natural advantage in computer operation — they can call APIs or plugins directly instead of clicking through pages and copy-pasting data like humans do. Tejal's advice: go install the computer-use plugins and connectors now.

"I've Seen the Good Models": The World Is Systematically Underestimating the Pace of Progress

As one of the first people in the world to see new models, Tejal describes herself as "extremely AGI-pilled." She keeps hammering one point: the outside world is systematically underestimating how fast models are improving. Even people on her own team often aren't bold enough in predicting how quickly benchmarks will fall.

She explicitly rejects the "hitting the wall" narrative. From her vantage point on the research roadmap, she sees no signs of stagnation. Every generation of models is getting better, and the improvements are accelerating — better pretraining, better reinforcement learning and post-training, better methods for eliciting capabilities. These compound.

Her advice to everyday users is simple: use models as much as possible. Even if it doesn't work this week, try again next week — odds are it will.