Interlinked.

Guides · measured July 2026

How to find every place a function is used.

There are two honest answers, and they are not the same. Your editor's Find All References lists the call sites it can resolve: precise, but only inside the one project it loaded. ripgrep finds every literal mention, but only in the folder you aim it at, false matches included. The real answer spans your whole machine. This is how to get it right, and why the same search that takes ripgrep 93.8 seconds across a 4.47-million-file drive can return in 16 milliseconds.

TL;DR: the short version
  • Two honest answers to “where is a function used”: Find All References (semantic and precise, but only inside the one project your editor loaded) and a literal name search for everywhere else: sibling repos, configs, CI, scripts, docs. The complete answer needs both.
  • Find All References has a structural blind spot. Any usage outside the project boundary (a sibling repo, a deploy script, an other-language binding, the docs) is invisible to it, and that is where a refactor the editor calls “complete” still breaks the build.
  • The wide, literal net is ripgrep’s idea, but it walks the disk on every run and only the folder you aim it at, about 93.8 seconds per repo across a 4.47-million-file machine.
  • Interlinked answers that same usage search from a warm whole-machine index in 16 ms across all 4.47M files, ranks real code above comments and strings, and stays fresh: a save is searchable in about 1 ms.
  • The order that catches everything: semantic first (Find All References), then one whole-machine literal search. Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo.

References vs usages

Two searches. Two different answers.

References are the call sites your language server can resolve: semantic, precise, and confined to the project it loaded. Usages are every place the name actually appears (across languages, repos, configs and docs), which is a text search. Read the diagram outward: the language server sees the inner ring; ripgrep can reach the middle ring if you point it there; the truth lives in the outer one.

THE WHOLE MACHINE4.47M files · every repo, config, script & doc: indexed, answered in ~16 msTHE REPO SUBTREEripgrep · grep: literal text, any language, but only where you point itTHE PROJECTVS Code · Find All References (Shift+F12): semantic, resolved, in-project onlyvalidateLicense()defined onceimportcall siteunit testcall sitea call in another module×// named in a commentsibling repo · imports itbuild.sh · calls the CLIREADME · documents itgit-ignored build outputCI · deploy.yml names it
a real usage of the function
a literal match that is not a usage: a comment, a string, a different symbol with the same name
resolved by the language server: a semantic reference

Find All References returns the inner ring, precisely. ripgrep can reach further, but only where you aim it, and it counts the false matches too. The complete answer, every genuine usage and no phantom ones, needs a literal search across the whole machine, with the real code ranked above the comments and strings.

The in-project trap

Find All References tells the truth. About one project.

It is genuinely the right tool for what it does. The language server resolves the symbol semantically: it knows your parse() from a different parse() two packages over, follows the imports, and skips the comment that merely names it. Keep using it. Just know its edge: it only knows the files it loaded (your open project, in one language). A function's reach does not respect that boundary. These are the usages it structurally cannot see:

OUT OF PROJECT SCOPE
A sibling repo that imports the built package
OUT OF PROJECT SCOPE
A CI or deploy file that calls it by name
OUT OF PROJECT SCOPE
A binding or wrapper in another language
OUT OF PROJECT SCOPE
A shell script, Makefile, or task runner
OUT OF PROJECT SCOPE
The docs and examples that reference the API
OUT OF PROJECT SCOPE
Generated or git-ignored build output

This is where the refactor that "caught them all" still breaks the build. You rename the function, the editor shows zero remaining references, and a sibling repo that imported the package (or a deploy script that called it by name) was never in the room. The precise answer was complete. It was just complete for the wrong scope.

Same machine · same drive · same symbol

The wide net is right. The disk walk is the problem.

ripgrep has the correct idea for the second answer: literal, language-agnostic, blind to no file type. The only trouble is mechanical: it walks the filesystem on every run, and it only searches the tree you point it at, so covering a whole machine means running it again in every repo. At 4.47M files, that walk stops being instant. Here is the same "where is this symbol used" question, timed different ways on one machine.

