Your coding agent forgets everything the moment a session ends. Ask Claude Code or Codex to resume a feature you shaped last week and it starts cold, rebuilding context you already paid for in tokens and attention. On September 3, 2026, Hugging Face shipped Funes, an open-source memory layer that fixes this by indexing the traces your agent already produces and making those past decisions searchable inside new work. What makes Funes worth a closer look is not just that it adds memory, but where that memory lives: entirely on your own machine, in a store you own and can carry between tools. That single design choice defines a new pattern for developers, the agent memory you own, and it stands in sharp contrast to the memory features arriving inside vendor chat assistants.

Background

Coding agents became genuinely useful in 2026, but they carried a structural flaw from their chat-assistant roots: statelessness. Each run of an agent like Claude Code begins with an empty context window. The agent has no memory of the architectural call you made three sessions ago, the workaround you agreed on for a flaky dependency, or the reason a particular module was written the way it was. Builders compensate by re-explaining context at the start of every session, pasting in the same background, or maintaining hand-written notes files that quickly drift out of date.

The industry answered this in two broad ways. Vendors began bolting memory onto their own products, so an assistant could remember facts about you across conversations inside that vendor's walls. Separately, a wave of open-source memory frameworks appeared, each proposing a different substrate for durable agent recall, from knowledge graphs to vector stores. Funes enters as a distinctly developer-first, local-first entry in that second camp. It targets coding agents specifically, treats the agent's own session traces as the raw material for memory, and keeps every byte of indexing and embedding on the machine where the work happens. The name is a nod to Borges's character who forgot nothing, which is precisely the capability a coding agent lacks.

A labeled local memory vault storing coding-agent sessions on a developer's own machine
Funes keeps indexing and embeddings on your own machine, so the memory store belongs to you rather than a vendor.

Deep Analysis

How Funes works: local Lance store plus hybrid retrieval

Funes ships as a single binary and slots into an agent with one command. Running funes add claude registers it with Claude Code and hands the agent two new tools, recall and get, alongside incremental indexing of every new turn. The same wiring works for Codex, pi, and Hermes. Under the hood the pipeline is deterministic: parse the trace, chunk it, embed the chunks, and index them. Because the steps are deterministic rather than driven by a second model call, the behavior is reproducible and cheap to run repeatedly as sessions accumulate.

Storage lives in local Lance datasets built on an append-only structure. Each new turn is appended rather than rewritten, so history is never mutated in place and the index grows without expensive rebuilds. Retrieval is where Funes earns its keep. Instead of relying on vector similarity alone, it runs hybrid search: dense vector lookup combined with BM25 keyword matching, then a cross-encoder reranking pass to reorder the candidates by true relevance. It layers on recency weighting so newer decisions surface appropriately, and it attaches neighboring chunks to a hit so the agent receives fuller surrounding context rather than an isolated fragment. This is the retrieval stack you would build if you cared about precision on a developer's messy, code-heavy history, where an exact identifier match and a semantic match both matter. You can also skip the agent entirely and query your own history directly with funes ask, turning the store into a searchable log of how your projects actually evolved.

Local-owned vs vendor-locked vs graph memory

Agent memory is not one thing, and the differences matter more than the marketing suggests. Three approaches now compete for the same job, and they diverge on the questions a builder should actually care about: who owns the data, how retrieval works, and whether the memory follows you between tools. Funes represents the local-owned model. Vendor memory, such as the features built into consumer chat assistants, represents the vendor-locked model. Frameworks like Cognee, which structure memory as a knowledge graph, represent a third path optimized for reasoning over relationships.

Dimension Local-owned (Funes) Vendor-locked (Claude / ChatGPT memory) Knowledge-graph (Cognee)
Where data lives Your machine, in a local Lance store Vendor cloud, inside the product Wherever you host the graph backend
Data ownership You own it outright Vendor controls storage and access You own it, with more setup
Retrieval method Hybrid: vector plus BM25 plus cross-encoder rerank Vendor-defined, opaque to the user Graph traversal over entities and relations
Cross-tool reuse Works across Claude Code, Codex, pi, Hermes Locked to the one assistant Tool-agnostic, needs integration work
Privacy posture Nothing leaves your machine unless you publish Context sent to and held by the vendor Depends on your hosting choice
Setup cost One command Built in, zero setup Higher: schema and graph modeling

The trade is legible. Vendor memory wins on convenience and loses on portability and ownership; the memory is a feature of one product and cannot leave it. Graph memory wins when relationships between entities are the point, such as reasoning over how modules, people, and decisions interconnect, but it asks more of you up front. Funes stakes out the middle that most working developers actually want: near-zero setup, a retrieval method precise enough for code, and full ownership with cross-tool reuse baked in. This is developer memory, distinct from the consumer chat memory we compared in our breakdown of Claude, ChatGPT, and Gemini memory, where the store lives with the vendor and serves conversations rather than coding sessions.

