ripwire Hands Coding Agents a Repo Map Instead of grep. Its Most Convincing Number Is the One That Got Worse.

The "ripgrep of AI context" re-ran its own head-to-head and cut its published lead from 1.75x to 1.46x. That correction is the reason to take the rest of it seriously.

Somewhere in ripwire's README, under a collapsed section most readers will never open, the project explains that it re-ran its own competitor benchmark and the result was worse for ripwire. The runner-up tool it had credited with 26.7% turned out to score 40.0% when scored fairly against the current binary. Two other competitors climbed too. The published margin over the best competitor dropped from 1.75x to 1.46x, and the README says why in plain language: the old framing flattered us by comparing today's ripwire against year-old competitor runs.

That paragraph is doing more work than the 52x speed number at the top of the page.

ripwire showed up at #13 on Trendshift's daily board this morning with 1,604 stars, v0.5.0 tagged September 7, and a repository that did not exist before July 29. The pitch is one line: point it at any repository and your agent gets a ranked, deterministic call graph, what to touch, what it breaks, which tests to run, instead of grepping around and reading whole files. Whether you should install it is a question worth working through, because the answer depends almost entirely on what language your code is in and how you plan to invoke it.

What it actually does

The mechanism is not retrieval-augmented generation and there is no vector store involved. ripwire is a single self-contained C++23 binary with no runtime dependencies, no API key, no embeddings, no index server, and no daemon. It parses the tree, builds a call graph, ranks it, and prints structured output. Everything happens locally in one process.

The verbs are where the design shows. ripwire . --for="the change you are about to make, in words" orients an agent on a task. --callers=SYM answers who calls this. --impact=SYM and --uses=SYM answer whether it is safe to change. --from-trace=FILE takes a stack trace and resolves the frames. --situ looks at your working diff and names the tests that cover the blast radius. --pr-context=REF sets up a review.

The token table is the sales pitch and it is measured on ripwire's own repository, dated 2026-08-08, with tokens estimated as bytes divided by four. --callers costs about 580 tokens against 40K to 52K for grep-then-open-three-files. --from-trace costs about 1.4K against 124K to 298K. --situ costs about 410 tokens against a range topping out at 132K. Orientation, the ripwire . case, is the least impressive row at 3.6x to 4.5x.

Notice the shape of that. The savings are enormous on the narrow, graph-shaped questions and modest on the broad ones. That is not a flaw in the tool, it is the tool telling you where it belongs.

The counterexamples it publishes against itself

Most projects that lead with a self-run benchmark bury the losses. ripwire prints them.

On a small file, pageRankDouble in src/pagerank.cpp at 5,559 bytes, the ranked neighborhood bundle would cost 27,916 bytes, roughly five times more than just reading the file. So ripwire serves the file instead and marks the response mode="whole-file" rather than silently doing the expensive thing. The docs list that alongside its other published counterexamples.

In the head-to-head round dated 2026-08-06, ripwire records paired losses: two instances to codebase-memory-mcp, two to repowise, one each to graphify and aider. It notes that two competitors, Vexp and CodeIndexer, were excluded rather than beaten, because their free tiers cap nodes, projects or chunks in ways that make a fair 60-instance sweep impossible. It records that an independent adversarial pass attacked the design of an earlier comparison and that the findings ship alongside that report.

And it names an open failure it has not fixed. On multi-file gold, where a change touches several files, ripwire scores 21.4% strict against its own 78.6% any@10. It finds one of the right files and misses the siblings. The README works through why: if each gold file were an independent draw at the single-file rate of 90.6%, multi-file would score 71.2%, so the failures are strongly correlated. Four pre-registered attempts to fix it have been rejected at plus or minus 0.00 percentage points, each archived with its grid and verdict.

A project that publishes four consecutive failed fixes to its own weakest number is telling you something about how it handles the numbers you cannot check.

Where the headline claims stop holding

Now the part that decides whether this is for you.

The benchmark slice is Python. The README says so directly: 107 of 134 gold files in the localization sweep are .py. That measures Python localization, not the twenty-plus languages the tool parses. If your codebase is Go or Java or Elixir, the file@k numbers are not evidence about your repository. The parsing may still be fine. The ranking is unproven there.

The speed comparison names no competitor. The 0.25 seconds and 6.6 MB against 46.8 seconds and 391 MB is measured "against the graph-database MCP server it was measured against," which is not a name. The head-to-head section does name tools, and one limit travels with it: repowise's timings include a fresh MCP-server spawn per query, and resident-server usage is faster. So the cold-start gap is real and the steady-state gap is smaller than the headline implies.

The compounding claim is unrun and says so. The most interesting argument in the README is that orientation is a fixed cost paid on every cold agent start, so a multi-agent orchestrator spawning lanes into an empty context pays it over and over, and ripwire amortizes it. The README's own words: every figure on the page is a single-agent measurement, the compounding follows from the fixed-cost mechanism, and it is pre-registered and unrun. That is the reason to try the pattern, not a result.

