Relace Search: An RL-Trained Subagent for Finding the Right Files

Watch a coding agent work on an unfamiliar repository and a surprising share of its turns go on looking around: list a directory, grep for a symbol, open a file, realise it is the wrong one, grep again. Each of those turns runs on your most expensive model and adds everything it read to a context that keeps growing.

Relace Search is a bet that this exploration phase should be handed to something smaller and faster. It is a code-specific search subagent that takes a natural-language request, explores the codebase with tools, and reports back a minimal set of relevant files. Relace introduced it in December 2025 under the name Fast Agentic Search; on OpenRouter it is listed as relace/relace-search.

How it searches

The harness gives the model five tools: view_file, view_directory, grep_search, bash and report_back. The distinctive behaviour is that it calls several of them in parallel on each turn, following multiple chains of files at once rather than one at a time. The catalogue description puts the typical spread at four to twelve parallel file views and greps.

When it has enough, it calls report_back with the files it thinks matter. Your main agent then starts its real work with those files in hand instead of discovering them itself. This is the delegation pattern covered in subagents and delegation: the subagent burns its own context on the search and returns only the conclusion.

Because the model is exposed through an OpenAI-compatible endpoint with tool calling, your own agent framework has to execute those tool calls against your files and return the results. It is not a hosted index you point at a repository, unless you use Relace's own Repos product, where a single repo.search call runs the whole loop for you.

Why parallelism was trained in, not prompted

The interesting part of Relace's write-up is the training. Its earlier models were built with supervised fine-tuning; this one used on-policy reinforcement learning, run on verl for about a day and a half on a single node of eight H200s, over three epochs of 3,200 examples.

The reward was an F-score, the harmonic mean of precision and recall over the reported files, combined with a penalty on the number of turns. The penalty does nothing up to four turns and decays linearly to zero at 24. That is a direct instruction to the model: find the right files, and do it in few rounds, which in practice means doing more per round.

Relace reports that this cut the number of turns from 20 to 5 on one of its evaluation sets and from 10 to 4 on the other. It is a useful example of shaping latency through the reward rather than through a system prompt asking the model to be quick, which rarely works.

What it saves, honestly stated

Relace claims more than a 4x reduction in end-to-end search latency with accuracy similar to Claude 4.5 Sonnet on its held-out sets. The write-up does not give those accuracy figures in its text, so treat the claim as directional.

The more informative number is the SWE-bench Verified run, where the search model acted as a subagent for a stronger agent:

• With the search subagent: 7 minutes 1 second median latency, 71.4% accuracy, 890M total tokens.
• Without it: 7 minutes 44 seconds, 72.0% accuracy, 1.03B total tokens.

That is a 9.3% latency reduction and 13.6% fewer tokens, at a cost of 0.6 points of accuracy. Modest, and Relace explains why: search is only about 12% of total tokens in SWE-bench traces, where problem statements often name the relevant files, against nearly 60% in the real-world coding traces it looked at. That suggests the saving would be larger in an interactive setting. It is also a reminder that delegation is not free. A subagent that misses a file the main agent would have found costs you correctness, and that small accuracy dip is what it looks like.

Cost and where it fits

Relace prices the model at $1 per million input tokens and $3 per million output, and OpenRouter listed the same figures at the time of writing. Search is input-heavy, since the model reads file contents and grep output, so the input price dominates. Compare that with what the same exploration costs at your main model's input rate; cost per agent run explains why input is usually the bigger line on an agent bill.

It sits naturally at the front of a pipeline: search finds the files, a frontier model decides on the change, and an apply model such as Relace Apply 3 merges the edit. The three pieces are independent. You can use the search model with any planner, and you can skip it entirely on small repositories where the main agent would find the right file in one grep anyway.

It is not a replacement for an index. On a very large monorepo, an embeddings or symbol index can narrow the space before any model runs, and building a code search tool covers that side. An agentic searcher is strongest when the question is semantic, such as where a behaviour is implemented, rather than a lookup an index answers instantly.

A test worth running

1. Take 30 resolved tickets from your tracker and note which files each fix touched.
2. Give the search model the ticket text and score the files it reports against the real ones: precision and recall, separately.
3. Run your main agent with and without the search step and compare turns, tokens and pass rate.
4. Look at the misses. If they cluster in generated code, config or files reached only through dynamic imports, your tool results may need to expose more.

OpenRouter lists a single variant, so record the date of your run. Keep the subagent if recall is high and the main agent gets measurably cheaper; drop it if the misses are costing you more retries than the search saves.