jevgrep Uses Jev to Find Files Instead of Grepping for Them

Coding agents spend part of every unfamiliar task just finding the right files. Grep needs you to already know the string you're looking for. Semantic search needs an embedding index you have to build and keep in sync. jevgrep, a CLI tool by dzhng, takes a third approach: ask a decision model whether each file is relevant to a plain-language question and let it judge.

The command is jg. You install it from npm, run jg auth to point it at a provider and jg skill to wire it into an agent's toolset. It needs Node 22 or newer. Under the hood it calls Jev, TypeSafe's typed decision model, to score folders, files and declarations against your question rather than generating a search query or building an embedding index up front. That fits Jev's actual shape: you hand it a question with a fixed answer space and it returns a typed, probabilistic judgment instead of free text, which is exactly the "is this file relevant, yes or no" decision jevgrep needs to make repeatedly and cheaply.

The README reports a ten-task SWE-bench comparison where jevgrep matched the baseline on 8 of 10 tasks at a lower cost, with a single run showing something like a 25 to 30% reduction depending on whether Jev's own cost is counted. That's a real result but a small one. Ten tasks and one run isn't enough to call it a benchmark. The README says so itself rather than dressing the number up. I'd want to see this repeated across a larger task set and multiple runs before treating the cost figure as anything more than a promising early signal.

The part worth reading before you install it is the data handling note: whatever source content gets sent to Jev for a relevance judgment leaves your machine and goes to whichever provider you configured. The README is upfront that its filtering doesn't guarantee sensitive content gets caught. For an open-source side project or a sandboxed repo that's a non-issue. For anything with secrets or proprietary code sitting in files an agent might scan, that's the detail to check before pointing jg at it, not something to find out after the fact.

The idea underneath jevgrep is the more interesting part than the tool itself. File-relevance judging is exactly the kind of fuzzy, repeated, finite-option decision a classifier model is supposed to be cheaper and faster at than a full generative call. jevgrep is a concrete example of someone building that pattern into an actual developer workflow rather than leaving it as an architecture diagram. If the cost numbers hold up under more testing, this is the shape I'd expect more agent tooling to take: a cheap typed judgment in front of the file list, with the expensive model only reading what already passed the filter.