jev-search and jev-semgrep: Search and Static Analysis, Typed

Keyword search and regex grep share a limit: they match strings, not meaning. A support ticket that says "still waiting, this is unacceptable" won't match a query for "angry customer" unless someone writes a synonym list first. Semantic search tools try to fix this with embeddings and vector databases. A smaller, newer approach skips the vector database and asks Jev, TypeSafe AI's typed decision model, a direct question per candidate: does this line, page, or result match the meaning I'm looking for?

Three projects on the Awesome Jev radar apply that idea to search and static analysis. Two of them are, confusingly, both named jev-search — built by unrelated authors, for different jobs, in the weeks since Jev's release. The third, jev-semgrep, brings the same typed-scoring idea to grepping text and code by meaning instead of pattern.

Key Takeaways

• Two unrelated repos are both called jev-search. superagents-lab's is a full web search app with 426 stars; larguesa's is a tiny experimental CLI with 6 stars. Don't confuse them.
• jev-semgrep reports real precision and recall: the author's own tests show precision 0.94, recall 0.98 on a test set, with probabilities drifting ±0.05 between runs.
• Every one of these three sends your content to an external API. Search queries, grep queries, and the lines they match all leave the machine.
• jev-semgrep works across languages by meaning, not vocabulary — the author reports a Japanese query matching refund requests written in French, Russian, German, Spanish, Chinese and Korean.
• larguesa's jev-search is explicitly exploratory, with a self-described small, manually curated benchmark that the author says doesn't yet prove general superiority over keyword search.

superagents-lab/jev-search: a typed router in front of 12 search engines

superagents-lab/jev-search (listing) is a web search app, not a code tool. A user types a plain-language question, and Jev decides which sources to query, what time range to use, and how to rank the results that come back — rather than an LLM writing a free-text answer. It queries up to 12 sources concurrently, among them Google, DuckDuckGo, Yandex, Reddit, Hacker News, GitHub, X, arXiv, YouTube, Wikipedia, IMDb and WeChat, merges results by URL, and streams them as each source lane finishes. Source and time-range choices stay editable in the UI, and one engine failing doesn't remove the others' results. The project caches successful responses for 10 minutes to 6 hours and enforces a 30-second overall deadline with 15-second per-engine limits.

It's the most substantial of the three by usage: 426 stars as of September 2026, MIT-licensed, built by Search1API as an independent project (not official TypeSafe software). A hosted version runs at jev.s1.dev; local development needs Node.js 22.12+, pnpm, a Search1API key and a Jev provider key (TypeSafe, Cloudflare Workers AI, or Vercel AI Gateway).

larguesa/jev-search: an experimental line search, honestly labeled

larguesa/jev-search (listing) does something narrower: it searches small local text files (up to 8 files, 16,384 bytes combined) for passages that match a meaning rather than a keyword, useful for skimming a wiki page or a README rather than indexing a codebase. It's a Python CLI with no runtime dependencies, using Jev 1.13 via OpenRouter or a direct TypeSafe connection.

The author's own exploratory results, run across six simulated tasks on technical text, found that combining semantic and lexical search recovered 29 of 34 labeled relevant passages, against 22 of 34 for keyword search alone — at roughly $0.0006 for six requests and a 0.536-second median latency. The README is unusually candid about what this doesn't prove: it's a small, manually curated experiment, not a demonstration of general superiority over keyword search plus reading the surrounding context. At 6 stars, this is an early, single-author tool. Note also that scores aren't calibrated as true probabilities, and every selected line and query is uploaded to an external provider — this isn't a private local search.

uehaj/jev-semgrep: grep by meaning, with numbers attached

uehaj/jev-semgrep (listing) is the most quantified of the three. It's a zero-runtime-dependency semantic grep: it asks Jev whether each line matches a stated meaning, batching about 30 lines per request across 8 concurrent requests, and supports AND/OR/NOT logic across multiple meanings. A single Node.js file, requiring Node 20.12+, installed globally with npm install -g @uehaj/semgrep or run directly via npx.

The author reports concrete numbers, not just description: precision 0.94 and recall 0.98 on a test set, roughly ±0.05 drift in probabilities between runs, and processing 210 lines in under one second through batching. It's language-agnostic by design — an English query matches Japanese lines and vice versa, and the README describes one Japanese-language meaning successfully locating refund requests across six other languages. Accuracy is reported as best in English, with "noisier" results in Japanese. Pricing follows TypeSafe's roughly $0.042 per million input tokens, and the service enforces a 1,200 requests/minute rate limit. Every searched line — potentially including source code, logs or customer data — is sent to api.typesafe.ai, which the author flags as a real privacy tradeoff for sensitive files. It has 131 stars as of September 2026 and is MIT-licensed.

What these three have in common — and don't

None of these tools replaces indexed search or a real static analyzer. superagents-lab's jev-search is a routing and ranking layer in front of existing search engines; larguesa's is a small-scale experiment its own author hasn't yet validated broadly; jev-semgrep is a grep replacement for meaning-based line matching, not a security or correctness scanner. What they share is the underlying pattern this series keeps returning to: instead of asking an LLM to write prose about relevance, each one asks Jev a typed question — does this match? how relevant is it? — and lets ordinary code act on the typed answer. That's the same pattern the database-native Jev tools apply to SQL rows, just applied to search results and text lines instead.

What to do next

• Don't confuse the two jev-search repos when you cite or install one — check the author and star count against this article or the radar directly.
• Reproduce jev-semgrep's precision/recall numbers on your own corpus before trusting them for a real static-analysis workflow; a single author's test set doesn't generalize automatically.
• Treat larguesa's jev-search as a prototype to learn from, not a search engine to depend on — its own README says as much.
• Read Typed Decisions vs Free Text for why scoring beats prose here, and apply How to Evaluate Jev Projects Honestly to any of these before shipping them.