Coding agents need to understand a repository before they can safely modify it, a process that can consume a significant portion of their context window as they search for symbols, open files and reconstruct relationships between functions. Ripwire, a new open-source project published under Red Hat’s redhat-et organization, proposes a different approach: analyze code locally and provide the agent with a structured, ranked map of the repository, without embeddings, external APIs or a vector database.
The key facts about Ripwire in 30 seconds
- Ripwire is written in C++23 and runs locally without an index server or API keys.
- It uses 22 vendored grammars to analyze programming languages and repository files.
- It ranks symbols using structural relationships, complexity, Git history, test coverage and other signals.
- It can identify relevant code, callers, potential blast radius and tests associated with a change.
- Its developers report substantial token savings compared with workflows based on searching repositories and repeatedly reading entire files.
The idea is particularly relevant as tools such as Codex, Claude Code, Cursor, Gemini, Windsurf, opencode and aider become capable of working autonomously across increasingly large software projects.
A model can have a huge context window and still use it inefficiently.
When a developer asks an agent to “modify incremental cache invalidation,” for example, the agent first needs to discover where that functionality lives. It might search for related terms, open several files, inspect functions, identify their callers, find relevant tests and gradually build a mental representation of the project.
Ripwire attempts to provide that representation before the agent starts reading the repository indiscriminately.
A repository map instead of turning source code into vectors
One common way to provide large amounts of information to an AI model is Retrieval-Augmented Generation (RAG).
Documents or pieces of source code can be transformed through an embedding model into numerical representations. Those vectors are then stored and queried using specialized systems, including vector databases.
When the agent needs information, semantic search retrieves chunks considered relevant to the query.
Ripwire takes a different route.
The project describes itself as “the ripgrep of AI context” and analyzes the structure of the source code itself to determine which information should be presented to the agent.
It is built in C++23 and incorporates Tree-sitter grammars directly into the project. It currently lists 22 vendored grammars, covering languages and formats including Rust, C++, Objective-C, C, CUDA, Python, Go, Swift, TypeScript, JavaScript, Java, Ruby, PHP, Lua, Elixir, Bash, C#, JSON, TOML, YAML and Markdown.
There is no need for an external indexing service, embedding API or API key.
The analysis can run locally.
That can be particularly attractive for private repositories because the mapping process itself does not require sending source code to an external indexing service. The privacy of the complete workflow will, of course, also depend on the AI coding agent and model being used.
Ripwire builds relationships between symbols and combines different signals to prioritize what it considers important.
These include call relationships, cyclomatic complexity, historical Git churn, test coverage and several other code-quality indicators.
The result is intended to be more useful than a list of files containing a particular word.
| Agent question | What Ripwire can provide |
|---|---|
| Where is this feature implemented? | Ranked relevant symbols |
| Who calls this function? | Callers |
| What uses this symbol? | Uses and relationships |
| Is this safe to change? | Potential blast radius |
| Which tests should run? | Related tests |
| What changed recently? | Git-aware context |
| What matters in this PR? | Change-specific context |
| Where is risky or complex code? | Metrics and hotspots |
The conceptual difference matters.
A vector database is primarily useful for answering “which content is semantically similar to this query?”
Ripwire also attempts to answer “which parts of the program are structurally connected to the thing the agent is about to change?”
Token savings are a major part of the pitch
This approach has another potential benefit: reducing the amount of source code that reaches the model’s context window.
Ripwire’s developers publish several measurements comparing its output with more conventional search-and-read workflows. These figures should be treated as project benchmarks, rather than independent evidence that every repository will see the same savings.
For example, asking who calls a particular function required roughly 580 tokens in one Ripwire measurement. A comparison based on searching for the symbol and opening two or three files consumed an estimated 40,000 to 52,000 tokens.
Preparing context for a specific task required around 2,100 tokens with Ripwire, compared with an estimated 16,000 to 80,000 tokens when reading the relevant files in full.
For a stack trace, the project reports roughly 1,400 tokens compared with 124,000 to 298,000 for a workflow involving multiple searches followed by file reads.
The differences are much smaller for some other tasks, and Ripwire explicitly acknowledges situations where using it does not pay off. If a question can be answered with a single grep, building and consulting a richer repository map may provide little benefit.
One particularly eye-catching claim is that Ripwire used approximately 5% of the tokens consumed by a grep-and-read workflow in one of its measured scenarios.
That should not be interpreted as a universal 95% reduction in AI token costs.
Actual savings will depend on the repository, task, model, workflow and how much unnecessary source code the agent would otherwise have read.
Does this mean goodbye to vector databases?
Not quite.
Describing Ripwire as a universal replacement for embeddings or vector databases would go beyond what the project demonstrates.
The technologies address overlapping but different problems.
Vector retrieval remains useful when agents need to find semantic relationships across large collections of documentation, support tickets, conversations, enterprise knowledge or other unstructured information.
Ripwire is specifically designed around software repositories, where there are signals that ordinary documents do not have: functions, call graphs, types, dependencies, Git history, complexity metrics and tests.
| Approach | Main strength |
|---|---|
| Grep / text search | Exact matches and speed |
| Embeddings + Vector DB | Semantic similarity |
| Direct repository reading | Maximum source detail |
| Ripwire | Code structure and relationships |
| Compiler-grade analysis | More precise program relationships |
There are limitations even within source code.
Ripwire acknowledges that a name-based call graph cannot perfectly capture dynamic dispatch, some indirect calls, callbacks routed through tables or symbols that only exist after macro expansion.
The project includes confidence and warning mechanisms intended to flag uncertainty, while allowing users to escalate to more precise analysis when necessary.
Its most interesting proposition therefore is not that RAG is obsolete, but that RAG may be unnecessary for some repository-navigation problems when the inherent structure of software can be used instead.
From giving the agent files to giving it exactly what it needs
This idea could become increasingly important as coding agents gain autonomy.
Large context windows are not free. The more irrelevant source code a model processes, the more tokens are consumed, while useful information can become buried among unrelated material.
Ripwire allows explicit token budgets to control how much context is returned.
It can also provide function signatures without sending complete bodies. The project reports 80.2% fewer element bytes for its top-50 signature representation compared with including full bodies.
If the agent later needs a specific implementation, it can request additional detail.
This resembles how an experienced developer approaches an unfamiliar codebase.
They do not normally start by reading every file from beginning to end. They first understand the architecture, identify relevant modules, locate important functions and then inspect the areas connected to the task.
Ripwire tries to automate that selection process.
The project offers both a command-line interface (CLI) and an optional Model Context Protocol (MCP) server.
Interestingly, its developers recommend starting with the CLI. Their reasoning is that MCP tool schemas themselves occupy agent context during sessions, even when those tools are not called.
Ripwire supports workflows involving Codex, Claude Code, Cursor, Windsurf, Gemini, opencode and aider, and is distributed under the Apache 2.0 license.
It also goes beyond repository navigation. Available capabilities include impact analysis, hotspot detection, complexity metrics, change review, test selection and several code-quality indicators.
In its LocBench retrieval evaluation, the project reports finding all expected files within its top ten results in 58.3% of cases, compared with 40.0% for the strongest alternative included in that particular test.
Again, those are measurements published by the project itself and should be validated across more independent repositories and workloads before drawing broader conclusions.
The underlying idea remains interesting regardless of the exact percentages.
Much of the AI industry has approached the context problem by expanding context windows, generating embeddings and storing increasing amounts of information for later retrieval.
Ripwire proposes another option: make the agent read less by organizing the repository before handing context to the model.
If that approach proves reliable across large real-world projects, the savings would not come only from avoiding embedding APIs or vector database infrastructure.
They could come from something potentially more valuable: reducing the millions of tokens coding agents spend repeatedly rediscovering how the software they are working on is structured.
Frequently asked questions
What is Ripwire?
Ripwire is an open-source tool published under the redhat-et organization that analyzes software repositories and provides coding agents with ranked information about symbols, relationships, potential impact and relevant tests.
Does Ripwire require embeddings or a vector database?
No. Ripwire operates without embeddings, external API keys or an external index server, and its repository analysis can run locally.
Can Ripwire work with Codex and Claude Code?
Yes. The project provides workflows for Codex, Claude Code, Cursor, Windsurf, Gemini, opencode and aider through its CLI, MCP server or agent-specific integrations.
Does Ripwire replace Vector DBs?
Not generally. It can eliminate the need for vector retrieval in some code-context workflows, but vector databases remain useful for semantic retrieval across documentation and other unstructured information.