grep + read files
41,600 tokens
$ greplm --version
greplm 0 6 0 v0.6.0
- Columnar symbol & ref storage
- Atomic deletes with checksums
- Faster warm daemon
Open-source code intelligence for AI agents
Stop paying for tokens your agents never needed
Your coding agents read entire files to find one line. greplm indexes your codebase once and returns only what matters — same answers, a fraction of the cost.
- Up to 99% fewer tokens
- Up to 96× faster
- MCP-native
- Fully offline
Same query. Different cost. "Where is SegmentWriter used?"
−97.1% same answer
greplm search
1,201 tokens
Get started
From zero to indexed in one session
No signup. No cloud. Runs entirely on your hardware.
greplm — launch sequence
- macOS
- Linux
- Windows
greplm installed
$
index ready · daemon warm · agents configured
$
How it works
Walk the repo once. Stop paying for re-reads.
greplm walks your repo once, builds a local code-intelligence index, and keeps it warm — so your agent asks precise questions instead of re-reading the tree.
Select a step to explore the pipeline
Indexing codebase 01 / 04
Your repo
- main.rs
- indexer.rs
- segment.rs
- search.rs
.greplm/
- Symbols
- References
- Call graph
- FST search
Parse every file into symbols, references, and call graphs. Store them in columnar segments under .greplm/ — fully offline on your machine.
Columnar segments · memory-mapped
- Symbols
- References
- Call graph
- FST search
daemon warm · incremental on save · no full-tree rescans
Memory-map segments once. Incremental updates on save. Queries hit the index in milliseconds — no full-tree rescans on every search.
AI agent
Where is SegmentWriter used?
- search_code
- build_context
- find_callers
- impact_of
- goto_definition
greplm-mcp over stdio · answered from the warm index
Your coding agent sends search, context-pack, caller, or impact queries through MCP — the same tools you run in terminal, wired into Cursor or Claude Code.
3 hits · jump-ready
- function
segment.rs:242write - caller
indexer.rs:187index_full - caller
daemon.rs:263dispatch
Token cost
97.1% fewer tokens, same files
Jump-ready file:line hits land in context — ranked, budgeted, and up to 99% smaller than dumping whole files with grep-and-read.
Drop-in for your agent
Wired into the tools your team already uses
greplm speaks MCP, so it plugs into Cursor, Claude Code, Copilot, and any MCP-aware client — then teaches the agent to reach for it instead of grep.
Detected & configured
- Cursor
.cursor/rules - Claude Code
CLAUDE.md - GitHub Copilot
.github/ - Any MCP client
mcp config
Speaks MCP — works with any MCP-aware client.
three commands · zero config
-
$greplm setupIndex your repo and warm the daemon — auto-detects agent files -
$greplm mcp configPrint ready-to-paste MCP JSON with resolved paths -
$greplm agent addTeach your editor to prefer greplm over grep
Auto-detects .cursor/, .claude/, and .github/, plus memory files like CLAUDE.md and AGENTS.md — falling back gracefully when nothing is found.
Beyond grep
It answers the questions an agent asks before it edits
One warm index walks the call graph, resolves typed go-to-definition, matches AST patterns, and assembles exactly the code a task needs — on a token budget.
$greplm callers references --limit 3 Who calls this function cmd_refs → references main.rs:896:17dispatch → references daemon.rs:263:32$greplm impact add_doc --depth 2 Blast radius via the reverse call graph d0 function add_doc segment.rs:132-165d1 function index_full indexer.rs:187-262d1 function index_incremental indexer.rs:265-454$greplm ast 'fn $NAME() {}' --lang rust Structural search regex can’t express agent.rs:86-88 fn dest(&self, …) -> PathBuf NAME=dest$greplm pack "how incremental indexing works" --budget 4000 Task context pack, budgeted # 15 items · ~3489 / 4000 tokens## function index_incremental (match) indexer.rs:265-454 [17.9] searchsymbolscallerscalleesimpactdefrefsastpackblamehistorychanged
Business impact
Your agents are burning budget on re-reads
Every search that dumps whole files into context is a tax on your API bill and your team’s velocity. greplm returns jump-ready answers — so sessions stay sharp and spend stays low.
One agent session · 4 codebase searches 200k context window
0 context cap
166,400 tokens
41,600 per search × 8
Context nearly exhausted — session ends early
0 context cap
4,804 tokens
1,201 per search × 8
Room for dozens more searches in the same session
99%
Fewer tokens per search
Same files returned, compact output
96×
Faster warm queries
Milliseconds, not full-tree scans
100%
Recall on benchmarks
Same results as grep-and-read
0
Data leaves your machine
Fully offline · no telemetry
Languages
14 languages. One index.
Symbols, call graphs, and AST search across your entire stack — from kernel C to Flutter apps.
14 languages indexed
One warm index powers every query — symbols, callers, blast radius, and AST patterns without re-scanning the tree.
.symbols.callers.impact.ast.refs
Fully offline — nothing leaves your machine. Index once, query forever.
Benchmarks
Proven on production-scale codebases
Same files as grep-and-read — for a fraction of the tokens, answered from a warm index in milliseconds while ripgrep re-scans the whole tree.
| Project | Files | Index once | Search saved | Pack saved | Recall | Warm query vs ripgrep |
|---|---|---|---|---|---|---|
| React JS / TS | 6,723 | 2.0s | 99.7% | 97.4% | 100% | 9 ms 12× faster |
| Odoo 18 Py / JS / XML | 41,142 | 19.8s | 99.9% | 99.3% | 100% | 33 ms 33× faster |
| Linux kernel C | 93,362 | 66.5s | 99.9% | 98.4% | 100% | 31 ms 75× faster |
Content search across all three suites
218.7M tokens 280.5k tokens 99.9% fewer
tokens ≈ characters / 4, applied identically to both engines; ripgrep runs in literal mode so both look for the same string. Warm query = median latency against the always-on daemon.