Repeated search is FFF's strongest reason for a trial
FFF keeps search state available across calls from an editor, agent, or library consumer. That makes it relevant when the same repository receives many related queries. Whether that design improves your complete workflow still depends on indexing cost, result quality, and integration behavior.
The README documents typo-resistant path and content search, frecency ranking, a background watcher, and an in-memory content index. It describes MCP, Pi, and Neovim integrations alongside native and language APIs. These are upstream descriptions; our run did not exercise them.
What our recorded run actually checked
Our recorded run took place on October 10, 2026, at commit 65119f965d39a657020daf9198a657f6d1f718fd. The recorded sandbox configuration was 3 CPUs, 8 GB of memory, and image lab-node:22. The image label alone does not establish the actual runtime version.
The npm-oriented install step took 6,201 ms. Its output contains an npm ci EUSAGE error explaining that a suitable lockfile is required, followed by output reporting an up-to-date package state. Although the harness marked the overall step successful, the supplied tail does not establish the exact subsequent command or prove that an FFF executable or native library was installed. The initial command failure also does not show that FFF itself is broken.
The summary recorded 0 dependencies and a 14 MB install-footprint metric. Those figures are not runtime memory measurements or proof that FFF has no dependencies. The checkout metrics were 392 files, approximately 74,992 source lines, and 9.3 MB. Detection found 10 CI workflows, a tests directory, and a Makefile.
Build and tests were skipped because the npm probe found no scripts. It did not establish the absence of Rust build targets or runnable tests. There is no recorded native compilation, installed-binary check, SDK load, watcher exercise, or measured search workload.
Npm audit recorded 0 advisories. Its coverage is unknown. This is not a security assessment of FFF's other ecosystems or native artifacts.
Upstream performance results need their limits attached
The current README compares warm FFF MCP with shell search and explicitly excludes startup and indexing. Its separate held-out evaluation covers six additional tasks in the small repository; the large repository did not receive a separate held-out run.
The reported held-out results vary by model. Opus 5.5 took 10.7 seconds with shell search and 9.0 seconds with FFF, using 58.3k and 49.2k tokens respectively. GPT-6 Astra took 8.1 seconds with shell search and 9.0 seconds with FFF, using 43.9k and 49.3k tokens. The README says both models returned all six expected answers in each recorded search mode, and that token totals include cached input.
These are upstream measurements, not our benchmark. They support testing a particular integration, rather than assuming FFF always saves time or tokens. They also cannot answer how long a cold start takes on your repository.
Setup and search coverage need separate checks
The README documents shell and PowerShell installers plus a Homebrew route for MCP. For Codex, it specifies an absolute executable path and a restart or new task after registration. Completing those instructions should be followed by checking that the client can actually call the server's tools.
The current README names the MCP tools grep, find_files, and multi_grep. The commit-pinned README corresponding to our run instead names ffgrep, fffind, and fff-multi-grep. Use documentation matching the artifact you install; current instructions do not prove behavior at the measured commit or in v0.10.5.
FFF's current MCP documentation says globs cannot restore files excluded by the index's ignore rules. Issue 714 discusses the narrower problem of explicitly named ignored paths inside an active workspace, initially for Pi, with a separate MCP report in the discussion. Referenced commits alone do not establish which released artifact resolves that case. Keep a way to inspect ignored dependencies and generated output, and test those paths before making FFF the only search route.
Ripgrep is relevant for shell content searches: its README documents recursive regex search and rg -uuu to disable automatic filtering. Fzf addresses a different need, selecting interactively from candidate input. Neither comparison establishes a performance winner for your workload.
Historical reports are not all current blockers
Issue 799 reports a fatal invalid-UTF-8 filename scan crash with @ff-labs/fff-node 0.10.5 and @ff-labs/pi-fff 0.10.5 on Linux. The supplied issue extract shows it closed as completed through pull request 809 on August 30, 2026. It should not be described as an unresolved fix proposal. The extract does not identify the first tagged release containing the fix, and our run did not retest the reproducer.
Issue 820 reports MCP logs written directly beneath ~/.cache with the standalone v0.10.5 binary. It was also closed as completed on August 30, 2026, through pull request 821. The referenced change concerns the default XDG state path. Our run did not inspect installed log behavior, and the supplied release evidence does not identify the first fixed tag.
Issue 786 remains open in the supplied extract. Its reporter describes a prebuilt Neovim module crashing on Termux aarch64 when a directory has more than two child directories, with 0.9.6 reported working and the problem reported from 0.10.0 onward. A collaborator could not reproduce it on non-Android aarch64. Treat this as a specific compatibility report, not evidence that all Linux or ARM64 installations fail.
The supplied v0.10.5 release page lists Neovim modules, C FFI libraries, MCP binaries, Python wheels, and a source distribution. That establishes release packaging, not successful operation of each artifact in our sandbox.
How to read the scores
These are editorial judgments on the supplied evidence, not benchmark results. The scale is 1 for insufficient evidence or a substantial unresolved obstacle, 2 for partial support with major verification gaps, 3 for a documented route with practical caveats, 4 for broad supporting evidence with limited gaps, and 5 for comprehensive support within the stated scope. A low evidence score does not establish poor product quality.
Setup receives 3/5 because installation routes and client wiring are documented, while our probe did not verify the native installation. Documentation receives 4/5 because the supplied README covers setup, APIs, configuration, and search limitations, although tool names differ between the measured commit and current documentation. Community receives 2/5 because the issue extracts show maintainer and contributor exchanges, but do not establish adoption or representative response times. Maturity receives 3/5 because release artifacts and completed fixes are documented, while Termux compatibility remains unresolved in the supplied report and our native validation is absent.
For a useful trial, choose one frontend and a pinned artifact. Confirm that it loads, check ignored and unusual paths, and compare complete tasks including cold indexing and warm queries. Our recorded run cannot make those adoption checks for you.