#FFF: Fast File Search for AI Coding Agents

FFF is a file search toolkit built in Rust that keeps a warm index in memory, claiming sub-10-millisecond query times on repositories where each ripgrep invocation takes several seconds. It is designed for the specific workload of AI coding agents and editors that search the same repository hundreds of times in a single session.

#What it is

FFF, short for "Fast File Finder," is a file and content search toolkit designed for both humans and AI agents. Unlike traditional search tools that spawn a new process and scan the filesystem for each query, FFF maintains a long-lived process that holds an index and cache in memory. A background watcher updates the index as files change, so subsequent queries do not need to rescan the entire repository.

The toolkit exposes path search, content search (grep), fuzzy matching, smart-case sensitivity, frecency ranking, and Git-aware annotations. It is available through multiple integrations: Neovim, an MCP server for AI agents, and Rust, C, and Node/Bun SDKs. The MCP server is particularly relevant because it brings FFF's search capabilities into coding agents like Claude Code, Cursor, Codex, Cline, and OpenCode.

#Why it matters

• Agents search constantly. A single grep call is fast. But an AI coding agent may search for files hundreds of times in one session: finding definitions, locating tests, checking imports, and navigating project structure. Each search that takes several seconds adds up quickly.
• Warm index vs. cold spawn. The core tradeoff is architectural: FFF keeps its index resident in a long-lived process, while tools like ripgrep rebuild state for every invocation. For repeated searches on the same repository, the warm-index approach is dramatically faster.
• Typo-resistant search. Fuzzy fallback and smart-case matching reduce the number of failed searches when an agent or human slightly mistypes a filename or uses different casing conventions.
• Frecency and Git awareness. FFF ranks results by how recently and frequently files have been accessed, and annotates results with Git status. This means the files an agent is actually working on tend to surface first.
• MCP integration. The MCP server exposes tools like fffind and ffgrep to coding agents, making the speed advantage available inside the agent workflows where it matters most.

#How it works

FFF runs as a persistent process that indexes the repository on startup and maintains the index in memory. A background file watcher detects changes and updates the index incrementally, so the index stays current without full rescans. When a query arrives, FFF looks up the in-memory index and returns results directly, avoiding the filesystem traversal that makes cold-start tools slow on large repositories.

According to the project's README, on a Chromium checkout with approximately 500,000 files, FFF queries after warm-up can complete in under 10 milliseconds, while each ripgrep process spawn takes 3 to 9 seconds. The same Rust core powers all integrations, so the Neovim plugin, MCP server, and SDKs all share the same performance characteristics.

#Caveats

The performance numbers are claims published by the FFF project itself, not independently verified benchmarks. The sub-10-millisecond figure applies to warm queries on a long-lived process: it does not mean FFF is faster than ripgrep for a single one-off search. The speed advantage comes at the cost of RAM. The README estimates approximately 26 MB of memory for a 14,000-file repository and several hundred MB for a 500,000-file repository. There is also a warm-up period: the initial index build takes time before queries become fast. FFF is not a replacement for ripgrep in every scenario: it is most valuable when you have a long-running process that searches the same repository repeatedly. If your workflow involves one-off searches across different directories, the overhead of maintaining a warm index may not pay off. Finally, as with any install script, you should review the curl-pipe-bash installation command before running it.

#Who it's for

FFF is for developers and teams whose workflow involves repeated searching within the same large repository: AI coding agents, IDE extensions, Neovim users, and pre-commit tooling. If your agent spends significant time waiting for file search results, FFF's warm-index approach can meaningfully reduce that overhead. If you only search occasionally or work across many small repositories, the memory and warm-up costs may not be justified.

The honest summary: FFF trades RAM and warm-up time for repeated-query speed. Measure it on your actual workflow before committing.

Source: https://github.com/dmtrKovalenko/fff