sgrep slices your repo into chunks and asks Jev one typed question per chunk — “does this match?” — then ranks by calibrated confidence. No keywords. No vector index.
The code that matters rarely spells out the concept. Here's how three approaches handle one query.
Literal keyword match.
verify_jwt() — the word isn't there
Prebuilt embedding DB.
Jev decides, one chunk at a time.
verify_jwt() by what it does
Prune vendor dirs, skip minified.
ast & tree-sitter units.
Model2Vec + BM25 → top-k.
One typed question / chunk.
By calibrated confidence.
Claude agents answered the same questions about a distributed app (~450 files, 4 services), comparing grep-and-read, plain sgrep, and sgrep + its graphify call graph. Same model, verified same-quality answers.
The win scales with scatter: auth spans 3 services + client (−49%); trigger config lives in one tidy app (−25%).
| Domain | Manual | sgrep | Lines | Δ |
|---|---|---|---|---|
| Authentication | 76,679 | 39,020 | 2,990→672 | −49% |
| Script-execution | 81,498 | 44,797 | 4,361→918 | −45% |
| Trigger-node config | 62,730 | 47,038 | 1,856→1,343 | −25% |
| Total | 220,907 | 130,855 | 9,207→2,933 | −41% |
"What breaks if we change the worker dispatch?" —
sgrep + graphify used −64%
tokens, read 94% fewer lines, and finished fastest
(94s vs 146s / 247s). Plain
semantic search can't traverse callers — that arm fell back to
grep. Use trace/impact for connection
questions; plain scan for find/describe.
Batch multi-query + a warm daemon flipped the wall-clock sign from slower to faster.
Warm daemon −33% vs cold · cached re-scan −86%. n = 1 per cell — directional. Full report in BENCHMARK.md ↗
Python 3.10+. The first run pulls a tiny (~7 MB) local embedding model for the pre-filter.
# global, isolated command (recommended) $ pipx install "git+https://github.com/Lagnajit09/sgrep@v0.3.0" # or into the current environment $ pip install -e . # set your Jev key — macOS / Linux (add to ~/.zshrc to persist) $ export TYPESAFE_API_KEY="sk-..." # …or Windows PowerShell (persists for new sessions) > setx TYPESAFE_API_KEY "sk-..." # …or set once, used from any dir: ~/.config/sgrep/.env (Windows: %APPDATA%\sgrep\.env) $ echo 'TYPESAFE_API_KEY=sk-...' >> ~/.config/sgrep/.env # optional backup provider — Vercel AI Gateway (auto falls back to it) $ export VERCEL_AI_GATEWAY_API_KEY="vck-..." # ask your codebase anything $ sgrep scan "where are JWT tokens verified" ./src # batch several questions in one run $ sgrep scan "how are requests authenticated" ./src -q "service-to-service auth" --json # follow the call graph: trace a flow, or a change's blast radius $ sgrep trace "how is a script dispatched to the worker" ./src $ sgrep impact --symbol build_worker_payload ./src
--mock for an
offline stand-in for Jev.
.env, then a global
~/.config/sgrep/.env.
sgrep serve keeps the
model warm; add --daemon to any scan.
sgrep trace and
sgrep impact map callers & callees via
graphify — 2–3× cheaper on connection questions.
.sgrepignore plus
automatic skipping of build/vendor & minified
files.
sgrep ships as an agent skill, so Claude Code and Codex
reach for scan / trace /
impact on their own. One SKILL.md,
published straight from the repo as a plugin marketplace — the
agent runs the CLI you installed, the skill just teaches it
when.
# add the marketplace, then install the skill › /plugin marketplace add Lagnajit09/sgrep › /plugin install sgrep@sagex-tools # Claude now uses sgrep on its own — or call it directly › /sgrep:sgrep
# add the Agent Plugins marketplace, then the plugin $ codex plugin marketplace add Lagnajit09/sgrep $ codex plugin add sgrep@sagex-tools # invoke the skill with $sgrep
SKILL.md serves Claude Code and Codex through
the open Agent Plugins standard.
scan/trace/impact for
you.