Explainers · updated July 2026
An embedding model turns words into coordinates of meaning, so an AI can search by what you meant.
Every time Cursor answers “where do we charge the card?” without being told the function's name, or a Pinecone-style RAG chatbot pulls exactly the right paragraph, one quiet component did the work: an embedding model. It converts text into a list of numbers that pins its meaning to a point in space, so similar ideas land near each other. Here's the plain-English version of what it is and how it works, and the honest catch when the text you're searching is code.
TL;DR · the short version
An embedding model is a trained neural network that turns text or code into a vector, a fixed-length list of numbers representing its meaning.
Similar meaning → similar vector so “find something like this” becomes “find the nearest points.” That geometric lookup is nearest-neighbour search.
It powers semantic search, RAG, and Cursor, genuinely great when you don’t know the exact words for what you’re looking for.
The catch for code it’s approximate (a ranked guess, not a complete set) and it drifts: the vector describes old code until you re-embed.
For exact names, symbols and strings a live literal index answers with no model at all: 139 μs across 4.47M files, fresh about a millisecond after you save.
What an embedding model actually is
A network that turns meaning into numbers. Then geometry does the rest.
An embedding model is a neural network trained to turn a piece of text (a sentence, a document, a chunk of code) into a fixed-length list of numbers called a vector, positioned so that things with similar meaning land near each other. Shown millions of examples of what counts as similar, it learns to place related ideas close together and unrelated ideas far apart. The numbers themselves aren't human-readable; what matters is the distance between them. Embed your question the same way, and the closest stored vectors are the best answers, even when they share not one word with what you typed. The picture below is the whole idea in two acts: the pipeline, then the lookup that makes it useful.
The same model embeds both your stored files and your live question, into the same space, which is what makes the distances comparable. A vector database like Pinecone stores those vectors and finds the nearest ones fast; that is the retrieval half of RAG.
What it's genuinely great at
Built for the question you can't put into keywords.
This isn't a takedown. For one whole class of question, an embedding model is exactly the right tool. It's the technology behind semantic search, behind most RAG pipelines, and behind Cursor's ability to answer “where do we handle refunds?” without being told the filename. Three things it genuinely nails:
Ask in plain English and get the right function even when you don’t know its name. “Give money back” can surface issueCredit() with no shared word, the entire reason embedding models exist.
“Explain the auth flow,” “what touches billing?” Questions with no single literal answer. Nearest-neighbour recall is built for exactly this.
Similar ideas cluster even across folders and programming languages, so related code surfaces together without a shared keyword to search for.
Keep it. Nothing below asks you to drop your vector database or Cursor's index. The point is only that searching by meaning answers the fuzzy question, and a different, very common question needs the opposite guarantee.
The honest catch for code
Approximate by design. Stale until you re-embed.
None of this makes an embedding model bad: it makes it a fuzzy-recall tool with a maintenance cost. Three things are worth knowing before you lean on one for code. It is approximate: nearest-neighbour is a ranking, not a guarantee, so “where is every call site?” returns the closest guesses with no promise the one you need is even in the top results. It drifts: a vector is a snapshot, so rename a function or refactor a module and it keeps describing the old code until you re-embed, and the model itself was frozen at training time, so it never saw your newest work. And staying current has a cost: re-running the model is compute and latency, and for cloud embedding services it means your code leaving the machine to be turned into numbers.
The trouble starts when an agent needs the opposite: the exact string, the current bytes, the symbol that changed thirty seconds ago, everywhere on the machine. That is not a meaning question. It is a lookup.
| Embedding-model search | Exact index (Interlinked) | |
|---|---|---|
| Matches on | Meaning: nearby vectors | Literal text: the exact characters |
| Returns | A ranked list of guesses | Every exact match, deterministic |
| Freshness | Stale until you re-embed | Fresh to the last save (~1 ms) |
| Runs a model? | Yes, a neural network | No model, ever |
| Code leaves the machine? | Often (cloud embedding APIs) | Never |
| Best for | “What is this about?” | “Where is this exact thing?” |
The exact lane, measured · Ryzen 9 9950X3D · 4.47M files
When you know the words, you want them exact.
The moment the token is known (a name, a symbol, a string, an error message) ranking-by-similarity is the wrong shape. You want every literal match, deterministically, fresh to the last save, across the whole machine. That is a purpose-built live index, and there is no model in it to drift or re-embed. 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, exact phrases about 16 ms. At rest the engine sits near 44 MB in Task Manager, and the on-disk index stays under 1% of the drive.
The thesis
Keep the embedding model. Add the exact lane under it.
An embedding model and a live index aren't rivals: they answer different questions, so they run in parallel. Point the model 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, and nothing to re-embed. Interlinked is the exact-retrieval lane. It replaces neither your model nor your vector database; it is the deterministic floor they stand on.
PARALLEL TO RAG · EXACT, FAST, FRESH · NO MODEL IN THE LOOP.
FAQ · what people ask
Embedding models, in plain answers.
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 your embedding model 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?