The searcherThe usage search it runsTime · 4.47M filesvs Interlinked
Interlinkedone indexed literal query, whole machine16 ms
ripgrepliteral content walk of the tree93.8 s58,625× *
Claude Code · one lookupgrep + read, no index3 m 13 s2,276,000× †
Claude Code · full run71 calls to be sure6 m 57 s~7,200,000× †

Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Interlinked on the same corpus: a filename lookup lands in 85 μs (139 μs median of 20); a whole-machine content query runs in about 7 to 9 ms. * 58,625× is the average across the content set; on the single query shown, ripgrep's 93.8 s collapses to 16 ms. † end-to-end Claude Code runs: the single lookup measured against Interlinked's 85 μs indexed answer (2,276,000×), the full run against one indexed call. VS Code's own file-open search is timed in the 412,000× write-up and the ripgrep comparison in the ripgrep write-up.

The everywhere-else tier, done right

Keep your language server. Fix the outer ring.

Interlinked does not replace Find All References: it finishes the job it can't. It keeps one warm, whole-machine index of every filename and every file's contents, so the literal usage search (the slow, per-repo ripgrep step) becomes a single query across all 4.47M files, answered in milliseconds and kept fresh as you type. And because it ranks genuine code above comments and strings, the noise the false matches added sinks to the bottom instead of padding your results.

16 ms
the 93.8 s ripgrep query, answered from the warm index (single query, this machine)
7 to 9 ms
a typical whole-machine content query, up to ~16 ms for an exact phrase
~1 ms
a save becomes searchable that fast (under 30 ms worst case), so the index is never stale
4.47M files
the reach: every repo, config, script and doc, not the one folder you aimed a tool at

The result can carry more than a list of files, too. The deeper question under "where is this used" is "what do I have to change with it", and the same index derives that. On a fresh machine it built 26,958 relationship pairs from 8,455 git events across all 12 repos in 1.7 seconds, so a usage result can arrive already knowing which files historically moved together with the one you touched.

NO MODEL IN THE LOOP: LITERAL SEARCH, INDEXED · CODE RANKED ABOVE COMMENTS & STRINGS · EVERY ANSWER STAYS ON YOUR MACHINE.

Common questions

Finding where a function is used, answered.

What is the difference between “references” and “usages”?

References are the call sites your language server resolves semantically: precise, but confined to the one project it loaded. Usages are every place the name actually appears (across languages, repos, configs and docs), which is a literal text search. The complete answer to “where is this used” needs both.

Why doesn’t Find All References catch every usage?

It only knows the files it loaded: your open project, in one language. A sibling repo that imports the package, a CI file that calls the function by name, a shell script, or the docs all sit outside that boundary, so it structurally cannot see them. That blind spot is where a rename the editor reported as complete still breaks the build.

Isn’t ripgrep enough to search the whole machine?

ripgrep has the right idea (literal, language-agnostic, blind to no file type), but it walks the filesystem on every run and only the tree you point it at, so covering a whole machine means re-running it in every repo. Across a 4.47-million-file machine that walk takes about 93.8 seconds, false matches like comments and strings included.

How does Interlinked make the same search instant?

There is no model in the loop and nothing leaves your machine: it keeps one warm, always-fresh index of every filename and file’s contents, so a whole-machine literal search is a single query instead of a disk walk. The 93.8-second ripgrep query returns in 16 ms with real code ranked above comments and strings, and a save is searchable in about 1 ms. For an agent the gap compounds: a lookup that would take 71 grep-and-read calls over 6m57s becomes one 16 ms call.

What does Interlinked cost?

Everything (including the machine-wide search wired into 19 AI clients, no keys) is free forever, on all your devices, no card. Hosting starts at $5.99/mo.

The workflow

Find every usage, in the right order.

1

Start semantic. Find All References (Shift+F12) gives you the precise in-project set: it resolves through imports and will not confuse your symbol with a same-named one elsewhere. This part, the language server does better than any text search.

2

Then go wide. Run a literal search for the name across everything the project boundary excludes: sibling repos, configs, CI, scripts, docs, generated code. This is the step people skip, and it is exactly where a refactor that looked complete quietly breaks something.

3

Make step two instant. With Interlinked, that machine-wide literal search is one call your agent makes automatically. 4.47M files, milliseconds, real code ranked above comments and strings, and always fresh: a save is searchable in about a millisecond.

4

Ask what moves with it. Beyond the mentions, the deeper question behind “where is this used” is “what do I have to change with it.” Co-change relationships surface the files that historically moved alongside it: the usages that matter most in a refactor.

One signed installer wires the machine-wide search into 19 AI clients (Claude Code, Cursor, Copilot, Codex, Windsurf, Zed, Cline and the rest) with no JSON editing and no keys. Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows.

Measured July 2026 · Ryzen 9 9950X3D · 4.47M files · Windows 11← All research