--- title: "WarpGrep v2: #1 on SWE-Bench Pro" url: "https://www.morphllm.com/blog/warpgrep-v2" description: "WarpGrep v2 is an RL-trained parallel search subagent that lifts every major coding model to #1 on SWE-Bench Pro. 15.6% cheaper, 28% faster, and now handling multi-repo, package, and log search." date: "2026-02-23" author: "Tejas Bhakta" --- # WarpGrep v2: #1 on SWE-Bench Pro
WarpGrep v2: 15.6% cheaper, 28% faster, #1 on SWE-Bench Pro
## What WarpGrep is for Code search is a messy job to hand a language model. Point a frontier model at a big repo and ask it to find something, and by the time it gets there it has stuffed its context full of files it read on the way and didn't need. A sub-agent is the obvious fix, but it opens two questions. Should that sub-agent be a general model like Opus, or something specialized for code search? And if it's specialized, does it run the same harness the main model uses, or a faster, much more parallel one built for the job? WarpGrep is our answer. A code search model in a very parallel harness, one that can hand back the results of up to 36 tool calls in under five seconds. ## The problem Search is the bottleneck for coding agents. [We went through 15 papers](/blog/code-search-bottleneck) making that case: agents spend north of 60% of their time just retrieving context, and the results they pile up on the way [rot their performance](https://research.trychroma.com/context-rot) as the context grows. WarpGrep v1 was our first pass at this, an RL-trained search model that lives in its own context window and finds the right files in 3.8 steps so your coding model never has to go looking. v2 is a much bigger step. It's the first search subagent that lifts nearly every major model to **#1 on [SWE-Bench Pro](https://www.swebench.com/)**, and that benchmark scores agents on production-scale repositories, not toys. ## Results SWE-Bench Pro is long-context, multi-file work pulled out of real open source projects, which is where a search subagent should either earn its keep or get in the way. We paired v2 with a few different coding models and watched the scores move: | Model | Without WarpGrep | With WarpGrep v2 | Delta | |-------|:-:|:-:|:-:| | **Opus 4.6** | 55.4% | **57.5%** | +2.1 | | **Codex 5.3 (CLI)** | 56.0% | **59.1%** | +3.1 | | **MiniMax 2.5** | 55.4% | **57.6%** | +3.7 | Every model we tried came out ahead, and every pairing landed at the top of the board. No single row is dramatic on its own. What convinced me it wasn't noise was the consistency: whichever coding model we bolted it onto, the number went up. The part I had to double-check before publishing was cost. Pairing Opus 4.6 with WarpGrep on SWE-Bench Pro tasks comes out **15.6% cheaper**, $2.51 a task against $3.06, and **28% faster** too, 445 seconds against 618, which is 173 seconds handed back on every task. On paper, adding a second model to a pipeline should cost you money and time. This saves both, and the mechanism is mundane once you see it: WarpGrep does the searching on cheap tokens, so the expensive model never spends its budget wandering the repo, and with less junk read there's less for it to generate and it's done sooner. ## Why a subagent at all The idea underneath WarpGrep is not complicated. When Opus needs to find the Stripe webhook handler in a large codebase, it can go hunting on its own: grep "webhook", open a file, land in a test fixture, open a few more, double back. It gets there eventually, six files deep, four of them irrelevant, and the tokens those four cost aren't even the real damage. The real damage comes later, when the [leftover junk pulls Opus's attention off](https://arxiv.org/abs/2307.03172) the two files that actually held the answer. Or it hands the hunt to WarpGrep, which makes that same mess inside an isolated window where the mess can't hurt anyone, drops the dead ends on the floor, and walks back with the handler file and exact line ranges. Opus's window ends up holding what it asked for and nothing else. Anthropic's multi-agent research system [beat single-agent Opus by 90%](https://www.anthropic.com/engineering/multi-agent-research-system) on the same underlying principle, and it wasn't that their subagents were somehow smarter than Opus. The lead agent's context stayed clean. That's the entire trick. ## Why a specialized model You could run more or less any model as the search subagent, and we tried the obvious ones: Haiku, Sonnet, GPT-4o-mini. A specialized model wins on parallelism, and on what parallelism costs to train for. Picture a single query: WarpGrep can throw as many as 8 tool calls at it in one turn and keep going for 4 turns, which is 32 guesses about where the code lives all live at once. It flings them wide to start. Then it reads what came back and reels in the threads that caught something. Training a general model to do that well is a fight. RL on natively parallel trajectories eats away at the plain sequential rhythm, grep, read, grep again, that ordinary coding runs on. You give up some breadth to get the parallel-search skill. For a coding model that's a bad swap. For a subagent that does nothing but search, it's the right one. The reward we trained against is almost embarrassing to write down: weighted F1 on file and line-range retrieval, with beta at 0.5 so precision counts slightly more than recall. There is nothing in that objective about being clever, and we didn't hand-code a single one of the behaviors people ask us about when they watch v2 work. The behaviors showed up on their own because they paid. Somewhere along the run the model started grepping into `node_modules/` and `site-packages/` whenever it concluded the answer wasn't in application code, which nobody suggested to it and which happens to be exactly what a senior engineer does when a stack trace dead-ends. It learned to chase an import to its source and then one hop past it to the real implementation. It even learned to quit early on easy queries instead of spending its whole 4-turn budget, which is where a decent slice of the latency savings comes from. (Someone will email me that these aren't really emergent, just well-shaped credit assignment, and they'll have a point.) ## Beyond one repo Where v1 stayed inside one codebase, v2 crossed a few borders. Multi-repo search came first, mostly because customers kept hitting the same wall we did: the frontend calls an API, the API leans on a shared library, the library wraps an internal SDK, and the answer to "where does this field actually get set" lives two repos away from wherever anyone is looking. v2 chases that whole chain in a single invocation. Package search got promoted from accident to feature. Training produced the `node_modules/` habit on its own, and after we watched it pull an answer out of a framework's middleware chain during an eval, keeping the behavior out of production stopped making sense. Your bug lives inside somebody else's SDK more often than anyone likes to admit. Logs were the third border, and the one I didn't see coming. A big share of production debugging never touches source at all, it's error output and stack traces and whatever the deploy printed on its way down, so v2 aims the same wide-parallel strategy at those: grep patterns, timestamp filters, structured field extraction, all in flight together. ## What a single search actually looks like The flow is simple. Your coding model, whichever one you're running, decides it needs context and delegates to WarpGrep v2 with a natural-language query. WarpGrep spins up in its own context window, fires 8 parallel tool calls per turn across up to 4 turns, and returns `(file, [start_line, end_line])` spans, only the relevant code. Your coding model gets clean, precise context and keeps going. The coding model never sees the search happen. It never sees the files WarpGrep looked at and rejected. Its context window holds only what matters. WarpGrep v2 runs at around 2,500 tokens a second, so a typical search finishes in under 4 seconds. The whole search costs a fraction of what the main model would spend doing that work itself, which is exactly why bolting on a second model makes the system faster and cheaper rather than slower. ## The broader point Search subagents might be one of the first lasting primitives in agent infrastructure. I don't mean a framework feature or a prompting trick. I mean a real architectural pattern, one that falls out of a hard constraint: models take a steep performance hit past roughly 100k tokens, and every coding CLI already compacts context aggressively to stay under that wall. Bigger context windows aren't the fix. What works is pulling search out into a dedicated context that does the dirty work and hands back only the signal. WarpGrep v2 is that isolation layer. It's live now as an API and built into [Morph's agent infrastructure](/products/warpgrep). --- **Try it:** [WarpGrep v2 API](/products/warpgrep) | [Read the v1 training post](/blog/fast-context-rl-retrieval) | [Research survey: why search is the bottleneck](/blog/code-search-bottleneck)