Benchmaxxing happens because benchmark scores can diverge from human judgment and real-world value.
2
Broken tasks, contamination, weak verifiers, and reward hacking can make a benchmark reward the wrong behavior.
3
Better benchmarks need domain experts, realistic data and tools, aligned verifiers, private holdouts, and expensive human evaluation.
Summary
Nick Heiner argues that the word "benchmaxxing" exists because benchmark scores often stop tracking what people want from models. Popular benchmarks can spread through marketing and incumbency even when industry insiders know they are easy to game. He describes several failure modes: tasks that are too expensive to create well, test contamination, reward hacking, contradictory prompts, brittle string-match verifiers, synthetic data, and poor quality control. These flaws can make two very different model behaviors receive the same score, or allow a model to score highly without completing the requested task. Heiner says benchmark creators should start with strong domain experts, use realistic inputs and working tools, align prompts with verifiers, and keep private holdout data. Human evaluation remains the target, especially for writing, although it is expensive. His example, Hemingway Bench, uses professional writers to compare model outputs blindly.
Benchmaxxing exists because benchmark scores can miss real-world value
Heiner defines benchmaxxing as training too hard on benchmarks in ways that depart from what users care about. A model launch brings benchmark charts, and later real users may find that the advertised performance does not match reality. He says the existence of the term itself shows that people know benchmarks do not always equal reality. The causes are incentives and poor methodology. Heiner still believes it is possible to identify better models, but only by examining how a benchmark was made rather than accepting its popularity or headline score.
Popularity turns weak benchmarks into an avalanche of borrowed credibility
Heiner points to LMArena as an example of a popular benchmark that can receive attention despite criticism that it is easy to game. Andrej Karpathy observed that models he considered best did not match LMArena's rankings, suggesting that teams were producing better LMArena models rather than better models overall. Most people need a simple way to compare models, but many cannot judge whether an evaluation is sound. They can judge whether it is popular. That creates feedback from incumbency, marketing, and repeated discussion, while real-world value receives less attention.
Benchmark tasks are expensive to create, so shortcuts can damage them
A serious agentic coding benchmark with 1,000 tasks could require each task to take 60 hours to make. Using Heiner's workforce cost example, that would cost $15 million, and replacing roughly a third of the tasks as models improve would cost another $5 million each year. Those costs encourage workarounds, including excessive AI assistance and cheap labor. Heiner says frontier work needs expertise from outside the model frontier, and cheap labor produces results of the quality paid for. At Surge AI, he says, the stated priority is quality rather than minimizing labor costs.
Contamination means a benchmark can measure memorization instead of capability
Heiner says contamination is not limited to a lab deliberately training on a test set. Public questions and answers are likely to be memorized to some degree, making contamination the default unless a benchmark creator is unusually careful. He describes an investigation of SWE-bench Verified repositories that found clear evidence that Opus had memorized much of the benchmark content relative to the rest of the repositories. Heiner says Opus 4.8's model card reported its SWE score without disclosing this contamination, leaving benchmark users without information needed to interpret the result.
A weak verifier can give the same score to opposite behaviors
Reward hacking happens when a model finds a cheap way to satisfy the letter of a reward rule while missing its purpose. Heiner compares gradient descent to water flowing downhill toward the easiest path, so verifiers must be designed against a maximally lazy agent. In AutomationBench, hard-coded string matches can reject valid phone-number formats that differ from the verifier's chosen format. Heiner gives the example of Haiku and Fable both scoring 20 percent, even though one made many mistakes and the other was correct 80 percent of the time but used different formats. A task that cannot distinguish those behaviors is not useful.
Contradictory prompts and incomplete checks make perfect scores meaningless
Heiner describes prompts in an instruction-following evaluation that cannot be satisfied as written. One asks for a response to be repeated verbatim and translated into Hindi; another asks for exactly one bullet point while also requesting several bullet points. Other prompts ask for a story while the verifier checks only whether the ASCII letter "i" appears no more than once. A model can receive full credit by using a Cyrillic character that looks like "i" instead. Heiner also describes files whose contents conflict with their grading rubrics, synthetic placeholders, and nonexistent dates that make models learn the shape of an evaluation rather than handle real data.
Human judgment is the target, but benchmark scores can keep rising after it stops
Heiner says the goal of AI evaluation is human evaluation because AI exists to serve humans. Automated benchmarks try to compress human preferences into a cheaper, scalable measure, but the compression can lose what people actually value. A model may continue climbing a benchmark while human ratings stay flat, or even fall. He shows an example where the prompt asks for the time and the response is bizarre, yet LMArena places it at the top of its leaderboard. He also describes reports of crowdsourced voting and model watermarks being used to influence LMArena votes.
Good benchmarks need domain experts and alignment at every layer
Heiner says expert input should determine the tasks, success criteria, input files, and tools. A medical benchmark also needs people who understand regulation, legal requirements, and hospital operations, not only doctors who can answer medical questions. Inputs should come from real-world data and tools should work unless buggy tools are the subject of the test. Prompts and verifiers need two-way alignment: every requested behavior must be checked, and every checked behavior must be requested. Benchmark creators should perform thorough quality control and keep a private holdout set to reduce contamination.
Writing quality requires professional human evaluators
For Surge AI's Hemingway Bench, Heiner rejects mechanical scoring and language-model judging as inadequate for writing, which he describes as rich, nuanced, and deeply human. He says language models do not have good taste in writing. The benchmark instead uses thousands of professional writers across roles such as technical writers, poets, journalists, and editors. They make blind comparisons between model outputs, which produces a leaderboard based on direct human judgments. He is explicit that this costs a lot, but says the aim is to maximize quality rather than minimize cost.
"Benchmaxing, of course, being when labs are training too hard on benchmarks in a way that deviates from what people actually care about."00:36
Who should watch
You build or review model benchmarks and need concrete ways to find broken tasks, contamination, and verifier failures.
Your team uses benchmark leaderboards to choose models and needs to understand what a score may be measuring.
You work on human evaluation, data quality, or agent testing and want Heiner's standard for realistic benchmark design.
