huggingface/funes: durable memory for your AI coding agents

The problem funes solves, and who actually has it

Coding agents forget. You settle an approach in Claude Code on Monday, open Codex on Thursday, and the reasoning behind that approach is gone. The transcripts still exist on disk, but nothing reads them back into a new task. funes is built for that gap: it indexes past sessions across Claude Code, Codex, pi and Hermes into a single memory, and exposes recall and get as tools an agent can call mid-task. The README's claim is that the model reaches for funes on its own, without you running a command.

The audience is narrow and specific. If you use one agent, occasionally, and never revisit old work, the index has little to retrieve. funes pays off when you run several agents against the same codebase over weeks, when the rationale behind a decision matters more than the decision itself, and when you want that rationale to survive a switch of agent or model. The repository description puts it plainly: durable, searchable memory of your past agent sessions. Nothing in the README suggests it is meant for non-coding chat history.

How funes stores and retrieves a memory

The storage layer is Lance. Cargo.toml pins lance, lance-io and lance-index at exactly 11.0.0, with the huggingface feature enabled, and the comments describe the dependency's job as dataset open, scan, append and create_index, local and over hf://. So a memory is a Lance dataset, and the same code path reaches it whether it sits on local disk or in a Hugging Face bucket. The lance-io comment mentions a WrappingObjectStore; src/memory/capture_store.rs implements the ObjectStore trait from object_store 0.13.2, which is how funes observes writes. That wrapper is the mechanism behind the secrets gate: the code can inspect a write payload before it lands.

Embeddings and reranking run on pinned local models through fastembed 5, which is an optional dependency behind an onnx feature. The Cargo.toml comment explains why it is off by default: ort ships prebuilt against glibc 2.38, above the glibc 2.35 floor that releases target, which is Ubuntu 22.04. That is a concrete packaging constraint, not a preference. funes ships no generative model of its own; per the README, you reason with whatever your agent uses, and switching models between sessions does not move the memory.

Indexing is incremental. The README references progressive indexing in the v1.1.0 release title and a hook, installed by funes add for Claude, Codex and Hermes, that keeps the index current every turn. Hermes sessions arrive through SQLite: rusqlite 0.32 is compiled with the bundled feature to read ~/.hermes/state.db. Other agents can join through a .parquet trace export, and docs/index.md#parquet-trace-format is named as the place where the required schema is defined. That is the extension point, and it is a schema contract rather than a plugin API.

Installing funes and running a first recall

The README points at scripts/install.sh, which detects your platform, downloads the matching prebuilt binary, verifies its tagged release checksum and version, and places it on your PATH, ~/.local/bin by default. The documented invocation is a pipe to sh:

curl -fsSL https://huggingface.co/buckets/huggingface/funes/resolve/install.sh | sh

The README is explicit about what that checksum proves. It detects corrupt, truncated or mismatched release downloads, but because the binary and the checksum live in the same bucket, it does not authenticate the bucket itself. If that distinction matters to you, the tagged binaries and their SHA256SUMS manifest are listed in the release bucket, with funes-x86_64-linux, funes-aarch64-linux and funes-arm64-apple-darwin as the named artifacts.

Before indexing anything of your own, you can try recall against a public memory. The README gives this exact command:

funes recall "why is funes append-only" --memory huggingface/funes-memory

That reads someone else's published memory for one call without touching your local setup. To get an answer rather than ranked passages, the README shows borrowing an agent for a single question, with nothing installed:

funes ask claude "why is funes append-only" --memory huggingface/funes-memory

When you are ready to wire it into your own workflow, the onboarding command is funes add claude, or codex, pi, hermes. The README states that this single command gives your agent recall and get as tools and, for Claude, Codex and Hermes, builds your first index, installs the per-turn hook, and publishes at each session boundary when a memory is bound. That is a lot of side effects for one command, so read docs/add.md first. funes status tells you whether recall is reading your own memory yet.

Append-only memory and the secrets gate

Two design choices deserve scrutiny. The first is that the store is append-only, which the README treats as a feature and even uses as the sample question in its own demos. The practical consequence is that a memory accumulates. Nothing in the README documents a deletion or compaction path for local chunks; the only removal it names is deleting a chunk on the Hub. If your sessions contain material you later want gone, that is a problem funes does not solve for you.

