Explainers · measured July 2026 · 7 min read
What is a background service? The program that was already working before you asked.
Type into your Start menu or Spotlight and results appear before you finish the word. That speed is not the search being clever in the moment: it is a program that was already running, that did the reading hours ago and has been sitting there waiting for you. Turn that program off and the very same search crawls.
That difference (a program that never stops versus a command you launch and it exits) is the whole story of fast search. This page defines the background service (its Unix name is daemon), shows why a warm one beats a cold scan, and measures the gap on a real machine: 85 microseconds against 35 seconds for the same lookup.
The definition
A process that never sleeps, so your query never waits.
A background service is a long-running program that the operating system starts on its own and keeps running in the background (with no window and nobody watching) so that the work it does is finished and waiting the moment you need it. On Unix, Linux, and macOS the same thing is called a daemon (a term from 1960s MIT computing, for a helper that toils away unseen); on Windows it is a service. Different names, one idea. It is the opposite of a command you type, which is born when you press Enter and dies when it prints its answer.
The definition. A background service (a daemon on Unix and macOS, a service on Windows) is a program the operating system keeps running in the background, with no window, so its work is finished and waiting the moment you need it.
Why search needs one. A search is only instant if the reading was done ahead of time. A warm service holds the index in memory and answers with a lookup; a cold command re-reads the disk from scratch on every query.
The measured gap. On a 4.47-million-file machine, a warm service returns a filename in 85 µs where a cold VS Code search takes 35 s: 412,000×, the difference between a blink and reaching for your coffee.
The objection, answered. Always-on sounds heavy. At rest the whole engine sits around 44 MB (less than one browser tab) and does its reading when nothing is waiting.
You already run one. Windows Search is a background service backed by a database. The design is proven; the trouble is its warm index is slow and partial. Interlinked is the same shape, done fast, across the whole machine.
The trade is simple. A service pays a small, permanent price (a little memory to stay resident) and in return every request is already half-answered before it arrives. A cold command pays nothing while it sits idle, then pays the full cost on every single query, forever.
The two shapes, drawn
One starts from zero, every time. One never left.
Follow the two lanes along the same clock. On top, a cold command is born for each query: it spins up, reads the whole disk, answers, and exits, keeping nothing, so the next query repeats all of it. On the bottom, a warm service was already running before the first query even arrived (the arrow enters from “since boot”); it holds the index in memory and never exits, so each query is a small lookup with no launch and no scan.
The cost of a cold start is set by the size of your disk: it re-reads everything each time (93.8 s here). The cost of a warm lookup is set only by the number of matches (85 µs for a name, 16 ms for a content match). By the time the cold command finishes reading the disk once, the warm service has answered thousands of queries and stayed fresh through all of them.
Same machine · same drive · same questions
Launched fresh, or already warm.
Line the two shapes up property by property and the difference stops being abstract. The top four rows are what each is; the middle two are what each costs, measured on one real machine; the bottom two are the honest trade: a warm service does spend a little memory while it waits.
| What happens | Cold-start command | Warm background service |
|---|---|---|
| Who starts it | You, every single query | The operating system, once at boot |
| When it runs | Only while the query runs | Always, quietly, in the background |
| Has a window | Yes: you launched it | No: it is headless |
| On each query | Launch, read the disk, exit | Answer from an index already in memory |
| Find a file by name* | 35 s · 67 s | 85 µs · 139 µs median up to ~480,000× faster |
| Find a word in files* | 93.8 s | 16 ms 58,625× across the set |
| Memory at rest | 0, nothing running | ~44 MB, one browser tab |
| Freshness | Always live: it re-reads | ~1 ms behind your last save |
*Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Filename figures are 85 µs for a single file and a 139 µs median across 20 queries (2 µs best case); the cold column shows VS Code (35 s) and Windows Search (67 s median). The content row is one query where grep read for 93.8 s and the warm index answered in 16 ms; across the five-query content set the lookup averaged 58,625× faster. Full method in the VS Code write-up and the ripgrep comparison.
The catch everyone worries about
Always on sounds expensive. Measured, it's a rounding error.
The fair objection to any background service is that a program which never stops must be eating your machine while you are not looking. It is worth checking rather than assuming. A resident search index has two costs: the memory it holds to stay warm, and the space its map takes on disk. Both are smaller than a habit you would not think twice about.
And crucially, a well-built service does its heavy reading when nothing is waiting on it, so the moments you actually notice, the ones where you asked a question, are the moments it does the least work. You feel the payoff and never the price.
A warm service for the whole machine
The idea behind Windows Search, done fast.
You already trust this shape. Windows Search and Spotlight are background services backed by a database, running right now behind everything you do. Interlinked is the same shape with the slow parts fixed: one small always-on service that keeps a live index of every file's name and contents across the entire machine (every repo, plus the roughly 90% of the disk that was never in git: configs, documents, downloads, the PDF with the answer). Names come back in microseconds, contents in milliseconds, and the map stays a millisecond behind your last save.
And there is no model in the loop: no embeddings, no guessing, no cloud round-trip. A lookup is a lookup: a word or a name, a row, a list of files. Everything stays on the machine; nothing leaves. It is the same warm floor every AI agent stands on, which is the larger story in the backbone of the LLM economy.
THE SAME ALWAYS-ON SERVICE ALSO LEARNS HOW YOUR FILES RELATE: WHICH CHANGE TOGETHER, WHICH REPOS SHIP AS ONE. NO MODEL. NO GUESS.
Questions people ask
Background services, answered.
What is the difference between a daemon and a service?
Almost none: they are the same idea under two names. Daemon is the Unix, Linux, and macOS word; service is the Windows word for a program the operating system starts and keeps running for you. Both are long-running, have no window, and are already alive when your request arrives. macOS also calls some of them “agents.” The concept is identical: a process that never sleeps so your query never waits.
Is Windows Search a background service?
Yes. Windows Search runs continuously as a background service and stores what it finds in an index (effectively a database on disk) which is exactly the right design. The trouble is the payoff: on a real 4.47-million-file drive it returned a median query in 67 seconds, because its warm index is slow to answer and does not cover the whole machine. A good background service answers the same question in microseconds.
Does a background service slow down my computer?
A well-built one barely registers. Interlinked's sits around 44 MB at rest (less than a single browser tab) and does its reading when nothing is waiting on it. The trade is a few megabytes of idle memory in exchange for answers that are already done. A cold command uses nothing while idle and then makes you pay the full cost on every query instead.
Why can't search just run when I ask for it?
Because reading the disk is the slow part, and a cold command has to do it every time. Starting fresh means launching a process and walking millions of files before it can answer: 35 s in VS Code, 93.8 s for grep on this machine. A warm service already read everything once, so the query becomes a lookup instead of a walk. That is the whole case for indexing ahead of time.
What does a background service have to do with AI agents?
An agent asks the filesystem constantly (which file, which function, what changed since last time) and every one of those is a search. A background service answers them in microseconds through an MCP connection instead of making the agent launch a fresh scan each time. That warm floor is the larger story in the backbone of the LLM economy.
Put a warm service on your machine
Stop launching search. Keep it running.
Install once. One signed installer starts the background service and wires up 19 AI clients: Claude Code, Cursor, Copilot, Codex, Windsurf, Zed and the rest. No JSON to edit, no keys.
Let it warm up. It reads the disk once, in the background, when nothing is waiting. Filename search works immediately; content fills in behind it. From then on every query is a lookup, not a launch.
Keep grep for one file. A cold command stays perfect for a single file or a pipe. The warm service just answers first on the whole-machine questions that would otherwise cost a full scan.
Trust it fresh. Save a file and it is searchable again in about a millisecond. At rest the whole 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.