The MCP server costs you context whether you use it or not. This is the most practically useful warning on the page and it is easy to skim past. The project recommends the CLI as the baseline and calls the MCP server the optional second interface, because the MCP verb schemas sit in your agent's context every session whether or not the agent calls them. If you install this the convenient way, you are paying a standing context tax for a tool built to reduce your context.

There is no Windows binary. Prebuilt binaries cover macOS and Linux on arm64 and x86-64, built for RHEL 8 and later, SHA-256 verified. Building from source needs CMake 3.24+ and a C++23 compiler. Windows users are on their own.

Install is curl | bash. The one-liner pipes a shell script from raw.githubusercontent.com straight into bash, and the installer stages seventeen agent skills and activates them for every agent it detects on your machine. It does not register hooks without an explicit flag, and it skips agents that are not installed, but read the script before you run it, the same as you would for anything else that writes into ~/.local.

One more thing about the LICENSE. The repository lives under the redhat-et organization, and the Apache 2.0 LICENSE names an individual copyright holder, David Brewster, rather than Red Hat. That is not a problem in itself and Apache 2.0 is Apache 2.0. It does mean the org name is doing more reputational work than the legal text supports, and if your procurement process treats "Red Hat project" as a category, someone should look at the file before that assumption gets written down.

Put this into practice

The lowest-friction way to evaluate this is thirty minutes on a repository you know well, using the verbs where the claimed savings are largest and the answer is easiest to check.

Build it yourself the first time. You need CMake 3.24+ and a C++23 compiler, nothing else. It is slower than the one-liner and it means you never piped a remote script into a shell. If you do use the installer, read scripts/install.sh first and note that it activates skills for every agent it finds.

Start with --callers, not --for. Pick a function in your codebase whose callers you already know from memory. Run ripwire . --callers=YourSymbol. Either it names the same call sites you would have named, or it does not, and you learn the answer in ten seconds without trusting anybody's benchmark. This is the highest-savings verb in the table and the easiest one to falsify.

Then run --situ on a real diff. Make a change you were going to make anyway, then run ripwire . --situ and compare its test list against the tests you would have run. The README claims this surfaces harnesses a filename grep across the test directory cannot find. That claim is checkable in your own repository in about two minutes.

Skip the MCP server until the CLI has earned it. Wire the CLI in as a shell command your agent can call. If you are using Claude Code, Codex, Cursor, Windsurf, Gemini, opencode or aider, the shell path works without adding anything permanent to your context. Add the MCP interface later, if ever, knowing that its schemas are a standing cost.

Judge it on your language, not on the README's. If your codebase is not Python, treat every localization figure as unverified for you and give yourself a week of real use before deciding. The tool may be excellent on Go. Nothing published so far demonstrates that.

Why this one is worth your attention anyway

There is a real idea underneath the marketing, and it is the same idea running through everything else this week. The expensive thing a coding agent does is not thinking. It is orienting itself in a repository it has never seen, over and over, from a cold context, and that cost scales with the size of your tree and the number of agents you run.

grep-and-read was never a retrieval strategy. It was the absence of one, and it worked fine when a human with a mental model of the codebase was driving. An agent starting cold has no mental model, so it reads whole files to build one, and pays for every byte. ripwire, tgrep and Headroom are three different bets on that same observation, and ripwire's bet is the most specific of the three: return structure, not text.

Whether the implementation holds up on your code is an empirical question you can answer in half an hour. What I will say is that a six-week-old project that responds to a favorable benchmark by re-running it, publishing a smaller margin, and archiving four failed attempts at its own worst number has already told you more about its honesty than most one-year-old projects ever will. Take the 52x with salt. Take the 1.46x seriously.

Sources: redhat-et/ripwire README and LICENSE, read cache-busted on 2026-09-08; star count from cache-busted shields.io; release tag and date from the repository's releases feed; Trendshift daily board read at 07:14 ET on 2026-09-08, where rankings are momentum scores rather than star totals. All benchmark figures in this article are ripwire's own published measurements, including its measurements of competing tools, and none have been independently replicated.

Medium metadata

Title: ripwire Hands Coding Agents a Repo Map Instead of grep. Its Most Convincing Number Is the One That Got Worse.
Subtitle: The "ripgrep of AI context" re-ran its own head-to-head and cut its published lead from 1.75x to 1.46x. That correction is the reason to take the rest of it seriously.
Tags: AI Agents, Developer Tools, Open Source, Claude Code, Software Engineering
Suggested kicker image: a hand-drawn contour map pinned to a workbench, one route traced in red pencil, everything else left faint
Canonical: import from the fervorai.dev URL