Smfs

The pitch behind Smfs is a diagnosis, not a feature list: agents are inherently fluent in bash — they navigate file structures, execute scripts, and pipe outputs — yet when we give them "memory" we force them to learn vector databases, manage API keys, and orchestrate external SDKs. Smfs collapses four moving parts (a vector DB, a memory service, a profile store, and an SDK) into a single mount point by translating semantic operations into standard POSIX syscalls. That reframing is the whole product, and it is a good one. The mechanics are unusually honest for this category. Real NFSv3 on macOS with no kernel extension and no macFUSE, FUSE on Linux, pure Rust with #![forbid(unsafe_code)], a single static binary, MIT or Apache-2.0 — that is a deliberately boring, auditable surface, and it means you can read the source before you let it touch your agent's context. Full POSIX semantics are implemented: symlinks, hard links, rename, chmod, chown, truncate, statfs. Inside a mount, grep is transparently upgraded to Supermemory's hybrid semantic search, so grep "auth middleware issues" returns the architecture doc and the Slack export that mention the problem in different words; grep -F falls through to literal standard grep when you actually want exact matching. cat profile.md returns a digest synthesized on read from every memory in the container — not stored, regenerated on demand via /v4/profile — which means context follows your users across sessions without a separate profile service. The file-format story is the other real differentiator. Dropping a PDF, MP4, PNG, DOCX, or M4A into the mount needs no OCR pipeline, no transcription step, no PDF parser, and no chunking job. The pipeline you would otherwise build — extract, chunk, embed, upsert — is simply gone, and grep works across every format at once. For anyone who has spent a week maintaining that pipeline, that is the argument. Where it gets uncomfortable: files live in Supermemory's cloud, so this is not a fully local memory store, and if your policies prevent memory from leaving your infrastructure, that is a hard stop. You need a Supermemory container and credentials per mount tag. The benchmark numbers are the project's own 220-question audit, not a third-party evaluation, so treat the 66%/43% token reductions as directional; note also that Codex correctness dipped slightly (105 → 101/110), so "same answers, fewer tokens" is not literally uniform across agents. And although the Linux side is genuinely zero-setup via the fuser crate, macOS depends on NFS mounting behavior that can vary with your setup. The fit is narrow and clear. If you run Claude Code or Codex in a shell on macOS or Linux, this is a low-risk trial. If you want a hosted API, a GUI, non-technical teammates to use it, or Windows support, Mem0 or Letta cover ground Smfs deliberately does not.