Many searches — especially for AI assistants — waste tokens and time by returning noisy or irrelevant files. fff.nvim addresses this by treating file search as a ranked, context-aware retrieval problem: it combines very fast indexing and fuzzy matching with lightweight "memory" (frecency, git status, file heuristics and definition matches) so agents and humans see fewer irrelevant files and fewer round-trips.
What Sets It Apart
- Fast, opinionated ranking: score combines frecency (recent/ frequent opens), git status, file size and match quality, so results prioritize files you actually want to open rather than every fuzzy hit. This reduces token and I/O waste for AI agents and keyboard navigation time for humans.
- Multi-mode search tuned for developer workflows: supports file fuzzy search, plain/regex/fuzzy live grep, glob constraints and cross-mode suggestions (when file search fails it proposes content matches). That means fewer context switches and quicker location of definitions or tests.
- Designed for agent integration (MCP): exposes a lightweight MCP-compatible interface and a prebuilt binary path so AI assistants can call a single fast RPC-like tool to get ranked file results, cutting down prompt size and agent read-time.
- Practical UX for Neovim users: native plugin with preview, quickfix integration, configurable scoring/debug view and sensible defaults so it slots into existing editor workflows without reinventing them.
Who It's For and Trade-offs
Great fit if you want faster, more relevant file discovery in large repositories (100k+ files) from Neovim or an AI agent: it reduces wasted reads and token costs for agent-driven code tasks and gives humans a typo-robust picker with git-awareness.
Look elsewhere if you need cross-repository/global code search, complex indexed semantic search (embeddings/RAG), or a pure cloud service: fff focuses on repository-local file/grep tooling and ranking heuristics rather than heavy-weight semantic indexing. It also requires either a prebuilt binary or a Rust toolchain to build; indexing and the frecency DB consume local storage and some CPU for large repos.
Where It Fits
Positioned between low-level tools like ripgrep (fast but unranked) and larger semantic/code-search systems (heavy indexing and embeddings). For editor-integrated file discovery and lightweight agent memory—especially when token and IO budgets matter—fff.nvim provides a pragmatic middle ground that emphasizes ranked relevance and speed over deep semantic understanding.
