Explainers · updated July 2026
What is a language server? The engine behind go-to-definition.
Every time you Ctrl-click a function and land on the exact line where it is defined, or right-click a variable and get every place it is used, a language server did that. It is a background program that understands one programming language deeply, and it talks to your editor through a shared standard called the Language Server Protocol, or LSP. It is one of the quietly great ideas in modern tooling. It also has an edge you can draw in one line: it understands the project you opened, and nothing outside it.
TL;DR · the short version
- A language server is a background program that understands one programming language semantically (go-to-definition, find-references, types, red-squiggle errors) and talks to any editor through the shared Language Server Protocol (LSP).
- It reads code as code, not as words, but by design it understands only the one project you opened. Your machine holds a dozen repos plus the non-git 90% (configs, logs, docs) that no language server was built to read.
- Cross-repo tools like Sourcegraph help, yet they run on a server and see only the pushed state: never the working copies on your disk, and never the files that were never in git.
- Interlinked is the complementary layer: a literal, always-fresh index of every file on the machine (4.47M files, a filename in 85 µs, a content query in 16 ms that took ripgrep 93.8 s) handed to every agent.
- Keep your language server; Interlinked is the whole-machine floor underneath it, not a replacement.
The idea, drawn plainly
One protocol, so every editor speaks every language.
Before 2016, an editor that wanted smart Go support had to build it by hand, and so did the next editor, and the one after that. Every editor times every language was its own integration, a combinatorial mess nobody could keep up with. Microsoft's answer, built for VS Code and then given away as an open standard, was to put a protocol in the middle. An editor learns to speak LSP once. A language ships one server (rust-analyzer for Rust, gopls for Go, Pylance for Python) that any editor can talk to. The N × M explosion collapses to N + M.
Under the hood it is an unglamorous back-and-forth: the editor sends the server a position in a file ("the cursor is here") and the server answers with meaning. The handful of things it can answer are the features you use every day:
Why it beats searching text
It reads code as code, not as words.
The reason go-to-definition feels like magic is that the server is not matching text. It has quietly built a model of your project's symbols, types and scopes (including the libraries you import) and answers from that model. Three things it genuinely nails:
It knows the user on line 40 is the same variable as line 12, and that the word “user” in a comment is not. Plain text search cannot tell them apart.
Find-references walks the real symbol graph of the workspace and its dependencies, so you get the actual call sites, not lookalike strings.
It re-reads files as you edit, so definitions, types and red-squiggle errors track your work in real time.
Keep it. Nothing below asks you to give up your language server. The point is only where its map ends.
Where the map ends
A language server sees one project. Your machine has a dozen.
By design, a language server binds to the workspace root you opened and builds its model of that project. That is exactly the right scope for editing one codebase. It also means three whole categories of your machine fall outside the circle. Draw it to scale and the structural limit is obvious.
The API, the mobile app, the shared library that all ship together each get their own server instance, or none. No single language server does find-references across repos, and “these projects ship together” is a fact none of them can even hold.
Your configs, .env, logs, markdown notes, the PDF spec: there is no language server for any of it. Most of a real disk is files no LSP was ever built to read.
Each editor and agent runs its own; the model is not shared. An agent with no language server running falls back to plain text search, and that is where find-references gets slow.
Cross-repo intelligence exists, with a catch
Sourcegraph does find-references across many repos. It runs on a server, and only sees what you pushed.
The obvious fix ("just index all the repos") is a solved problem at the org level. Sourcegraph builds precise code intelligence across an organisation's repositories, so you can find every reference to a symbol across hundreds of projects at once. It is the right tool for a platform team. But it runs on a server, is configured per repository, and indexes the pushed state, not the working copies sitting on your disk right now, and never the files that were never in git.
So the two anchors leave the same gap. VS Code's language servers understand one deep project at a time; Sourcegraph understands many pushed repos from a server. Neither indexes the local, unpushed, non-git reality of the machine you actually work on: the layer closest to you.
On a fresh install, a whole-machine index found 12 of 12 repos on the disk and seeded 26,958 relationship pairs from their own history, including the cross-repo fact that a folder of separate projects ships together, which neither a per-repo language server nor a pushed-only code graph can represent. How the vault seeds itself →
The layer under all of them
Index the whole machine. Hand it to every agent.
Interlinked is not a language server and does not pretend to be: no types, no symbol graph, no semantics. It is the other half of the picture: a fast, literal, always-fresh index of every file on the machine, names and contents, across every repo and the non-git 90%, exposed to whatever agent you use through one connector. When your agent needs go-to-definition inside the open repo, the language server is right. When it needs "where does this exact name appear anywhere on this machine" (across repos, in the configs, in the docs, or with no server running at all), this is the floor it stands on, and it answers before a language server has finished warming up.
A single filename lands in 85 µs, 139 µs at the median across all 4.47M files. That same lookup takes VS Code's own search about 35 seconds on this machine (412,000× slower) and Windows Search a median 67 seconds (~480,000×). Content search runs in the 7 to 9 ms range. A saved edit is searchable in about a millisecond, under 30 ms worst case. At rest the whole engine sits around 44 MB in Task Manager, and the index on disk stays under 1% of the drive. It never leaves the machine, and there is no model anywhere in the box.
NOT A REPLACEMENT FOR YOUR LANGUAGE SERVER: THE LITERAL, WHOLE-MACHINE LAYER UNDER EVERY AGENT AND EDITOR.
Give every agent the whole map
Keep your language servers. Add the rest of your machine.
One signed installer indexes every file on your machine and wires up the AI clients you already use: no JSON editing, no cloud account, no keys. Your editors keep their deep, semantic view of the open project; every agent also gets a fast, literal, whole-machine search alongside it. Then ask any of them "where does this name show up across everything I have?" and see how much lived outside the circle.
Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo. Download for Windows · How Cursor indexes your codebase