funes Keeps the Original Passage: Why Hugging Face's Coding-Agent Memory Refuses to Summarize
A single binary that indexes your Claude Code, Codex, pi, and Hermes sessions into one local table, with no model allowed anywhere near the write path
Every agent memory product on the market has a model in the write path. Something reads your session, decides what mattered, and writes a summary. funes, the memory tool Hugging Face released on September 3 and explained in more depth on September 17, has no model in that path at all. It parses your transcripts, chunks them, embeds them with a pinned local model, and stores the original text. When your agent asks what happened, it gets the passage back, with the session and turn it came from.
That sounds like a small implementation detail. It is the entire design, and it is the reason the tool is worth understanding even if you never install it.
What it is
funes is one Rust binary, Apache-2.0 (the LICENSE file reads "Copyright 2026 The HuggingFace Team"), sitting at 435 stars cache-busted as of this afternoon. GitHub carries tagged releases with changelogs (v1.3.0 on September 2, v1.3.1 on September 17), but the binaries and their checksums live in a Hugging Face bucket and the installer verifies them there rather than as GitHub release assets. The repo names its authors as the Hugging Face team; the launch post is by David Corvoysier and the September 17 post is by Aritra Roy Gosthipaty and Ayush Chaurasia.
Install and wire it in two commands:
curl -fsSL https://huggingface.co/buckets/huggingface/funes/resolve/install.sh | sh
funes add claude # or codex, pi, hermes
funes add builds a first index from the sessions already on disk, gives the agent two tools (recall and get), and installs a hook that indexes each completed turn. From then on the agent can call recall on its own when a task touches an old decision. You can also query from the shell:
funes recall "why did we switch off the streaming parser"
funes get <session_id> --from 40 --to 60
funes ask claude "what did we decide about the storage layout"
recall returns ranked verbatim passages, each with the agent, timestamp, session, and turn it came from and a get command to open the surrounding turns. ask retrieves locally and then hands the passages to whatever agent you name for a grounded answer. Subagent transcripts are indexed too.
The mechanism
The indexing pipeline is deterministic. Each supported trace format is parsed into the same turn-and-block shape, chunked, embedded with a pinned local model, and appended to a Lance dataset. The embedding model's identity is stamped into the dataset, and funes refuses to query a memory built with a different one. Reasoning is a separate concern; you switch models between sessions and the memory does not move.
Recall is hybrid. A query runs vector search for semantic matches and BM25 for exact identifiers (flag names, error strings, file paths), fuses the rankings, reranks the candidates with a cross-encoder, reweights by recency, and attaches neighboring chunks. Completed turns produce deterministic chunk IDs, so re-indexing skips anything already written and the memory is a disposable derived artifact; the transcripts remain the source of truth.
Why Lance? The September 17 post is mostly an answer to that question. One dataset directory holds everything:
chunks.lance/
data/ text, provenance, vectors
_indices/ BM25 and vector indexes
_versions/ committed dataset versions
There is no separate document store, vector store, and search service to keep in sync. New chunks append without rewriting, every commit is a version you can roll back, both index types travel with the data, and it runs in-process against local disk or object storage. That last point is what makes funes a library instead of a daemon, and it is why a memory can be published as a Hugging Face dataset repo (private by default) and pulled down by a teammate's agent with a single --memory flag.
The privacy design has two gates. When TruffleHog is installed, indexing redacts detected credentials before storage. Separately, funes push runs an always-on, fail-closed scan and holds back any chunk that still contains a secret. The SECURITY.md documents what the scanner does and does not cover.
Why the no-summary rule is the interesting part
Summarized memory has a failure mode that nobody measures until it bites: the summary flattens the one finding you needed. Hugging Face ran a small handoff-versus-recall benchmark on two tasks whose answers could not be reconstructed without the prior session. Compaction, which is what most agents do by default, "arrived on one task and never arrived on the other," because its summary had dropped the findings that mattered. Recall returned the passages themselves and was the cheapest of the three options, 8x cheaper than a written handoff on one task and 4x on the other, measured in weighted tokens per successful task.
Two tasks is not a study. But the shape of the result matches what I see in practice. The thing you need from an old session is rarely a fact. It is the reasoning that produced a decision, including the two approaches that were tried and rejected. A summary keeps the decision and throws away the rejections. A passage keeps both.
This is also where funes differs from the memory feature that shipped in Grok Build on September 16 and the auto-memory that Claude Code has used for months. Both of those write markdown topic files that a model curates in the background; the model decides what is durable and rewrites it into a note. That is a summarization pipeline with a file on the end. funes takes the opposite bet: index everything, let the ranker decide at read time, and never let a model rewrite the record.
Put this into practice
Start by asking your existing transcripts a question, before you change any agent configuration.
Install the binary, then run funes index against your home directory's .claude or .codex folders and give it time; the first index embeds every chunk locally. Then run funes recall with a question you know the answer to, something like the reason you chose one library over another two months ago. Read what comes back. If the passage is there and the ranking is sensible, you have learned something about the tool. If it is not, you have learned something about how much of your reasoning lives in sessions you already deleted.
Second, try the published memory before you trust your own. The funes team pushed a memory of their own development sessions, and you can query it with nothing indexed:
funes recall "why is funes append-only" --memory huggingface/funes-memory
That is the fastest way to see what verbatim recall looks like versus a summary.
Third, if you keep it, bind it to one agent with funes add codex and watch a real session for a week. The tool exposes recall as a tool the agent chooses to call; you are checking whether it reaches for it at the right moments, not whether the index exists.
Fourth, before you ever funes push, read SECURITY.md and check that TruffleHog is on your PATH. The index-time redaction only runs when it is installed. The push-time gate runs regardless, but you want both.
Fifth, decide your recency policy on purpose. The default half-life is 30 days. If your project has a long history and most of the decisions you care about are older than a month, that default is working against you. Keep reading.
Honest limitations
The recency weighting is the sharpest edge, and the evidence comes from a community member rather than the vendor. A commenter on the launch post (vshulcz, who discloses that they maintain a competing tool called deja-vu) ran funes 1.3.0 against 19,195 sessions laid down in real ~/.claude and ~/.codex layouts, with 100 questions whose answer sits in exactly one session. With defaults, funes found the right session at rank 1 for 9 of 100 questions and within the top 5 for 39. With --half-life 0, rank-1 rose to 19 and top-5 to 46. Their conclusion: "the 30-day recency half-life halves rank-1 on history older than a month, which is most of what's on a real disk." Plain BM25 over the same corpus (their own deja-vu) hit rank 1 for 18 of 100 and indexed in 29 seconds versus funes's 2 hours 3 minutes on an M4 Pro for 308,000 chunks. The funes author replied that this benchmark rewards exact-term matching where BM25 is already sufficient, and that funes "shines when the information is actually difficult to find." Both of those things can be true. Treat the default half-life as a setting you must tune, not a fact about your data.
The first index is slow on a real machine. The same commenter reports that the documented one-minute first pass indexed 218 of 19,195 sessions and answered zero of the 100 questions, so "about a minute" means about a minute until the embedding job starts.
It only knows what your transcripts contain. If you used a chat window, a different agent, or a machine that no longer exists, that reasoning is gone.
The binary ships for Linux x86_64, Linux aarch64, and Apple Silicon. No Windows, no Intel Mac.
The release tags are on GitHub but the artifacts are not; the version you install is whatever the Hugging Face bucket serves, verified by a checksum that lives in the same bucket. The README says this itself: the checksum "does not authenticate the bucket itself."
And a verbatim index is a verbatim index. If you pasted a customer's stack trace into a session in March, it is in the table, redacted only if a secret scanner recognized it as a secret. Publishing a memory to a shared repo is a deliberate act, but so is not reading what you are publishing.
Where this leaves you
Agent memory is settling into two camps this month. One camp lets a model decide what you meant and writes it into a note. The other keeps what you said and lets a ranker find it later. funes is the clearest implementation of the second camp, and its own users have already shown where the ranker needs help.
Run one recall against sessions you have not opened in three months. Then decide which camp you trust with your reasoning.
Sources: huggingface/funes README · Give Your Coding Agents a Memory You Own, September 3, 2026 · funes: Local Memory for Coding Agents, Built on Lance, September 17, 2026 · funes LICENSE · Grok Build memory, September 16, 2026
Medium metadata
Title: funes Keeps the Original Passage: Why Hugging Face's Coding-Agent Memory Refuses to Summarize Subtitle: A single binary that indexes your Claude Code, Codex, pi, and Hermes sessions into one local table, with no model allowed anywhere near the write path Tags: AI Agents, Claude Code, Codex, Agent Memory, Open Source Canonical: fervorai.dev (import from the published URL)