Comparisons · measured July 2026
Your agent searches hundreds of times a task. Cloud makes it wait for the network. Local is already in the room.
Every retrieval tool makes one architectural choice: where the index lives. Put it on a server (the model behind Sourcegraph and other cloud code search) and your code travels to it, and every query round-trips the network. Keep it on the machine and the index sits on the same disk as the files, so nothing crosses the line. That one choice sets four things an agent feels on every single call: privacy, speed, freshness, and cost. Here is the picture, the numbers, and exactly where each side wins.
The short version
Two places to put an index. Only one is on the machine.
Local code search is retrieval that runs entirely on the machine holding the files: the index sits on the same disk as the code, and a query never crosses the network. Cloud code search is retrieval where the index lives on a server: your code is copied to it, and every query round-trips over the network to reach it.
Both are legitimate. The right one depends on whose answer it is, and, increasingly, on who is asking. We go product-by-product on the two famous server-side tools in Sourcegraph vs a local index.
Local keeps the index on your disk beside the files; cloud keeps it on a server your code is copied to.
On the four axes that matter to an agent (privacy, speed, freshness, cost), local wins for the machine in front of you.
Speed: a local lookup lands in 85 microseconds on 4.47M files; a cloud query can't beat the network round-trip, tens of milliseconds before the search even starts.
Freshness: local is searchable ~1 ms after you save; a server is only as fresh as its last crawl or push.
Agents multiply the gap: they query hundreds of times per task, so every round-trip, stale answer, and per-seat fee compounds.
The picture
One query, two paths. Resident, or round-trip.
The agent is the same in both designs. The only difference is what happens when it asks. Cloud search sends the query out of the machine, across the network, into a server, and waits for the answer to come all the way back: a round-trip whose floor is set by physics, not by how fast the server is. A local index sits beside the code, so the same question is a short hop that never leaves the disk.
The fastest datacenter on earth still can't delete the round-trip: the query has to reach it and the answer has to return. Local has zero of that: the index is already in the room.
The four axes an agent feels
Privacy, speed, freshness, cost: line by line.
| The axis | Cloud code search | Local code search | Wins for an agent |
|---|---|---|---|
| Privacy | code is copied to a server to be indexed | the index never leaves the disk · works offline | LOCAL |
| Speed | a network round-trip on every query | 85 µs single file · 139 µs median | LOCAL |
| Freshness | only as fresh as the last crawl or push | ~1 ms after save · under 30 ms worst | LOCAL |
| Cost | per seat, per month, plus servers kept warm | free on every machine · no server to run | LOCAL |
| Coverage | the pushed / synced repositories | every repo + the non-git 90% of the disk | LOCAL |
| Shared knowledge | one canonical index the whole org queries | this machine only | CLOUD |
Speed and freshness figures measured on Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. A single file lands in 85 µs (best case 2 µs); 139 µs is the median across 20 queries over the whole machine. “Non-git 90%” is the configs, documents, and downloads that were never in a repository. Full single-file methodology in the VS Code comparison.
Why agents change the math
A human searches sometimes. An agent searches constantly.
A person runs a search now and then, reads the result, and moves on. An agent does it hundreds of times inside a single task, so an architecture that is merely “fine” for a human becomes the bottleneck for an agent. Five things multiply by that frequency:
Frequency taxes the round-trip. An agent doesn’t search once; it searches its way to an answer. We watched Claude Code spend 6 minutes 57 seconds across 71 tool calls just to locate one file without an index: the difference between brewing a pot of coffee and a single blink. Every one of those calls that round-trips a cloud pays the network tax again.
The latency floor is physics. The fastest server still can’t beat the speed of the round-trip: the query must leave the machine and the answer must return. That’s tens of milliseconds of travel before any search happens, an eternity when you do it hundreds of times a task. A resident index has none of it; a single file lands in 85 microseconds.
Agents edit as they work. An agent changes files mid-task, then searches again. A cloud index is stale until the next crawl or push, so the agent can retrieve a version that no longer exists on disk. A local index is about a millisecond behind the live file (under 30 ms in the worst case), so it always searches what’s actually there.
The cost shape is backwards for agents. Cloud code search bills per seat, per month, plus servers kept warm. Agents are cheap to run but query relentlessly, so a metered, round-tripped path taxes the exact thing they do most. Local has no seats and no server to keep warm, so the frequency is free.
Agents touch everything. To finish a task an agent reads secrets, configs, and the non-git 90% of the disk. With cloud search, indexing means copying that content to a server. With a local index, none of it ever leaves the machine: there is no model in the box and no upload, just a lookup.
Stack those together and the same hunt (6m57s across 71 tool calls) collapses to one 16-millisecond call, about 7,200,000× less effort spent finding instead of thinking. In that measured run roughly 58% of the session's tokens (more than half the bill) went to file hunting; with the index it drops to nearly none. The full teardown is in the backbone of the LLM economy.
Where cloud still wins
This isn't a teardown. A server wins when the answer is shared.
Sourcegraph built its name on cross-repository code search: point it at an organisation's repositories and it indexes them on a server, so a whole team gets one canonical, permission-aware view: go-to-definition, find-references, and search that spans every repo, from one place. When the answer has to be the same for everyone and consistent across machines, that shared shape is exactly right, and a local per-machine index can't replace it.
A local index answers a different question: “what's on this machine, right now?”, the working copy you haven't pushed, the files that were never in git, and the answer that has to be fresh this second for the agent in front of you. Different scopes, not a contest. Keep the cloud index for the org; add a local one for the machine.
The local index, measured
Everything a server can't reach, answered where it already is.
Interlinked keeps an always-fresh index of every file on the machine (names and contents, across every repo and the non-git 90%) and hands it to whatever agent you use through one connector. It never leaves the machine, and there is no model anywhere in the box: every result is a lookup, not a guess. Here is what that costs and delivers, measured on the machine below.
For contrast, Windows Search takes 67 seconds median on this same drive, about 480,000× slower than the 139 µs median, a blink versus a minute at the coffee machine. Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4.47M files. Full write-ups: the ripgrep comparison and how the vault seeds itself.
CLOUD FOR THE ORG'S SHARED KNOWLEDGE. LOCAL FOR THE MACHINE YOUR AGENTS RUN ON: LIVE, PRIVATE, IN MICROSECONDS.
Questions people ask
Local vs cloud, answered.
Is local code search more private than cloud?
Yes. With local search the index sits on the same disk as your code and a query never crosses the network, so nothing is copied to a third-party server and it works fully offline. Cloud code search copies your code to a server in order to index it.
Is local search actually faster than cloud?
For a single lookup, yes and by a wide margin: 85 microseconds locally on a 4.47M-file machine, versus a cloud query that must round-trip the network (tens of milliseconds of travel) before the server even starts searching. The gap is physics, not tuning.
Does cloud code search ever win?
Yes: when the answer must be shared. A server index like Sourcegraph gives a whole team one canonical, permission-aware view across every repository. For org-wide knowledge that is the right shape; for the machine in front of a single agent, local is.
Why does this matter more for AI agents than for people?
A person searches occasionally; an agent searches hundreds of times per task. Every round-trip, every stale answer, and every per-seat fee is multiplied by that frequency, so the architecture that is merely fine for a human becomes the bottleneck for an agent.
Can I use both?
Yes. Keep your team’s cloud code search for shared knowledge and add a local index for the live, private machine your agents run on. They are different layers of the same stack, not competitors.
Add the machine in front of you
Keep your cloud search. Add a local index for your agents.
One signed installer indexes every file on your machine (names and contents, every repo plus the non-git 90%) and wires up the 19 AI clients you already use. No cloud account, no keys, no JSON editing, and nothing ever leaves the disk. Your team's server search keeps doing its job; every agent on your machine gets a fast, live, private index alongside it, answering in microseconds.
Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo. Download for Windows · How agents plug in (MCP) · The case for local-first