Explainers · updated July 2026
Semantic search finds code by concept, not by the name you typed.
Ask a plain-English question (“where do we charge the card?”) and semantic search hands back the right function even when you didn't know it was called chargeCard(). That's the magic behind Cursor's codebase answers. But turn it around: type an exact symbol you already know, and searching by meaning works against you. It ranks look-alike functions above the one you asked for. Here's what semantic search is, the one place it quietly fails on code, and the exact-match lane that belongs right next to it.
The same two queries, two engines
Meaning on one side. Exact text on the other.
Semantic search matches by meaning; literal search matches the characters you typed. Run the same two queries through both and the split is clean: each engine wins the row the other loses. This is the whole article in one picture; everything below just walks the four corners.
The left column is what a Cursor-style semantic search returns; the right is what a literal tool like grep returns. Read it as a rule of thumb: know the exact words → go right; can't name what you're after → go left.
Where it fails on code
Brilliant for questions. Blind to exact names.
This isn't a takedown. For the fuzzy question (“where's the auth flow,” “what touches billing?”) semantic search is the right tool, and Cursor built a good product on it. The trouble is the opposite, extremely common case: you already know the token, and now ranking-by-similarity is the wrong shape. Three ways it shows up:
Two functions can mean almost the same thing, so the getUserById you typed can rank below a fetchUser you didn't. When you already have the name, you want that name, not its five nearest neighbours.
Nearest-neighbour is a ranked list, not a complete set. A refactor, a security sweep, a rename needs every literal call site: a guarantee approximate recall structurally can't make.
Vectors are a snapshot of meaning. Edit the code and they describe the old version until you re-embed, which is compute, latency, and, for cloud setups, your code leaving the machine to be turned into numbers.
None of this makes semantic search bad. It makes it a meaning tool with a blind spot. And the blind spot is the everyday case: the exact string, the current bytes, the symbol you renamed a minute ago, everywhere on the machine. That isn't a meaning question. It's a lookup.
The literal opposite
grep never guesses. It also never stops walking.
grep and ripgrep read the real bytes on every run, so they're the mirror image of semantic search: never approximate, never stale, never wrong about what's literally there. The catch isn't correctness. It's cost and reach. They re-walk the disk for every query, and they only see where you point them: one folder, one repo.
So the exact lane is right (you do want literal, current matches), but grep's delivery is wrong for an agent. Which raises the obvious question: what if a literal search were already pre-walked, exact like grep, but answered from memory and fresh to the last save?
The exact lane, measured · Ryzen 9 9950X3D · 4.47M files
Exact like grep. Fast like memory. Fresh like a save.
A purpose-built live index keeps grep's two virtues (literal matches, current bytes) and drops its cost: the walk already happened, so the answer is waiting. There is no model in it to drift, and nothing to re-embed. Point it at a name, a symbol, a string, or an error message and you get every exact hit, whole-machine, fresh to the last save. Measured on the machine below:
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Filename figures are medians: 139 μs across 20 queries, 85 μs single-file; the same lookup is 412,000× a VS Code search and ~480,000× Windows Search. Content queries run ~7 to 9 ms typical, ~16 ms for an exact phrase. At rest the engine sits near 44 MB in Task Manager, and the on-disk index stays under 1% of the drive (~24 GB on a 4 TB machine).
The thesis
Keep semantic search. Add the exact lane under it.
Semantic search and a literal index aren't rivals: they answer the two different questions from the diagram, so they run in parallel. Point Cursor's semantic search at meaning, where fuzzy recall is the feature. Point the index at the exact file, symbol, string, or error message: whole-machine, across every repo and the files git ignores, fresh to the last save. No model in the loop: every hit is a literal match you can verify, not a ranked guess. Interlinked is the exact lane; it replaces neither your model nor Cursor's semantic index. It's the deterministic floor they stand on.
PARALLEL TO SEMANTIC · EXACT, FAST, FRESH · NO MODEL IN THE LOOP.
Do this today
Give every agent the exact lane.
Install once. One signed installer auto-configures 19 AI clients: Claude Code, Cursor, Copilot, Codex, Windsurf, Zed, Cline and the rest. No JSON to edit, no cloud account, no keys.
Point each lane at its job. Keep semantic search for meaning: the plain-English questions you can't name. Hand the agent the exact lane for names, symbols, strings and error messages you already know.
Scope when you know, sweep when you don't. Whole-machine when you have no idea where something lives; scoped to a folder when you do. Scoped queries return in microseconds.
Let it stay fresh. Save a file and it's searchable in about a millisecond. No re-embedding, no re-index step, no drift: the walk already happened.
Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows.
Related: What are embeddings for code? · How Cursor indexes your codebase · RAG, a live index, or grep?