Hugging Face's funes gives coding agents a memory they own
Coding agents such as Claude Code, Codex, pi and Hermes already generate a dense record of their own work: as they search a codebase, try an approach, hit an error and change course, the session captures not just what changed but why. Hugging Face's framing is that this record usually goes to waste, because a raw session log is still only an archive, and an agent cannot grep its way to why an earlier session moved off the streaming parser, as the post puts it, across ten thousand turns of history. funes is Hugging Face's answer to that: a memory layer that indexes an agent's existing session traces so the agent can search them the way it searches a codebase, instead of a person having to remember the old session and paste its context back in.
funes ships as a single binary. Its default inference backend needs no separate ML runtime, and both embedding and reranking run on the user's own machine. It installs with a one line shell script, and one command wires it into an agent: funes add claude (or codex, pi, hermes) builds the first index, gives the agent recall and get tools, and installs the automation that indexes every completed turn from then on. Indexing is incremental: a new session adds only its new turns rather than re-embedding the whole history, and older, deeper history backfills in bounded steps instead of all at once.
Day to day, recall happens inside the ongoing conversation. The agent reaches for its own memory when a task touches a past decision, rationale or finding, and names the session its answer came from. recall returns the original passage rather than a summary, tagged with the agent, timestamp, session and turn it came from, and a companion get command opens that full turn with its surrounding context. Underneath, one deterministic pipeline parses every supported agent's trace into the same turn and block shape, chunks it, embeds it with a pinned local model, and writes it to a local Lance dataset. A query then combines vector and BM25 search, fuses the two rankings, reranks the candidates with a cross-encoder, reweights them by recency, and attaches neighboring chunks. Hugging Face credits that design with three properties: one memory across agents, since Claude Code, Codex, pi and Hermes all write to the same shape and every hit says which agent produced it; raw evidence that stays intact, because nothing is distilled into a fact at write time; and a recall that is local by default, needing no account or Hub repository, with a hosted model never processing the sessions during indexing.
A memory can also travel between machines and people. Binding one to a Hugging Face dataset while adding an agent, for example funes add codex acme/funes-memory, publishes the current memory there; funes then keeps indexing every turn locally and publishes at session boundaries, so the local memory stays a Lance dataset while the shared copy becomes a Hugging Face dataset the user owns, private by default. Credentials are redacted twice before anything reaches the Hub: once during indexing, and again when publishing rescans every chunk and withholds anything that still looks like a secret, with the specifics of that scan deferred to a separate SECURITY.md file rather than spelled out in the post. Reading a remote memory caches its dataset files locally so warm queries run at local speed, and the setup reuses the Hub's existing ownership, access control, versioning and distribution, so the memory does not become an account on a separate memory service that gets rented back through an API.
For a single question rather than an ongoing integration, funes ask is the read only sibling of funes add. funes ask claude "what did we decide about the streaming parser" reads the local memory by default, or a shared one can be named directly, as in funes ask claude "why is funes append-only" --memory huggingface/funes-memory. It recalls the relevant passages, hands them to a coding agent, and returns a sourced answer without installing anything or changing the agent's persistent setup. If the retrieved passages do not support an answer, Hugging Face says the agent reports that rather than guessing.
Because a shared memory is not tied to the agent or model that created it, a task can start in Claude Code and continue in Codex a week later, with the second agent recalling the first one's reasoning, or run through pi on a local or Hub served model before returning to Claude. Hugging Face names three settings this is meant to serve: across an individual's own machines, binding each agent to one memory; across a team, where a new hire's agent can retrieve months of decisions on its first day, including dead ends and rationale that never made it into a pull request; and alongside an open source project, where a maintainer can publish the sessions behind a release, described in the post as a searchable CLAUDE.md that holds the project's history instead of a page someone has to keep rewriting, and which anyone can query with --memory. Published memories carry a dataset card and a funes tag, so they show up as discoverable on the Hub.
To justify recall over the alternatives, Hugging Face ran what it calls the handoff-vs-recall benchmark: two internal tasks, each chosen so its answer cannot be reconstructed without a session's prior context, tested against context compaction and a written handoff. Compaction, which is what most agents do by default, was the only one of the three whose outcome was inconsistent: it answered one task and missed the other, and where it failed, its own summary had flattened the finding that mattered. Recall, which returns the original passages instead of a summary, came out cheapest of the three on both tasks: 8x cheaper than a written handoff on the first task, and 4x cheaper on the second. Hugging Face does not name the two tasks, or give absolute cost or time figures, only these relative multipliers.
The post closes on a line from Jorge Luis Borges's short story Funes the Memorious: "To think is to forget differences, generalize, make abstractions." funes is itself open source, hosted at github.com/huggingface/funes, and Hugging Face frames it as an assembly of existing open pieces rather than a new invention: open source embedding models small enough to run locally, Lance's append only datasets with cheap incremental writes, and the Hub's caching and content deduplication for datasets. The post never names Hugging Face as the developer of funes in so many words, writing throughout as an unnamed "we"; that attribution rests on the blog's own huggingface.co domain and on the github.com/huggingface/funes repository, which the post does name directly.
Key facts
- funes is a single binary memory layer for coding agents (Claude Code, Codex, pi and Hermes) that installs with one command and then indexes every completed turn automatically and incrementally, without re-embedding earlier history.
recallreturns the original session text rather than a summary, tagged with the agent, timestamp, session and turn it came from, and agetcommand opens the full turn in context.- A memory can bind to a private Hugging Face Hub dataset (for example
funes add codex acme/funes-memory) so it follows a user across machines or reaches a team; credentials are redacted twice, once during indexing and again when publishing rescans every chunk. - On Hugging Face's own handoff-vs-recall benchmark, two tasks that require a session's prior context, recall was the cheapest of three methods on both: 8x cheaper than a written handoff on one task and 4x cheaper on the other, while context compaction succeeded on only one of the two.
funes askanswers a single question read only from a local or a named shared memory (--memory huggingface/funes-memory) without installing a persistent integration, and reports when the retrieved passages do not support an answer rather than guessing.
Why it matters
Coding agents already produce a dense record of their own work: as they search a codebase, try an approach, hit an error and change course, the session captures not just what changed but why. Hugging Face's argument is that this record usually goes to waste, since a session log is only an archive: as the post puts it, nobody can grep their way to why an earlier session moved off the streaming parser across ten thousand turns. This is what funes fixes: it turns that existing trace into something an agent can search on its own, mid task, the same way it searches a codebase. It also reframes what a memory is. Instead of an account with a separate memory service that a user rents access to through an API, a funes memory is a dataset the user holds locally, or owns on the Hugging Face Hub.
Who it affects
Anyone already running Claude Code, Codex, pi or Hermes day to day, since funes attaches to those four agents specifically and needs no separate memory product to adopt. It is aimed in particular at two situations a single agent's own context window cannot solve: a team, where a new hire's agent can retrieve months of decisions on its first day, including dead ends and rationale that never made it into a pull request; and an open source project, where a maintainer can publish the sessions behind a release so anyone can query the reasoning behind it with --memory, rather than maintaining a static history document by hand.
How to use it
Install funes with the project's one line script (curl -fsSL https://huggingface.co/buckets/huggingface/funes/resolve/install.sh | sh), then run funes add claude (swapping in codex, pi or hermes) to build the first index and wire in automatic per turn indexing. Add a Hugging Face dataset name to the same command, for example funes add codex acme/funes-memory, to publish that memory to the Hub, private by default, so it follows the same user across machines or reaches a team. For a single question instead of an ongoing integration, funes ask claude "what did we decide about the streaming parser" reads the local memory, and adding --memory huggingface/funes-memory points the question at a named shared one instead. No price is stated anywhere in the post, for funes itself or for the Hub storage a shared memory depends on.
How solid is it
Every specific claim here is Hugging Face's own telling, on its own blog, about its own tool. The central evidence is a benchmark it built and ran itself: two internal tasks, chosen so neither could be answered without a session's prior context, testing recall against context compaction and a written handoff. Recall came out cheapest on both, 8x versus a handoff on one task and 4x on the other, while compaction alone answered only one of the two. The post does not name the tasks or publish absolute cost or time figures, so the multipliers cannot be checked independently. The credential redaction step is described only at a high level, with specifics deferred to a separate SECURITY.md file rather than spelled out in the post. The post also never names Hugging Face as the developer of funes in so many words, writing throughout as an unnamed "we"; that attribution rests on the blog's own huggingface.co domain and on the github.com/huggingface/funes repository, which the post does name directly.
Risks and caveats
The one benchmark behind the headline efficiency numbers is small, unnamed and run by the people who built the tool, so the 8x and 4x figures may not hold on different tasks or teams. No version number or release date is given for funes, nor for the earlier Hugging Face post it builds on. Sharing a memory means trusting the redaction pass to catch every secret across months of session transcripts before they reach a Hub dataset; the post says credentials are scanned twice but does not describe what the scanner does or does not catch. And because recall surfaces raw passages rather than a curated summary, a wrong assumption a past session made and never corrected sits in memory just as durably as a correct one, with no built in way for a later agent to tell the two apart.
“To think is to forget differences, generalize, make abstractions.”
— Jorge Luis Borges, Funes the Memorious