Community · E2 · artifact verified
Grep for what code does, not what it's called
jgrep answers semantic queries like catches an error and silently ignores it over a whole source tree in about two seconds for a cent: one typed yes-or-no judgment per code chunk, sixteen chunks per request, no index.
01 · Role in the system
What Jev does here
Exact strings belong to grep; meaning belongs to LLMs that are slow and priced per call. jgrep splits the difference with Jev: chunks of code go out sixteen per request, each answering one typed yes-or-no question derived from your query - with calibrated probabilities, in parallel, at per-million-token input pricing with output free. No index, no embeddings, no vector database: a whole src tree takes about two seconds and about a cent, and it works on a git diff too, which is how you ask for the endpoint with no auth check in my changes. Results come back as file:line with the probability attached. Zero runtime dependencies, shipped on npm.
02 · Control boundary
Where Jev sits
Code split to chunks; batched typed yes-or-no questions per chunk; deterministic ranking of file:line hits by probability.
Code owns the loop, permissions, thresholds, validation, and side effects. Jev owns only the bounded judgments described above.
03 · Known limits
What this evidence does not prove
- Judgment runs per query over the tree, so repeated searching re-pays the cost by design - the trade for having no index.
- Two-second and one-cent figures are author-reported.
- Chunking bounds context: cross-file semantic patterns are judged per chunk, not per program.
04 · Attribution
Public sources
This is a Community record: the project was published by a third-party community author.
- kyu1204 ↗Community · github · public · checked 2026-09-24