Cursor adds Instant Grep: 13ms regex search across millions of files

• Cursor shipped Instant Grep, a local regex search index that can search “millions of files” in milliseconds and is now wired into the editor to speed up agent task completion, according to Cursor's launch thread.
• The headline benchmark in Cursor's writeup cuts a Chromium search for MAX_FILE_SIZE from 16.8s with ripgrep to 13ms locally, or 243ms with a network roundtrip, as shown in the benchmark summary.
• Cursor says the speedup comes from candidate filtering rather than a new regex engine: Instant Grep uses n-grams, inverted indexes, and Bloom filters so it avoids opening most files before running the real match, per the technical post.
• The design is explicitly aimed at agent workloads on very large repos, where users may have limited hardware and “agents will run way crazier regexes than you will by hand,” as one practitioner reply put it.

Cursor's launch thread says Instant Grep is now part of Cursor and lets the editor search across “millions of files” in milliseconds. The company ties that directly to agent performance: faster grep means agents spend less time blocked on code retrieval and more time executing tasks.

The attached technical writeup makes the target use case explicit. Regex search still matters for queries that syntax-aware indexes and LSP-based navigation do not cover well, especially in monorepos where plain ripgrep can take “over 15 seconds” on large projects technical writeup.

The benchmark circulating with the launch uses a Chromium query on an Apple MacBook M2. In that test, the chart shows Instant Grep at 13ms, Instant Grep plus a us-east-1 roundtrip at 243ms, and ripgrep at 16.8s.

Cursor's technical post describes Instant Grep as a local text index built for regex retrieval. The core idea is to precompute an inverted index over character-level fragments, then decompose an incoming regex into pieces that are likely required, fetch only files containing those fragments, and run the real regex engine on that smaller candidate set.

That matters because, as Rohan Paul's summary notes, the system is “not mainly a faster regex matcher” so much as a better candidate finder. The writeup starts from classic trigrams, then moves to sparse n-grams to reduce index noise and size while preserving filtering power technical post.

The harder problem is query decomposition. A quoted excerpt from the post says simple heuristics produce too many candidate documents, while complex heuristics can require loading “dozens — perhaps hundreds” of trigrams, erasing the win. Cursor's answer is a weighted sparse n-gram scheme plus Bloom filters to sharpen lookups before disk reads benchmark summary.

The systems design is as important as the indexing theory. The technical summary says the index stays on the developer's machine for freshness and latency, keyed off a Git commit plus a live-change layer, with posting lists on disk and a compact memory-mapped lookup table. That makes repeated agent searches cheap enough to sit inside the edit-search-edit loop instead of feeling like a remote retrieval step.

Practitioner responses also framed the constraints more broadly than “use a trigram index.” In one reply, Jediah Katz argues the real challenge is balancing disk usage, weak client hardware, extremely large repos, and regexes generated by agents rather than humans. A separate reply from Yacine MTB says similar laptop-local systems can hit “sub 50ms keystroke search” on a large codebase, which reinforces that the differentiator here is productizing that class of index inside an AI-native editor.

If Cursor's benchmark holds up across real monorepos, Instant Grep removes one of the quiet bottlenecks in agentic coding: broad text retrieval that is too fuzzy for symbol search but too frequent to tolerate multi-second scans developer reaction.