Pathfinding Without Vector Indexes: Blink and neo4jev
Blink walks file trees and neo4jev walks Neo4j graphs by asking Jev which branch to take next. How index-free navigation works, and what the demos do not prove.
Semantic search normally starts with preparation: chunk the corpus, embed it, build an index, keep it fresh. That is the right call for large, stable collections. It is heavy for a codebase that changed an hour ago, or a graph you only want to explore once.
Two projects built on Jev, TypeSafe AI's decision model that returns typed scores and choices, skip the index. They treat search as navigation. At each level, present the candidates (directory names, graph relationships), ask Jev how likely each is to lead toward the goal, and follow the promising ones. Both were created on 16 September 2026, so this is early, small-scale work. Both appear on the Awesome Jev radar with source-reviewed summaries.
Key Takeaways
- No pre-built index. Both tools navigate the live structure (a file tree or a graph) rather than searching embeddings.
- Jev scores branches; code manages the search. The model returns probabilities, and local logic allocates effort.
- Blink and neo4jev are different algorithms. Blink uses an ensemble of walkers. neo4jev uses beam search. Do not conflate them.
- Speed claims are unproven. The site's review found no general benchmark for Blink and no measurement of large-graph speedups for neo4jev.
- Both are tiny: 14 and 16 stars as of September 2026.
Blink: spend walkers where the odds are
Blink (aiskill.market page) describes a natural-language query and finds a matching file. Its README describes "an ensemble of walkers that walk the file system": Jev scores the file and folder names at each level, and more likely paths get more walkers. Walkers keep moving until they reach a file, and the output shows the percentage of starting walkers that ended at each result.
Practical details from the README: it shows the top 10 results and groups the rest as "OTHER"; it needs Bun 1.3.14 or later and a TYPESAFE_API_KEY; without recursion flags it ranks only immediate subdirectories; empty folders are marked unresolved; and you can exclude names via settings.json. It quotes Jev pricing of $0.042 per million input tokens with free output tokens.
One correction to how it is sometimes described: the radar's review notes that Blink's README calls this an ensemble of walkers and never says beam search. It also offers no general speed benchmark, so "seconds on huge repos" is a plausible expectation, not a documented result. Because Blink only sees names, a repo with unhelpful file names will limit it. That is an inference from the mechanism, not a stated limitation.
neo4jev: one hop, one round-trip
neo4jev (listing) moves the same idea into a knowledge graph. At each node, outgoing relationships become Choice options, each with relationship type, properties and target node details. Jev returns a probability distribution, and a top-k or cutoff rule selects branches, which is beam search.
A Noul question ("has the goal been reached?") is asked in the same system_one call as the Choice, so each hop costs exactly one round-trip. Paths are ranked by the sum of log-probabilities to avoid float underflow and length bias.
Limits are explicit: at most 10 relationships per type and 60 per hop, filled round-robin across relationship types, so supernodes are sampled and unused edges can't be selected. The demo targets the public Neo4j Companies knowledge graph, though the code is described as schema-agnostic.
The most refreshing detail is the fallback. Without an API key, each call is attempted, its failure is displayed verbatim, and the pipeline runs on explicitly labelled stand-in answers. The README says nothing is ever presented as TypeSafe output that did not come from TypeSafe. That is exactly how a demo should behave when it cannot reach its model.
What the demos do and don't prove
| Question | Answer |
|---|---|
| Does the mechanism exist as described? | Yes, per each README |
| Is it faster than vector search? | Not measured in either README |
| Does it scale to very large graphs? | The review found no tens-of-millions-of-nodes measurement |
| Is it production-ready? | Both are days old with 14 and 16 stars |
Each hop costs an API call, so cost and latency grow with depth and width. Vector search pays up front and queries cheaply. Index-free navigation pays per query. Which wins depends on how often you query versus how often the data changes, and nobody has published that comparison for these tools.
What to do next
- Use Blink as a probe on a repo you know, and see whether its top result matches where you would have looked.
- Read neo4jev's fallback behavior as a template for honest demos.
- Think about your access pattern: rarely queried, frequently changing data suits navigation; hot, stable data suits an index.
- See another Jev retrieval shape in Jev for Search and Data, and the general reasoning in Typed Decisions vs Free Text.