The second is the publishing guard, which is better specified than most. Credentials are redacted at index time, and a separate, always-on gate refuses to push any chunk that still contains a secret. Cargo.toml shows the mechanism: arrow-select 58 is included for filter_record_batch, described as dropping secret-bearing rows before a push. A filter that runs on the batch is a stronger guarantee than a regex over text, but it is still a filter, and the README does not claim it catches every credential format. Treat the gate as a backstop, not as permission to index sessions containing live tokens.

Visibility is handled sensibly. Dataset repositories created by funes are private by default, existing repositories keep their current visibility, and making a funes-created memory public is a deliberate change on the Hub. That default is the right one, and it is the reason the publish-at-session-boundary behaviour in funes add is less alarming than it first reads.

Where funes is the wrong tool

funes is not a general retrieval system for your codebase. It indexes agent sessions, and the sources it names are Claude Code, Codex, pi and Hermes plus a parquet trace import. If your history lives in a chat product outside that list, or in a proprietary transcript format, the import contract in docs/index.md#parquet-trace-format is the only door, and you would have to produce that schema yourself.

It is also not a standalone question-answering service. funes runs no generative model. funes ask borrows an agent, which means the quality of a grounded answer depends on the agent you borrow and on the model it uses. The README's framing, that you get one grounded answer naming the sessions it drew from, is about attribution rather than about answer quality.

Finally, the build story has a real constraint. The onnx feature that brings in fastembed is off by default because ort targets glibc 2.38 while releases target a glibc 2.35 floor. Anyone building from source on an older distribution should read the Cargo.toml comment before assuming the default feature set matches the shipped binary. The README does not document rollback of an index or of a published memory, and it does not document a migration path between memory schema versions.

How funes differs from agent memory built into one tool

The obvious alternative is the memory feature built into a single agent, such as Claude Code's own project memory. The difference in approach is scope and ownership. A built-in memory belongs to one agent and one machine; it is not a dataset, it has no publish step, and it does not span tools. funes indexes several agents into one Lance dataset, and every hit reports which agent it came from, so a task started in Claude Code can be picked up in Codex with the full history available.

The second difference is that the memory is a portable artifact. Because a funes memory is a Hugging Face dataset repo, it is owned by your account or org, gated by your token, and readable by whoever you grant access. A teammate or another machine recalls from it with one flag: funes recall "..." --memory <user|org>/funes-memory. docs/hub-caching.md describes how remote recall caches to local speed, which is the piece that makes remote recall usable rather than a network round trip per query.

The trade-off is operational weight. A built-in memory needs no install, no checksum verification, no index hook and no publishing policy. funes asks you to run a binary, keep an index current, and decide what leaves your machine. That is a real cost, and it is only worth paying if the cross-agent and portable-dataset properties are things you actually need.

Licence, maintenance and upgrade cost

funes is Apache-2.0, stated in both the README metadata and Cargo.toml, so the licence permits commercial use and modification with the usual attribution and notice conditions. That is not legal advice; if you plan to redistribute a modified binary, read the LICENSE file in the repository root. The pinned Lance dependencies at exactly 11.0.0 are worth noting for anyone forking: the version is fixed rather than ranged, and arrow-array, arrow-schema and arrow-select are all held at 58 with a comment stating they must match Lance's arrow version. Upgrading Lance is therefore a coordinated change, not a version bump.

On maintenance, the last push to the default branch was on 2026-09-09, and the most recent tagged release is v1.3.0 from 2026-09-01. The repository is not archived. Those are the facts; judge activity from them rather than from any claim here. Upgrades are handled by the tool itself: funes update replaces the binary in place with the latest build for your platform, --force reinstalls the current one, and funes status reports when a newer release is available. The v1.2.0 release title, verified install and update, suggests that path was the focus of that release. What the README does not describe is what happens to an existing memory when the on-disk format changes between versions.

Editorial conclusion

Adopt funes if you already run Claude Code, Codex, pi or Hermes and keep losing decisions between sessions, and read docs/add.md before you run funes add, because that one command also builds an index, installs a hook and can publish at session boundaries. Do not adopt it if you need a memory that forgets on request: the README describes the store as append-only and the only deletion path it names is deleting a chunk on the Hub. Before trusting it with work sessions, run funes status to confirm recall reads your own memory rather than a remote one, and check the secrets gate against a session you know contains a token.

Frequently asked questions

Official sources

1. huggingface/funes on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases