Study: Overfitting and Extra Compute Eat 68% of the Gains from Harness Evolution

When a team automatically evolves a harness around a frozen LLM, metrics go up without a single weight update. A new paper from Hugging Face Daily Papers tests how much of that improvement is real. The authors introduce the Harness-Delta Attribution (HDA) protocol and run it on 11 executor models and three harness-evolution frameworks. The result is uncomfortable: in 21 configurations with a statistically significant gain on the search set, an average of 54% of the improvement comes from overfitting to benchmark artifacts, and another 14% comes from additional compute budget at inference.

What exactly HDA breaks down

A harness is everything that surrounds the model: system prompts, skill descriptions, the set of tools, and orchestration code. Evolutionary frameworks iteratively rewrite these components and keep the versions that perform better on the search set. The model weights stay fixed, so the approach looks like a cheap alternative to fine-tuning.

The problem is that a headline number like "went from 40 to 52" mixes several effects. HDA splits the gain into three parts:

• overfitting, meaning the gain from artifacts of the specific search set;
• the test-time scaling effect, where the evolved harness simply spends more tokens, attempts, or steps;
• the remainder, which the authors treat as an upper bound on the generalizable improvement.

The remainder does not prove that the improvement transfers. It is the maximum that could be left after subtracting the first two components.

The numbers across 21 configurations

The experiments cover math, coding, creative, and agentic tasks. The authors selected only cases where the gain on the search set is statistically significant. There were 21 of them.

• Averaged over these cases, overfitting explains 54% of the gain and test-time scaling explains 14%.
• In 14 of the 21 configurations, the combined share of the two factors exceeds 50%.
• Adding up the averages leaves roughly a third of the original gain as the remainder. This is an average, not a guarantee for any particular setup.
• The size of the remainder and the transfer to held-out tasks depend heavily on the task type, the model, and the framework.

A separate finding concerns validation. Signals based on a validation set do not prevent overfitting. A team that stops evolution at the best validation score can still end up with a harness tuned to its own benchmark. In addition, gains on the search set often do not transfer to held-out tasks. There is little data showing that they would survive a practical distribution shift.

How to evaluate harness evolution in practice

For teams building agents, the takeaway is down-to-earth. A report that says "the harness gave +12 points" with no breakdown tells you little on its own. You need to check at least three things. First, how the result behaves on truly held-out tasks that took part in neither the search nor the checkpoint selection. Second, how much compute the new harness spends per task, and what the baseline version delivers with the same budget. Third, how stable the result is when the task distribution shifts slightly, for example in phrasing, domains, or tools.

For researchers building evolution frameworks, the paper raises the bar: comparing on a single search-set metric no longer looks sufficient. Gain attribution becomes part of the methodology, like ablations in conventional machine learning.

There are limitations, too. The remainder in HDA is an upper bound, not a measured generalization ability, and the conclusions rest on 21 configurations. But the direction is clear. Until evaluation separates real agent improvement from overfitting and extra compute, claims that a harness can be improved automatically without updating weights deserve a discount of roughly two thirds of the gain.