Three memory approaches compared: local-owned storage cubes, a vendor-locked box, and a linked knowledge graph
Local-owned, vendor-locked, and knowledge-graph memory diverge most on ownership, retrieval method, and cross-tool reuse.

Giving a coding agent a memory you own

The workflow is deliberately short, which is part of the point. Start by installing the single binary. Then run the one-line setup for whichever agent you already use, for example funes add claude for Claude Code or the equivalent for Codex, pi, or Hermes. From that moment, Funes indexes every new turn incrementally, so the memory builds itself as you work rather than requiring a separate curation step. Give it a few real sessions before you judge recall quality; an empty store cannot retrieve what it has not seen, and the value compounds as your history accumulates.

Once memory exists, use it two ways. Inside the agent, simply ask it to resume or extend earlier work, and it will call recall and get to pull the relevant prior reasoning instead of re-deriving it from scratch. Outside the agent, run funes ask to interrogate your own history directly, which is useful for questions like why a decision was made or where a pattern was first introduced. If you run agents on more than one machine, connect the private-dataset sync so the same memory is available everywhere, an approach that complements the emerging pattern of persistent agent sessions that survive beyond a single window. The full toolchain is on GitHub under an open-source license, so you can read exactly what the pipeline does before trusting it with your history.

Privacy, portability, and cross-tool reuse

The ownership model is not a slogan; it is enforced by where computation happens. Indexing and embeddings run locally, so your code and prompts are never shipped to a cloud service as a condition of using memory. For anyone working under an NDA, on unreleased products, or inside a regulated codebase, that distinction is the difference between a usable tool and a compliance problem. Nothing leaves the machine unless you explicitly choose to publish it.

When you do want to sync or share, Funes publishes memories as Hugging Face datasets that are private by default. That lets the same history follow you across machines, or lets a team share a common pool of context, without inverting the default toward exposure. Critically, a redaction pass strips credentials before anything is published, so an API key or token that slipped into a session trace does not travel with the memory. Portability is the quiet superpower here. Because the store is yours and speaks to multiple agents, switching from one coding agent to another does not mean abandoning everything the old one learned about your project. The memory is an asset you keep, not a lock-in you accept.

Impact on Creators

For builders, the immediate payoff is fewer cold starts and less re-explaining. Every session that begins with the agent already aware of prior decisions is a session where more of the token budget goes to new work instead of re-establishing old context. Over a long project, that compounds into real time saved and more consistent output, because the agent stops contradicting choices it cannot remember making.

The deeper shift is about who owns the accumulated intelligence of a project. As coding agents do more of the work, the record of how and why a codebase evolved becomes valuable in itself. A local-owned memory turns that record into a durable, queryable asset that belongs to the developer or team rather than to a vendor. Independent creators, agencies, and small teams that cannot risk shipping client code to a third-party memory service get a credible option that respects confidentiality by default. And because Funes is open source, the pattern is inspectable and forkable, which matters for anyone who wants to trust their tooling rather than take it on faith.

A developer carrying a portable memory store between multiple coding agents
Because the store is portable, switching coding agents no longer means abandoning what the old one learned about your project.

Key Takeaways

  • Funes is an open-source, local-first memory layer for coding agents, released by Hugging Face on September 3, 2026.
  • It indexes your agent's own session traces into a local Lance store, then retrieves with hybrid search: vector plus BM25 plus cross-encoder reranking, recency weighting, and neighboring-chunk context.
  • Setup is one command per agent (funes add claude and equivalents for Codex, pi, and Hermes), with incremental indexing of every turn.
  • The memory belongs to you: indexing and embeddings run locally, so nothing leaves your machine unless you publish it.
  • Optional sync publishes private-by-default Hugging Face datasets, with a redaction pass that strips credentials first.
  • Against vendor-locked chat memory and knowledge-graph frameworks like Cognee, Funes optimizes for ownership, precise retrieval, and cross-tool reuse with minimal setup.

What to Watch

The open question is whether the agent memory you own becomes the default expectation or stays a power-user choice. Vendors have every incentive to keep memory inside their products, because a memory you cannot export is a retention mechanism as much as a feature. Funes and its local-first peers push in the opposite direction, betting that developers will increasingly refuse to hand the record of their own work to a service they do not control. The signals to track are adoption beyond the four agents supported today, whether teams standardize on shared private datasets as a knowledge base, and whether the vendors respond by opening export paths of their own. If precise, portable, locally owned memory proves as sticky in practice as it looks on paper, the amnesiac coding agent will start to feel like a relic, and the question will shift from whether your agent remembers to who gets to keep the memory.