Explainers · measured July 2026 · 8 min read
What is cold start in search? Why the first query is always the slow one.
You have felt this without naming it. The first search after you open an app, reboot, or come back from lunch is sluggish; run the very same search again and it snaps back instantly. That gap is cold start. The catch: for the tools your AI agent actually reaches for (ripgrep, Windows Search) that gap is not a one-time toll. They pay it on nearly every query, because the warmth that made the second search fast evaporates the moment the command exits or a file changes.
There is a way to never pay it: keep the index resident: alive in memory, in the background, warmed once before you ever type. Then the first query of the day is exactly as fast as the thousandth. On a real 4.47-million-file machine that is the difference between 93.8 seconds and 16 milliseconds: a lost train of thought against a single frame of video.
The definition
A tax on the first read, not on the search itself.
Cold start in search is the extra delay a search tool pays on its first query (before its caches are warm) when it has to load and read data from disk from scratch instead of from memory it has already built up. The name is borrowed from a cold engine on a winter morning: nothing is warmed up yet, so the first attempt is the slow one. In search, “warm” means the data you need is already sitting in fast memory: the operating system's file cache, or the tool's own in-memory structures. “Cold” means none of it is, so the first query has to fetch and build everything before it can answer.
The definition. Cold start is the extra slowness a search pays on its first query (before any cache is warm) when it has to read from disk from scratch instead of from memory it already holds.
Warm is temporary. The second identical search is quicker because the data is now cached in RAM. That warmth dies the moment the command exits, a file changes, or the memory is needed elsewhere.
Unindexed tools pay it again and again. grep and ripgrep start a fresh process every time and keep no index, so they re-read from scratch. Windows Search runs its index behind and falls back to a slow path, so real whole-machine queries pay the cold cost over and over.
The numbers. On a 4.47-million-file machine, a from-scratch content scan takes 93.8 seconds; the same query against a resident index returns in 16 milliseconds. A filename lookup is 85 microseconds, and the first of the day is as fast as the thousandth.
The fix is residency. An index that lives in memory in the background is warmed once, before you ask, so there is no first-query tax, ever. Interlinked keeps one over your whole machine.
The whole game is who pays this tax, and how often. A scan pays it on every query. A tool that leans on a cache pays it again every time the cache is lost. A resident index pays it once, at startup, in the background, where nobody is waiting.
The three regimes, drawn
Cold every time. Warm for a moment. Or warm for good.
Watch the same six searches run three ways. Up top, an unindexed scan: every query reads the disk from scratch, so every bar is full height. In the middle, a tool that leans on the cache: the first query is cold, the next two are warm and quick, and then something ordinary happens (you open a new shell, you save a file, the memory gets reused) and the warmth is gone, so the next query is full height again. At the bottom, a resident index: warmed once in the background before you ever ask, so every bar is short and identical.
Height is time. The unindexed lane pays the full read on all six queries; the cached lane pays it again whenever its warmth is lost; the resident lane paid once, at startup, and never again. Same machine, same files, same query. Measured on a Ryzen 9 9950X3D with 4.47M files.
Who pays, and when
Same query. Wildly different bills.
Every popular search tool falls into one of the three regimes above. The difference is not how clever the scan is (ripgrep's is superb), it is whether any warmth survives between your queries. Measured on one real machine:
| The tool | What stays warm | Pays cold start… | On 4.47M files |
|---|---|---|---|
| grep / ripgrep | Nothing persistent: a fresh process, no index | On every query | 93.8 s |
| VS Code search | The folder you opened, for the session | First query, and anything outside that folder | 35 s |
| Windows Search | A background index, kept partial and behind | On misses and whole-machine queries | 67 s |
| Interlinked | The whole-machine index, always in memory | Never (warmed once at startup) | 85 µs / 16 ms |
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. The 93.8 s is one content query read from scratch; the resident index answered the same query in 16 ms (58,625× faster across the five-query set). Filename look-ups are an 85 µs single-file result and a 139 µs median across 20 queries (2 µs best case), against 35 s for VS Code's Ctrl+P and a 67 s Windows Search median. Full per-tool method in the ripgrep comparison, the VS Code write-up, and the Windows Search breakdown.
Why the warmth keeps vanishing
Three kinds of warm. All three are fragile.
“Warm” is not one thing. There are three ways a search tool can have your data ready in fast memory, and each one loses it in its own way, which is exactly why unindexed tools keep paying the cold-start tax:
The operating system's file cache.
After a tool reads a file, the OS keeps a copy in spare RAM, so the next read is quick. This is why the second ripgrep run feels faster. But it is spare RAM: the moment another program needs it, your files are evicted. And a 4.47-million-file machine is far too big to hold in cache at once, so most real queries land on data that was never warm to begin with.
The tool's own memory, for one run.
A command like grep or ripgrep builds up state while it works, then exits, and all of it is gone. The next invocation starts cold, from zero, no matter how fast the last one was. There is nothing to inherit.
A lazily-built index that drifts.
Windows Search and Spotlight keep an index between runs, which is the right idea. But it is maintained in the background at low priority and allowed to fall behind, so a query for something recent, or something the index skipped, falls through to a slow path. Fast on a lucky hit, slow the rest of the time.
Notice the pattern: in every case the warmth is a side effect, not a guarantee. It exists right up until the moment you actually need it, and then, often, it doesn't. This is the same reason editor search feels like it slows down as your project grows: there is simply more to re-read cold.
The fourth option
Warm it once. Keep it warm for good.
This is the whole idea behind Interlinked. Instead of hoping the cache is warm, or rebuilding a scan every run, it keeps a live index of your whole machine resident in memory: a background service that warms up once, stays up, and rides the filesystem's own change notifications so it never drifts. The first query after a reboot is the same speed as the thousandth that afternoon, because nothing about “warm” is left to chance. There is no cold start to pay, because the warming already happened, in the background, before you asked.
And there is no model in the loop: no embeddings, no cloud round-trip, nothing to guess. The whole engine sits around 44 MB at rest, less than a single browser tab, and the index takes under 1% of the drive. It is the always-warm floor every AI agent stands on, the larger story in the backbone of the LLM economy. For the speed head to head, indexed vs unindexed search plots the whole ladder.
Questions people ask
Cold start, answered.
Is cold start the same as a cold cache?
Closely related. A cold cache (empty fast memory) is the usual cause, but the term covers any first-request slowness before a system reaches its steady, warmed-up speed: caches to fill, indexes to load, connections to open. In file search the dominant cost is the cold operating-system file cache plus a missing in-memory index.
Why is ripgrep slow the first time and fast the second?
Because the first run pulls every file off the disk, and the operating system then keeps those files in spare RAM, so an identical second run reads them from memory instead. It is real, and it is why ripgrep feels quick in a tight loop. It just doesn't hold on a real machine: the working set is far bigger than RAM, the cache is evicted the moment something else needs it, and ripgrep keeps no index, so it re-scans from scratch whenever the warmth is gone. The full numbers are in content search vs ripgrep.
Does a faster SSD get rid of cold start?
It shrinks it; it does not remove it. A quick NVMe drive makes the cold read less painful, but reading four-million-plus files is still work measured in tens of seconds, and memory is still thousands of times faster than any disk. The only way to make the first query as fast as the hundredth is to not touch the disk on the query at all, which means answering from a resident index.
Does Windows Search have cold start if it is already indexed?
In practice, yes: on the queries that matter. It keeps an index, but the index is maintained in the background at low priority and allowed to fall behind, and the query path itself is not kept hot for whole-machine questions. On a real 4.47-million-file drive its median query was 67 seconds. A resident index answers the same class of question in microseconds.
How does a resident index avoid cold start entirely?
By moving the warm-up off the query path. A background service reads the machine once, holds the index in memory, and keeps it live as files change, so by the time you search, everything is already warm and you are never the one waiting for the cache to fill. That is why the first query of the day and the thousandth cost the same 85 microseconds. More on the mechanics in what is file indexing.
Never pay the first-query tax again
Warm your whole machine, once.
Install once. One signed installer wires up 19 AI clients: Claude Code, Cursor, Copilot, Codex, Windsurf, Zed and the rest. No JSON to edit.
Let it warm up. It reads the disk once in the background. Filename search works immediately; content fills in behind it. From then on the index is resident: every query is warm before you ask.
Keep grep for one file. It stays perfect for a single file or a live pipe. The resident index just answers first on the whole-machine questions that would otherwise start cold every time.
It stays live. Save a file and it is searchable again in about a millisecond, so the index is always both warm and correct. At rest the whole engine sits around 44 MB.
Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows.