Don't Retrain the Model, Harness It

Researchers affiliated with Chinese and British institutions report improving AI agents while cutting their running costs by revising the software around their models, rather than retraining them. ^[1]

Their system, HarnessPro, repeatedly examines an agent's previous attempts, proposes changes to how it works and tests those changes. In experiments using GPT-5.5 with Codex, its most intensive version raised average task pass rates by 2.0 percentage points while reducing average cost per task by 26.1%, compared with a method called RHO. These are the authors' own experimental results, not independently replicated findings. ^[1]

That is an attractive combination: more tasks completed successfully for less money spent on each attempt. It also points to a competitive opening. Improving an AI product need not always begin with building a better underlying model. There is useful work to do in the software that tells an existing model what to see, which tools to use and when to check its answer.

HarnessPro's authors are affiliated with Tsinghua University, Z.AI, Shanghai Jiao Tong University, the University of Warwick and Kling AI. Version two of their paper is dated October 20, 2026. It describes a concrete engineering approach to recursive self-improvement, where an automated process revises part of a system and then repeats the process on the revised version. ^[1]

Software around a fixed model produced measurable, promising gains on the tested benchmarks. ^[1] That makes it commercially interesting even before anyone earns the right to call it a breakthrough.

The model stays put, the workflow changes

A model's weights are the learned numerical parameters produced by training. They define the underlying model. A harness is the surrounding software that manages its interaction with the world: instructions, tools, memory, the handling of information and rules for checking work. HarnessPro targets that surrounding layer. ^[1]

Consider the choices involved in an agent's attempt to complete a task. How much reasoning should it spend before using a tool? How much of a tool's response should it retain? When should it stop working and check the result?

HarnessPro's revisions include allocating reasoning and tool budgets by task, changing execution control, compressing tool output and shortening instructions while retaining context and final checks. ^[1]

These are consequential choices. Giving a model more information is not automatically useful if the relevant detail becomes harder to find. More tool calls are not automatically productive if they repeat work. An agent's workflow can spend resources badly even when the model inside it is capable.

HarnessPro uses records of past attempts to identify opportunities for revision. Specialized agents propose and implement changes, candidate harnesses face fixed tests generated by a language model, and selected versions proceed to another round. The object being improved is the agent's operating setup. ^[1]

The authors offer lite, medium and heavy versions to serve different cost and performance priorities. That is a useful acknowledgement that the best workflow depends on what a user values. A system built to maximize successful completions may make different choices from one built to keep each attempt cheap. ^[1]

The commercial opportunity lies in making those choices well. A better model can still be wasted by a bad workflow.

What the numbers buy

The study evaluates HarnessPro on three benchmarks, Terminal-Bench 2, SWE-Bench Pro and ProgramBench. It uses two model-and-tool combinations: GPT-5.5 with Codex, and GLM-5.2 with Claude Code. ^[1]

As a scale comparison, the average two-percentage-point gain means two additional successful attempts per 100 tasks. The authors say the advantage over RHO also held with GLM-5.2 and Claude Code. ^[1]

The most striking reported result comes from Terminal-Bench 2. There, the heavy version improved the pass rate by 4.5 percentage points while reducing mean cost per task by 33.9%. ^[1]

A reduction of roughly a third in running cost would matter for an agent used repeatedly. Small improvements to each attempt can become valuable when the same workflow is run many times. The attraction is especially strong when savings arrive alongside a higher success rate, rather than being purchased by accepting more failures.

The measured savings concern execution cost per task, not the total expense of developing and evolving the harness. The study does not provide a direct cost or speed comparison with retraining, or demonstrate general autonomous improvement of the underlying model. ^[1]

The case for harness engineering as a cheaper, faster route than retraining is therefore an economic argument, not a result this paper has proved. It targets software and workflow rather than a new model-training run. Whether that makes it cheaper overall depends on how much the search for a good harness costs and how often the resulting system is used.

A costly search can still pay for itself over enough tasks. A modest running-cost saving can also disappear into development expense. Buyers need both sides of that calculation.

A different opening for competitors

Harness improvement could change who gets to compete. If a developer can improve an agent while holding its model fixed, ownership of a leading model becomes a less complete measure of that developer's prospects.

That does not make access to strong models irrelevant. Both model-and-tool combinations in the study are specific systems, and the reported results belong to those tested combinations. ^[1] The opportunity is to compete through how well a model is deployed, alongside competition over the model itself.

The practical implication is a broader role for teams good at tools, testing and workflow design. A company might distinguish its agent through disciplined information handling or better decisions about when to verify work. The capability a customer experiences comes from the whole system.

HarnessPro also offers a way to automate some of that engineering. Its loop does more than ask people to write better instructions. It assigns agents to propose and implement changes, tests the candidates and carries selected versions forward. ^[1]

The strongest objection is that this may amount to benchmark-specific tuning. A workflow can improve on familiar tasks without becoming useful across unfamiliar ones. Automated revision makes the search faster or more extensive only if its tests reward the right changes.

That objection does not erase the reported gains. It determines how much those gains are worth outside the experiment.

The tests must earn the claim

HarnessPro's authors separate benchmark tasks into training, validation and test sets, reserving the test set for evaluation after harness evolution. They also say the candidate-selection tests use neither answer keys showing the correct solution to each task, known as ground-truth solutions, nor official tests. ^[1]

Holding tasks back until the end is an important discipline. It helps distinguish a system that performs well during its own revision process from one that succeeds on tasks excluded from that process.

The next test should be independent reproduction with the same models, tools and settings. Researchers should then vary the task mix and the model-generated tests used to select candidate harnesses. If small changes in the evaluator erase the advantage, the improvement is fragile.

The economics deserve the same treatment. A useful evaluation should show the resources spent generating revisions, the costs of unsuccessful candidates and the running costs of the selected harness. It should report variation across runs, so a buyer can judge whether an average gain is dependable.

Verification also needs explicit protection. When a system searches for cheaper execution, evaluators should check that it has not won by weakening checks or taking unacceptable shortcuts with tools. A lower bill is a poor bargain if it buys less dependable work.

HarnessPro makes a credible case for treating the agent's surrounding software as a major engineering target. Its next milestone should be an independently reproduced gain on tasks kept back from the revision process, following the separation used in this study, with the full cost of producing that gain included. That is the evidence needed to turn an appealing experiment into a purchasing decision.