This server provides read-only recall and inspection of funes memories built from past AI coding-agent sessions.
recall: semantic search over past sessions, with filters for repo, role, harness, block type, date, and memory; supports one-line results and reranked candidate pools.
get: read a session's turns verbatim, with range selection and the same memory context as a search hit.
scan: exhaustively find a literal string within one session, with context and case-sensitivity options.
sessions: list a memory's sessions, filter by repo/date, and page through results.
sketch: summarize what a session was about, including its opening ask and last word.
status: inspect memory health, size, languages, indexing/pushing gaps, and diagnose thin or empty results.
Point tools at a local, remote, or Hugging Face memory (local, <org>/<repo>, hf://…, or a path).
Indexes Hermes agent sessions into the same shared memory and exposes recall/get tools, allowing past work from Hermes to be recalled alongside other agents.
Publishes local memory as Hugging Face dataset repositories and recalls from remote memories on the Hugging Face Hub, including public or private datasets, through push and recall commands.
Durable memory for your AI coding agents. funes indexes your past sessions across Claude
Code, Codex, pi, and Hermes and lets any agent recall the past decisions, rationale, and findings.
Your memory is a dataset you can publish to the Hugging Face Hub — then any machine, teammate, or
agent can recall from it.
Put a question to a memory and borrow a coding agent to answer it: funes recalls the relevant sessions, hands them over, and you get one grounded answer that names the sessions it drew from — nothing installed. Here it reads the public huggingface/funes-memory dataset named right in the command.
Your agent recalls your past work. The model spontaneously uses funes to recall prior decisions, rationale, and findings mid-task.
One memory across your agents. Index Claude Code, Codex, pi, and Hermes into a single memory; recall spans all of them, and every hit shows which agent it came from.
Your memory is a Hugging Face dataset. Publish it to the Hugging Face Hub; a teammate, another of your machines — or anyone, if you make it public — recalls from it with one flag.
And it happens on its own: with funes added, your agent reaches for recall mid-conversation — no command to run. Here it recalls to answer a question about funes's own design, grounded, naming the session it drew from.
Related MCP server: agent-history-mcp
The installer detects your platform, downloads the matching prebuilt binary,
verifies its tagged release checksum and version, and puts it on your PATH (~/.local/bin by
default):
curl -fsSL "https://huggingface.co/buckets/huggingface/funes/resolve/install.sh?src=readme" | shThen add it to your agent:
funes add claude # or codex, pi, hermesAnother agent? Integrations their authors maintain are listed in
funes-integrations/COMMUNITY.md,
and funes add <id> --from … installs one from wherever it is published.
To build and share your own, start with Writing an integration.
One command onboards you: your agent gets recall and get as tools, and — for Claude, Codex, and
Hermes — funes builds your first index, installs a hook that keeps it current every turn, and (with a
memory bound) publishes at each session boundary. From here you just work. See
docs/add.md for the agents, memory binding, and what a run does; funes status tells
you whether recall is reading your own memory yet.
Tagged binaries and their SHA256SUMS manifest are also available in the
release bucket:
Platform | Binary |
Linux x86_64 |
|
Linux aarch64 |
|
macOS Apple Silicon |
|
The checksum detects corrupt, truncated, or mismatched release downloads. Because the binary and checksum share the same bucket, it does not authenticate the bucket itself.
Already installed? funes update replaces the binary in place with the latest build for your
platform (--force reinstalls the current one), then brings your agent integrations to their newest
release; funes status tells you when a newer release is out. To build it yourself, see
Building from source.
funes names itself to the Hub: the User-Agent of its Hugging Face requests carries its version and
an anonymous install id. The id is a random UUID kept in ~/.funes/install-id, created on the
first run. It derives from nothing (not your hostname, user, hardware, or Hugging Face account) and
only lets the project count installs and active installs, local-only ones included. It goes
nowhere but the Hub. Set DO_NOT_TRACK=1 or FUNES_NO_TELEMETRY=1 to leave it out. Deleting the
file starts a new one. The installer's own downloads say only which script revision and platform
they are for.
Your memory isn't tied to one tool. Because Claude Code, Codex, pi, and Hermes all index into a single memory, you can switch agents without losing anything — start a task in Claude Code, pick it up in Codex next week, and each one recalls the entire history, not just its own sessions (every hit shows which agent it came from). Another agent can join by writing its sessions as funes JSONL turns files.
Models work the same way. funes runs pinned local embedding and reranking models, but no generative model of its own: you reason with whatever your agent uses — through pi, any local model or one served through the Hugging Face router. Switch models between sessions and the memory doesn't move.
Your local memory is a dataset, and it shares the way one does: publish it to a Hugging Face dataset repo you own and it becomes an artifact on the Hub like any model or dataset — owned by your account or org, gated by your token, readable by whoever you say. Not just the code of a project, but the process behind it — the decisions, dead ends, and rationale — becomes something an agent can recall.
Dataset repositories created by funes are private by default. Existing repositories retain their current visibility, and making a funes-created memory public is a deliberate change on the Hub.
Bind your host to a memory, funes bind <user|org>/funes-memory or the memory named when you add
an agent, and every agent recalls from it and keeps it current on its own; or run the two commands
directly:
funes push <user|org>/funes-memory # publish your local memory's new chunks
funes recall "..." --memory <user|org>/funes-memory # read any remote memory for one callThat second form is how you read someone else's published memory on a topic, without touching your own setup. Publishing is guarded: an always-on gate redacts credentials from what it publishes, and holds back what it can't redact. And because a published memory is just a dataset, you can try recall right now, before indexing anything of your own:
funes recall "why is funes append-only" --memory huggingface/funes-memoryAnd to get an answer rather than ranked passages, borrow an agent for one question — nothing installed:
funes ask claude "why is funes append-only" --memory huggingface/funes-memory # or: funes ask codexSee docs/push.md for publishing, the secrets gate, selecting what to publish, and inspecting a memory; docs/ask.md for grounded answers; docs/hub-caching.md for how remote recall caches to local speed.
funes add wires all of this into your agent; each command is also usable on its own. Browse the
workflow-oriented documentation index for the complete guides.
Command | Docs |
| docs/add.md — supported agents, integration lifecycle, memory binding, generic MCP clients, and hooks |
| docs/index.md — build/update the memory and compact it; sources, incremental, flags |
| docs/recall.md — recall passages and drill into them |
| docs/sessions.md — list sessions, digest one, find a literal in one |
| docs/ask.md — borrow an agent for a grounded answer |
| docs/push.md — publish and share a memory |
| installation and updating — replace the installed binary with a verified release, and update the agent integrations |
The per-turn indexing and session-boundary publishing the hooks run are detailed in docs/automation.md.
funes add runs one loop: index what you've done, recall it when it matters — and index what
you just did, so it's recallable next time. Both halves are one deterministic pipeline: each source
is parsed into a generic turn/block shape, chunked, written to a local Lance dataset, and embedded
with a pinned local model; recall fuses vector + BM25 search, and reranks the pool with a cross-encoder.
Integrations convert each agent's transcripts into the shared turns format.
Adding an agent means publishing an integration of your
own; the indexing and query pipeline already reads that format.
funes shapes its output for agents, not people — so to put a question to a memory yourself, borrow
an agent: funes ask recalls from the memory and answers grounded in what it finds, installing
nothing. funes recall prints the raw ranked passages behind an answer, and funes get reassembles
any cited turn in full.
docs/index.md — sources, progress, and incremental indexing.
docs/recall.md — retrieval, drill-down with get, and reading a shared memory.
docs/sessions.md — browsing a memory by session: sessions, sketch, scan.
docs/ask.md — borrow an agent for a grounded answer, nothing installed.
docs/automation.md — the per-turn hooks that keep it all fresh.
Needs a Rust toolchain and protoc — lance's build scripts compile protobuf at build time
(the finished binary does not need it). Install it one of two ways:
# System-wide:
sudo apt-get install -y protobuf-compiler # Debian/Ubuntu
brew install protobuf # macOSThen cargo build --release (binary at target/release/funes); cargo test runs the suite. The
integration test downloads the embedder/reranker weights on first run.
Inference (embedding + reranking) runs on a built-in backend — Accelerate on macOS, pure Rust on Linux — so the default build has no ML runtime dependency and runs on any glibc ≥ 2.35 (Ubuntu 22.04). On macOS 15 or later, indexing embeds and recall reranks on the GPU through Metal, falling back to the CPU where no GPU starts. An ONNX Runtime backend is available as an opt-in variant:
cargo build --release --no-default-features --features onnx # ONNX backend instead
cargo run --release --features onnx --example score_models # score the built-in backend against itEach memory names its embedding model, and funes embeds a query with the model of the memory it searches. A memory holds one model's vectors: funes indexes into it with that model, and refuses to push another model's vectors into it. To change it, rebuild from the transcripts (the memory is a disposable derived artifact — the raw text is retained in every row). This is separate from the model you reason with, which is free to change.
Subagent transcripts (.../subagents/agent-*.jsonl) are indexed too.
"To think is to forget differences, generalize, make abstractions." — Jorge Luis Borges, Funes the Memorious
Why funes is built the way it is — and how it compares to other memory tools — is documented in
docs/RATIONALE.md.
funes is licensed under the Apache License 2.0.
Read one session's turns as they were written — whole blocks, splits reassembled, nothing ranked or summarized. Typically the follow-up to a search verb: expand a result into the turns around it. Sessions run to thousands of turns: read the stretch you need, not the session.
Inputs: session_id (required), to, from, memory.
Semantic search over the user's past AI agent sessions: describe what you are after, get back the verbatim passages — what was decided, tried, measured or investigated. Call it when they refer to earlier work, or when you are about to re-derive something a session may already have settled. Call it too before claiming that something was never built, was dropped, or was never discussed: the code cannot show that, only the sessions can. Ranked top-k, so it gives you a foothold on a topic, not every session touching it. Ranking weighs relevance, not age: for the latest word on a topic, or one stretch of time, bound it with since/until. Each hit is a passage framed by its exchange, the prompt that asked, the assistant's last word on it and the user's reply, so the answer is usually in the reply itself: k is the token cost, candidates the reach, and a pool larger than k is reranked, at seconds of latency that grow with the pool, so the reach can grow without the reading. oneline lists the hits without their passages, to choose what to read.
Inputs: query (required), k, repo, role, +7 more.
Find every occurrence of a literal string in one session — exhaustive, unranked, in reading order. For when you already know the wording and want where it occurs, rather than what a topic is about. Scope is one session and one spelling: a zero result clears only that.
Inputs: needle (required), session_id (required), to, from, +3 more.
Enumerate a memory's sessions, oldest first. Metadata only — when it started and when its last indexed turn was, harness, repo, turn count, id, and the prompt each opened with, which is the ask a session started from, not what it became. Filter by repo or date to get the session ids the other verbs take; a whole memory can run to thousands of rows.
Inputs: repo, limit, since, until, +2 more.
What one session was about, worked on, and ended up at: the passages most distinctive within it, verbatim, always including its opening ask and its last word. Takes a session id; there is no query. Enough to tell the user what a session was, in one call; not a way to find a particular thing in it.
Inputs: session_id (required), to, from, units, +2 more.
Health and size of a memory: indexed chunks, the languages its sessions are written in, local chunks awaiting embedding, source sessions awaiting indexing, and for a remote this host pushes to what it has yet to push. Call it when a read comes back empty or thinner than expected — it says whether the memory is the problem rather than the call.
Inputs: memory.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 6 tools
Each tool has a distinct retrieval role: semantic recall, literal scan within a session, full-turn get, session sketch, metadata enumeration, and index health. The potential overlaps between recall/scan and get/sketch are explicitly disambiguated by scope and output.
Names are concise lower-case single words, but they mix verb-style actions (get, recall, scan, sketch) with noun-style resources (status, sessions). The set remains readable, though it does not follow a predictable verb_noun pattern or a single part-of-speech convention.
Six tools is well within the ideal range and each maps to a distinct memory operation. None appears redundant, thin, or tacked on.
The read-only memory surface covers semantic search, literal search, session reading, summarization, enumeration, and health checks. The main gap is no exhaustive cross-session literal search — scan is scoped to one session — though agents can work around it by enumerating sessions and scanning each.
Shared memory for AI tools: save once, recall word for word from Claude, ChatGPT, Codex or Gemini.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Persistent memory for AI agents. Search, store, and recall across sessions.
Recall (recall.it) — your AI knowledge base / 'second brain'. Via the official API: semantic search