Explainers · updated July 2026 · 7 min
What is fuzzy file finding? Type a fragment, get the file.
It is the trick behind VS Code's Ctrl+P and the command-line favourite fzf: type a loose fragment of a name (the right letters, in order, gaps allowed) and the tool ranks the files that contain it, best guess first. No exact spelling, no full path, no remembering which folder. Here is what it actually is, why it feels like magic, and the one place it runs out of road.
letters in order · gaps allowed · the file you meant, first
TL;DR · the short version
- 01Fuzzy finding is matching plus ranking: your typed letters must appear in order, gaps allowed. The real work is the ranking, so the file you meant lands first from three or four keystrokes.
- 02Ctrl+P and fzf nailed the gesture but share one limit: the list they match is small and already in hand (the open folder, or whatever you pipe in). Reaching the whole machine means walking the disk first.
- 03Pre-build the list instead: Interlinked keeps every filename indexed and fresh, so a whole-machine lookup is 85 µs for one file (139 µs median across 4.47M), about 412,000× faster than a VS Code drive search, ~480,000× vs Windows Search.
- 04Content search rides the same index at 7-9 ms, where ripgrep goes 93.8 s cold → 16 ms warm (58,625×); a 6m57s, 71-call agent grep collapses to one 16 ms call.
- 05Everything local is free forever, no card. Hosting starts at $5.99/mo. Around 44 MB at rest, ~1 ms freshness, and the index never leaves the machine.
The mechanism, drawn plainly
Letters in order. Gaps allowed.
A fuzzy matcher keeps a file if your typed letters appear in its name in the same order, not necessarily next to each other. ucontr keeps UserController because u, c, o, n, t, r all show up in sequence. That is called a subsequence match, and on its own it would keep hundreds of files.
So the real work is ranking. A good matcher rewards letters that land consecutively, that sit on a word or camelCase boundary, or that start a path segment, and it leans on how recently you touched the file. The payoff is that the file you meant is almost always the first row, from three or four keystrokes.
All three names match the fragment. The ranker prefers the one whose matched letters form a structured run over the ones where they merely happen to appear in order.
Why developers love it
Two tools made it muscle memory. Ctrl+P and fzf.
Fuzzy finding went from niche to universal on the back of two tools. Both are excellent. Both are worth keeping. And both share one quiet assumption we'll come back to.
Ctrl+P fuzzy-matches filenames across the folder you have open. Two keys, a fragment, Enter. You're in the file before you'd have reached for the mouse. It ships on by default in the most-used editor on earth, which is why the gesture is now everywhere.
fzf doesn't crawl anything itself. You pipe it a list (git ls-files, fd, your shell history, branch names) and it filters that list interactively as you type. Composable, fast on any list you hand it, and it turned the fuzzy pattern into a Unix primitive.
The shared assumption: the list you're matching against is small and already in hand. Ctrl+P holds the open folder; fzf holds whatever you piped in. That is exactly right for the job each was built for, and it is also where the edge falls.
Where it runs out of road
Fuzzy matching is instant. Getting the list isn't.
The matching was never the bottleneck: filtering a list of names against a fragment is trivially fast. The list is the cost. Ctrl+P matches the folder you opened and is blind to everything outside it. fzf matches whatever you pipe in, instantly; but to reach the whole machine, something has to produce that list first, and producing “every file on the disk” means walking the disk, a cost that grows with the drive and is paid again on every invocation. Drawn to scale, the three regimes look like this:
* Ctrl+P is instant inside a normal repo: its limit is scope, not speed. fzf's own matching is instant too; the cost is the enumerator (fd / find) walking the disk, which grows with the drive. Interlinked: 85 µs single lookup, 139 µs median of 20, on Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4.47M files.
The wall isn't your typing: it's the boundary of the list. Ctrl+P only holds the folder you opened, so a file two repos over simply isn't a candidate, no matter how well you type.
Pipe fd or find into fzf and you can reach anything, but you re-walk the tree every query, and on a real drive that walk is the slow part. The bigger the machine, the slower it gets.
Nothing says the candidate list has to be built at query time. Build it once, keep it fresh as files change, and whole-machine fuzzy finding becomes a lookup instead of a walk.
Same machine · same drive
The same “type a fragment, get the file,” across 4.47 million of them.
If the candidate list were the entire machine, and it already existed (no folder boundary, no walk to build it), then whole-machine fuzzy finding is just a lookup. On a real 4.47-million-file drive, that lookup lands in the microsecond range: 85 µs for a single file, 139 µs median across twenty queries.
| The tool | What it fuzzy-matches | Scope | One name lookup | vs Interlinked |
|---|---|---|---|---|
| Interlinked | loose filename fragments, rank-by-relevance | whole machine · every repo + non-git | 85 µs | 1× (baseline) |
| VS Code Ctrl+P | fuzzy filename, workspace only | the folder you opened | 35 s * | 412,000× |
| fzf + fd / find | fuzzy over a piped list | whatever you enumerate | disk-walk bound * | not measured |
| Windows Search | name / content, indexed subset | a subset of folders | 67 s | ~480,000× |
Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4.47M files. * Ctrl+P is instant inside a normal repo; the 35 s figure is VS Code searching the full 4.47M-file drive, the only way to make it whole-machine, for 412,000× (85 µs vs 35 s). fzf's matching is instant; the cost is the enumerator (fd / find) walking the disk, so its whole-machine time is bound by the walk, which grows with the drive. Windows Search is the median of 20 queries, 67 s, for ~480,000× (139 µs vs 67 s). More on the Ctrl+P boundary in why VS Code search stays slow and the full six-tool run in the 412,000× write-up.
Whole-machine, already listed
Keep the gesture. Lose the boundary.
Interlinked keeps an always-fresh index of every filename on the machine (across every repo and the non-git 90%) and answers loose, rank-by-relevance name queries out of it: the Ctrl+P feel, with the whole machine as the candidate list. There is no workspace to open and no disk to walk; the list is already built and kept current as files change. And because it speaks the same protocol every AI client uses, your agent gets the same instant fuzzy reach, not just you.
A saved file is findable by name in about a millisecond, under 30 ms in the worst case. At rest the whole engine sits around 44 MB in Task Manager (less than a browser tab) and the index takes under 1% of the drive. Nothing leaves the machine, and there is no model anywhere in the box.
NOT A WORKSPACE TOOL: THE WHOLE-MACHINE FUZZY LAYER UNDER EVERY EDITOR AND EVERY AGENT.
Keep your finders
Keep Ctrl+P. Keep fzf.
Install once. One signed installer wires up 19 AI clients (Claude Code, Cursor, Copilot, Codex, Windsurf, Zed and the rest) and starts indexing every filename on the machine. No JSON to edit.
Keep your finders. Ctrl+P and fzf stay exactly where they are, perfect inside a repo. The index just answers the same type-a-fragment query when the file lives anywhere else on the machine.
Let it stay fresh. Save or rename a file and it's findable again in about a millisecond. At rest the engine sits around 44 MB and the index takes under 1% of the drive.
Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows · What a codebase index can't see