Coding agents can improve by changing the prompts, tools and code that guide their work. But finding which changes actually help and are worth preserving is challenging and expensive.
Each candidate change needs testing, and a search across many candidates can consume thousands of CPU hours and cost thousands of dollars.
Recursive Self-Improvement via Fast Tree Search (SIFT), a framework from researchers at MIT and Sakana AI, tries to cut that evaluation cost. It uses a separate language model to compare candidate agents before committing to expensive benchmark runs. It can also propose new changes while earlier candidates are still being evaluated. That lets the search explore several branches without waiting for a full test after every patch.
On the Polyglot coding benchmark, one SIFT run reached 35.1% accuracy in under five hours of wall-clock time, using 42 CPU hours and about $150 in API credits, according to the researchers.
For teams tuning coding-agent harnesses against well-defined tasks, SIFT suggests a way to spend expensive evaluations more selectively rather than running every candidate through the full test suite.
Every improvement needs a test
Engineers can tune a coding agent’s instructions, add tools or change how it responds to failures. But hand-tuning takes expert time and limits the search to ideas people think to try. Recursive self-improvement automates part of that process by allowing the system to modify its own source code.
In the self-improvement loop, an agent examines failures and proposes a patch to its harness. The revised agent attempts the target tasks, and its score helps determine which version becomes the starting point for another patch. Because a patch changes the system that will propose or execute later work, improvements can build on one another.
Earlier approaches manage this search in different ways. Darwin Gödel Machine (DGM) maintains an archive of agents and checks candidates on increasingly large task sets: first 10 tasks, then 50, with the full Polyglot benchmark held back for final evaluation. The Huxley-Gödel Machine (HGM) considers how an agent and its descendants perform when choosing where to search next. It varies the number of randomly sampled tasks used to evaluate candidates.
The main challenge is the cost of testing modifications to the agent harness. In the paper’s cost breakdown, proposing a patch costs about 12 cents. A pairwise judge call costs about 4.4 cents, and SIFT uses up to 10 per candidate, or up to roughly 44 cents. Evaluating an agent on 50 Polyglot tasks costs about $6 and 2.6 CPU hours.
Testing a candidate change on just a few tasks is cheap, but its score can be misleading: it may have drawn unusually easy or hard problems. Using a larger test set gives teams a better basis for deciding which version to improve next, but running those extra tasks costs time and money.
As the authors put it, the bottleneck is “the poor signal-to-cost trade-off of existing evaluation methods.”
How SIFT works
SIFT builds on DGM’s agent harness but inserts a cheaper source of feedback into the search. Its central bet is that a language model can compare two versions of an agent and judge which is likely to perform better, even before the new candidate completes a large benchmark run.
After SIFT generates a modified agent, it runs the new version on four coding tasks. This quick check catches changes that break the agent or leave it unable to solve basic problems, before the system spends more on comparing and testing it.
SIFT then asks an LLM-as-a-judge to make pairwise comparisons between the new agent and up to 10 high-ranking agents already in its archive. Comparing two implementations is closer to asking a hiring manager to choose between finalists than asking for an absolute score out of 100. The judge sees the agents’ code, not the benchmark tasks or their results.
SIFT combines those pairwise choices into a ranking using a Bradley–Terry model, a statistical method for estimating relative strength from wins and losses. The ranking does not replace testing. It helps decide where testing and further development are worth spending time.
The new candidate is then placed into a priority queue for the larger, time-consuming evaluation. Its priority combines the judge's ranking with its benchmark-accuracy ranking.
The workflow avoids making each patch wait for the previous one’s full evaluation. Patch generation, judging and benchmark evaluation can proceed in parallel. It’s comparable to a CI pipeline in which work continues while longer tests run in the background. Promising candidates can become the parents of new patches before their expensive evaluations finish.
When SIFT chooses a parent to improve, it weighs the judge’s ranking, the agent’s accuracy ranking on the search task set and how often that agent has already been selected. If the candidate is still waiting for evaluation, it temporarily inherits its parent’s accuracy. Counting past selections discourages the search from repeatedly backing one branch. It leaves room to explore alternatives that may turn out better after more changes.
In one of the tests on the Polyglot coding benchmark, a candidate called Node 9 added a short instruction to run tests after editing, along with a “test_runner” tool that returns structured failures. A later descendant added more machinery. Both agents solved 44% of the tasks in the smaller search test, so that test could not tell which would perform better on the broader benchmark. When evaluated across Polyglot, the simpler version scored 35.6%, compared with 33.8% for the more elaborate version built on top of it. The judge had already ranked the simpler Node 9 higher.
When the judge beats the search score
The researchers tested SIFT on Polyglot, TerminalBench 2.1, and a 60-task SWE-bench Verified subset. Their experiments included several coding models and LLM judges. They compared SIFT with DGM and HGM, measured improvement against each agent’s unmodified starting version, and ran SIFT without the LLM judge to see whether the judge made a difference.
On Polyglot, SIFT delivered better accuracy with less compute using both the open-weight Qwen3-Coder-30B and the closed o3-mini model. With Qwen3-Coder-30B, it slightly outscored HGM while using about a third fewer CPU hours. With o3-mini, it reached 35.1% accuracy, compared with DGM’s 30.7%. A SIFT run without the LLM judge scored 29.8%, suggesting that the judge helped drive the gain.
TerminalBench shows what the judge can catch when a small test gives a misleading signal. The judge’s top pick solved 18 of the 50 tasks used during the search, while the highest-scoring agent in that same search solved 19. But across repeated runs on the full benchmark, the judge’s pick averaged 36.7%, compared with 28.1% for the agent that scored 19 out of 50. The judge had spotted the problems from the code alone: that agent’s new verifier was disabled by default, and its rewritten shell tool posed a runtime risk.
Results on the SWE-bench subset also favored judge-guided selection, though less cleanly. The two judge-selected agents averaged 50.4% and 53.8% across four evaluations. The two top selections from the no-judge run averaged 44.6% and 50.4%. The starting agent scored 40.0%.
What teams can take from SIFT
The paper does not link to a standalone SIFT implementation, but developers do not necessarily have to recreate the entire self-improvement stack. SIFT is built on top of the DGM harness, so teams working with a DGM implementation already have much of the underlying loop: generate modifications to the agent, maintain an archive of candidate versions, and evaluate their performance. SIFT adds the pairwise judge and Bradley–Terry ranking, and makes the search asynchronous so candidates can be expanded while others are still being evaluated.
SIFT was only tested on coding agents, but the same basic approach could apply to other self-improving agents where there’s a clear way to measure whether a change worked. The first step is to define a small, cheap evaluation that can quickly reject obviously bad modifications. For an enterprise agent, this could be a small set of representative internal tasks that catches broken tools, regressions or changes that violate basic requirements.
The second piece is an LLM judge that compares candidate implementations pairwise. Rather than trying to predict an exact benchmark score, the judge only needs to provide a useful ordering of which version looks more promising.
Finally, the pipeline needs to be asynchronous. Candidate generation, judging and more expensive evaluations should run in parallel, so promising branches can continue expanding while previous candidates are still being tested. This is where much of SIFT's speedup comes from: the search tree keeps growing instead of waiting for every evaluation to finish.
Choosing the judge also creates room for optimization. The researchers found that a cheaper judge retained much of the global ranking signal on TerminalBench, although the stronger model was more reliable among the best candidates. They say a tiered setup could work, with the cheaper judge for most comparisons and a stronger one near the top of the ranking.
SIFT shows how the self-improvement loop itself can become more efficient by combining cheaper evaluation signals with asynchronous search. That lets teams explore more candidate improvements without scaling evaluation costs at the same rate. But downstream benchmarks are still needed to confirm that a change actually improved the agent, and the researchers had to block patches that loosened the evaluation harness.