jevgrep: code search by behaviour, and what its own benchmark shows

A retrieval tool, not a code answer machine

jevgrep is described as find code by asking what it does, a CLI for coding agents that uses Jev to judge relevance across folders, files and declarations. The framing matters, because it draws a boundary the README is careful about.

You ask a question about a repository, and `jg` returns relevant files, reading leads and verbatim source excerpts on stdout. Then your coding agent does the implementing and testing. The README states the output is evidence for the agent to use, not a generated answer, and not a guarantee that every relevant file was found. The bundled skill likewise leaves research and implementation decisions to the calling agent.

The problem it addresses is narrow and real. A coding agent starting on an unfamiliar repository spends part of every task locating the right files. A grep tool answers an exact string you already know. jevgrep is for the case where you know the behaviour you need to understand but not where it lives, for example where authentication is checked before a request reaches a handler, or which tests cover retry behaviour when a request times out.

That is also its limit, and the README says so directly: when you already know an exact symbol or path, a direct read or an `rg` search may be all you need. jevgrep is most useful for questions that span unfamiliar files.

The output is ordered evidence, structured for an agent

The response format is specified rather than left to chance. The summary and a compact file list come first, then the selected source with line references, then detailed declaration and call locations.

That order is the design. An agent reading top to bottom gets orientation before it gets code, and line references let it open the right window instead of reading a whole file. Declaration and call locations at the end are the part that generalises beyond the excerpt, because they say where a symbol is defined and where it is invoked rather than only where a match occurred.

Two details show the author has run this against awkward cases. It keeps qualifying file locations even when it cannot confidently return an excerpt, so a partial result is still a lead rather than an empty response. And it does not force every search into a fixed top-two list, which means the number of files returned reflects the repository rather than a hardcoded ceiling.

Language support is uneven and stated as such. Python and TypeScript or JavaScript get real declaration parsing. Everything else falls back to a text path, which means for a repository of, say, Go or Ruby you get matching files and excerpts without the declaration and call-site detail that makes the tail of the output useful.

Installing the CLI and pointing it at a provider

The install is a global npm package, and it has three prerequisites that are worth reading before anything else: Node.js 22 or newer, macOS or Linux, and an API key for one of Vercel AI Gateway, TypeSafe, OpenRouter or OpenCode Zen. No separate Python, Bun or ripgrep installation is needed to use `jg`.

npm install -g @dzhng/jevgrep
jg auth
jg "How are telemetry events recorded and sent?" ./my-project

`jg auth` asks which provider you want, then saves the key in an owner-only config file. Re-running auth replaces that setup, and searches always use the saved provider rather than anything passed per invocation.

Two operational details follow from that design. Environment-based credentials and endpoint overrides are not used, so a CI job cannot inject a key through a secret variable and has to run `jg auth` as a setup step. And an existing saved key that predates provider selection is treated as a Vercel key, which is a quiet behaviour to be aware of when upgrading an old installation.

`jg doctor` checks the saved credential with synthetic input, which is the right way to do it since it does not put your source through the provider just to find out whether the key works.

The skill is a separate install that drifts from the CLI

Installing the binary does not make an agent use it. The README is explicit that you must also install the skill, from the project where your agent works.

jg skill

The installer detects agents, listing Claude Code, Codex and OpenCode among them, and asks where to install. It accepts `--global` for a user-wide install and `--yes` for unattended use. Under the hood it delegates to the vercel-labs skills CLI, which means npm or npx and network access are required. You can skip jevgrep entirely and run the installer directly with `npx skills add dzhng/jevgrep --skill jevgrep`.

The drift problem is the part that will bite you. There is no `jg upgrade` command, so the CLI is upgraded with npm, and the README states that updating the npm package does not overwrite skill files in your projects. The skill has to be refreshed by rerunning `jg skill`.

npm install -g @dzhng/jevgrep@latest
jg --version

So you can end up running a 0.4.3 CLI against a 0.2 skill that describes different output, and nothing warns you. Check `jg --version` after upgrading and rerun the installer deliberately.

Your source code is sent to a hosted provider

This is the part to read before pointing jevgrep at a private repository. Searches send eligible source content to Jev through the provider you selected during auth.

The README describes the default filtering, and it is reasonable on its face: filesystem filtering respects ignore files, and excludes hidden files, dependency and build directories, binary files and obvious credential files. So `.gitignore` does real work, and a `.env` will usually be caught.

Then the README says the sentence that should govern your decision: these filters are not a guarantee that all sensitive information has been removed, and you should choose a search root you intend to send. There is no statement about retention or training on the provider side, because the decision sits with whichever provider you authenticate against, and the four options on offer are not the same company.

If your repository is not something you would paste into a third-party chat window, this tool is out. If it is, the narrower question is which provider and which root. Pointing `jg` at `./src` rather than `.` is the difference between sending a service and sending your whole tree, and the README's own examples do exactly that.

What the cost measurement actually shows

The README publishes numbers, and it is unusually careful about their limits. Both jevgrep and a no-Jev baseline solved 8 of 10 SWE-bench tasks. Sol cost fell from $7.62 to $5.44, a 28.6 percent reduction rounded to about 30 percent, computed excluding jevgrep's own cost. A later rerun that included jevgrep measured 25.8 percent lower total cost with the same 8 of 10 tasks solved.

Read the two figures together. The headline graphic reports the flattering one, and the README says so, adding that future benchmark totals include Jev.

The sample is ten tuned Python SWE-bench tasks, one frozen installed package, and the exact public skill from the repository. The README states the comparison measures task success and cost, not a speed improvement or guaranteed savings on every repository.

The most useful observation is the one that cuts against the marketing: the same 8 of 10 solved either way. On this sample retrieval changed what a task cost, not whether it succeeded. That is a real result for cost-sensitive agent loops, and it is not evidence that jevgrep makes agents more capable.

Bun and Turborepo behind a Node-only CLI

The published artifact is a Node-only CLI, and the repository that produces it is built with Bun workspaces and Turborepo. `packageManager` is pinned to `[email protected]`, and the workspace catalogue pins `typescript` to 5.9.3 and `@types/bun` to 1.3.14, so a contributor gets the same toolchain versions as everyone else.

bun install --frozen-lockfile
bun run dev --help
bun run verify

`verify` is `check-types && lint && test && test:installed`, and that last step matters: the README says verification includes Docker tests of the installed Node-only package, so the suite exercises the published CLI rather than only the source tree. The individual scripts are split by concern, with `test:parser` running parser tests against a `test/parser/` directory, `test:filesystem` covering `packages/core/test/filesystem.test.ts` alongside `test/retrieval.test.ts`, and `test:native` running `node scripts/test-native.mjs`.

Formatting and linting are oxfmt and oxlint at pinned versions, not Prettier and ESLint. And `eval:swebench` shells out to `python3`, which is why the README says no separate Python installation is needed to use `jg` rather than to reproduce the evaluation.

Editorial conclusion

Adopt jevgrep when you run coding agents against repositories you are willing to send to a third-party provider and agent cost per task is the metric you are optimising for. Do not adopt it to raise task success rates, since the published run solved the same 8 of 10 tasks with and without it, and skip it for code that cannot leave your network. Verify first that the installed skill matches the CLI, because npm install -g @dzhng/jevgrep@latest does not refresh skill files and jg skill is a separate step.

Frequently asked questions

Official sources

1. dzhng/jevgrep on GitHub
2. Issues
3. License: MIT
4. README
5. Releases