ClickHouse Open-Sources Loom: One Self-Hosted Server Gives Claude Code, Codex and Cursor Shared Memory Tied to a Live Code Index

ClickHouse has open-sourced Loom, a self-hosted MCP server, HTTP API, and Python/TypeScript SDK that gives coding agents a shared, long-term memory stored in the same ClickHouse database as a live index of the codebase it describes. Any team can run it against its own repository and its own agents, for free, under Apache-2.0.

The pitch is narrow and specific: every coding-agent session normally starts from nothing, re-deriving context a previous session (or a teammate’s agent) already worked out. Loom keeps that context, checks it against the actual code as the code changes, and serves it to Claude Code, Codex, Cursor and custom agents over one connection.

Why ClickHouse built it

According to ClickHouse’s announcement, the trigger was its own autonomous contributor, GroeneAI, which had merged more than 3,000 pull requests by October but still started each session from almost nothing. ClickHouse says it evaluated two existing agent-memory tools on live traffic for three months, taking in over 82,000 memory writes, and found a consistent gap: the tools remembered what the agent had written about the code, but couldn’t see the code itself. Code search stayed in a separate, private index that didn’t know which function called which. Loom is ClickHouse’s attempt to converge memory and code intelligence into one system instead of two that happen to sit next to each other.

What’s actually in the box

Loom keeps facts, embeddings, a full-text index, a code graph, task state, and a cost/audit trail in one ClickHouse database, under one set of permissions. A few mechanics stand out:

• Facts get versioned, not overwritten. A note that a service defaults to max_threads: 16 in March and a later note that the default doubled in June don’t collide — the old value stays queryable as of any past date.
• Memories are linked to code, and flagged when the code moves on. If a function tied to a saved note gets renamed, Loom follows the rename. If it gets rewritten, the note is flagged for human review rather than silently going stale.
• Namespace-based sharing controls who writes and who reads — one-way (research agent writes, coding agent reads), two-way/N-way (shared team knowledge), or personal-to-shared promotion with approval gates.
• Search fuses four passes — vector search, BM25 keyword search, a verbatim-chunk pass, and an entity-graph hop — into one ranking, and will tell an agent it doesn’t know rather than returning a weak match as if it were confident.

Loom runs on self-managed ClickHouse or ClickHouse Cloud (version 26.5+, 26.8+ recommended for faster vector search), ships with a local embedding model and a placeholder “fake LLM” so it works with zero API keys out of the box, and adds real semantic search and generated answers once you supply your own model and embedding keys.

The numbers, with the caveats attached

ClickHouse published two sets of comparisons, both run on Claude Code (claude-sonnet-5) against the ClickHouse codebase, with the same questions and models on each side, switched Loom on or off.

Evaluation	With Loom	Without Loom	Scope
Coding-agent answer quality	0.84	0.78	24 questions × 3 runs
Coding-agent file localization	96.4%	91.4%	36 questions × 10 runs
Memory vs. full conversation history	94%	90%	100 LongMemEval-S questions

Cost per question dropped alongside the quality gains — from $0.212 to $0.17 on the answer-quality test, and by a similar margin on file localization — because retrieved memory needs fewer tokens than re-deriving context. On the full 500-question LongMemEval-S set, ClickHouse’s memory.ask scored 96.6% under its own judge, which the GitHub README is explicit is a product evaluation with its own configured models, not the fixed-reader comparison in the table above.

Two things are worth flagging before treating these as settled. First, every comparison is vendor-run on ClickHouse’s own repository and its own benchmark questions — there’s no independent replication yet. Second, ClickHouse itself says the 94%-vs-90% memory-versus-full-history gap “isn’t big enough to call statistically significant on its own”; the sample sizes (24 and 36 questions) are small enough that an 8% or 5% swing could partly reflect the specific question set. The benchmarks folder on GitHub has the full protocol and per-question results if you want to check that yourself, and a third-party MCP listing on Glama independently confirms the server’s real tool surface — 13 MCP tools including loom_search, loom_memory_set, and loom_context_pack — beyond ClickHouse’s own description.

What this changes for operators

Cross-session memory is one of the most common complaints about Claude Code and Codex workflows, and most existing fixes are either a single vendor’s proprietary feature or a thin per-agent scratchpad that one tool can’t read from another. Loom isn’t alone in targeting the staleness half of that problem — see our coverage of WikiTrace’s evidence-linked agent memory, which ties memories to the evidence that produced them and reports a sharp drop in memory-induced failures — but Loom is a concrete, self-hostable, free alternative that explicitly targets the team case: a developer using Claude Code to scope a change and a teammate using Codex to implement it can read and write the same namespace, with source and commit attached to every memory.

Getting started is a single install script:

curl -fsSL https://github.com/ClickHouse/loom/releases/latest/download/install.sh | sh

That starts Loom plus ClickHouse, applies migrations, and prints a dashboard URL at http://localhost:7777. From there, claude plugin marketplace add ClickHouse/loom and claude plugin install loom@loom connect Claude Code automatically once a repository is indexed; Codex uses the equivalent plugin commands, and Cursor connects over plain MCP. One caveat worth noting before you rely on it: the code index mirrors the branch the server has pulled, so uncommitted changes don’t show up in code-aware memory checks until you commit and push.

For teams already running their own agent memory benchmarks or weighing zero-retention policies against persistent memory, Loom is now a serious, inspectable option to run that comparison against — the source, benchmark methodology, and architecture docs are all on GitHub under Apache-2.0.