Editors and AI agents run dozens or hundreds of file/content searches per session; one‑shot CLIs (ripgrep, fzf) pay the cost of process spawn, ignore parsing and FS walks every time. FFF flips that tradeoff by keeping an index and caches resident in a long‑lived process so subsequent queries are orders of magnitude faster and token‑cheaper for agents.
What Sets It Apart
- Frecency‑aware ranking: results are boosted by recent and frequent opens so the files you actually work on bubble up, reducing noise for agents and humans.
- Typo‑resistant fuzzy matching for both paths and content: Smith‑Waterman and SIMD‑accelerated algorithms survive dropped characters and reorderings, with smart‑case and auto‑fuzzy fallbacks.
- Multi‑mode content search and multi‑pattern OR search: plain, regex, and fuzzy grep modes plus SIMD Aho‑Corasick for fast multi‑term matching without many separate runs.
- Long‑lived, multi‑language integrations: Rust crate, C ABI, Node/Bun SDK, Neovim plugin, and an MCP server so AI agents (Claude, Codex, etc.) can call fff tools directly.
Who It's For and Trade‑offs
Great fit if you build editor integrations, AI agent toolchains or IDE features that run repeated searches against the same repo and need contextual results (git status, frecency, definition hints). Look elsewhere if your workflow is a single, one‑off grep from a shell — the project trades extra RAM and an initial indexing cost for sub‑10ms subsequent queries on warm trees. The content index uses modest per‑file memory (configurable; can use mmap) and may be sizable on huge checkouts.
Where It Fits
Compared to ripgrep/fzf: those are excellent one‑shot CLIs; FFF is a library and long‑lived service built for repeated, programmatic queries. Compared to full‑text engines (Tantivy/etc.): FFF targets repo‑scoped, low‑latency interactive search with git‑aware metadata and frecency, not global document indexing.
How It Works (high level)
FFF keeps a resident file tree and a lightweight content index, updates via a background watcher, and uses SIMD‑first algorithms, multi‑threaded pipelines, and optional mmap caching to deliver fast path and content matches. It exposes typed results (line content, match ranges, git status, frecency scores) via multiple bindings and an MCP server for agent tool injection.
