Sverklo vs Memoir
Both pitch Git-style memory for AI agents. Memoir (Apache 2.0, alpha, 239 stars) implements per-branch HEAD pointers over a Merkle B-tree — when you git checkout feature-x, the memory view auto-isolates. Sverklo (MIT, production v0.20.6) implements bi-temporal SHA-pinning — every memory carries valid_from_sha + valid_until_sha + superseded_by, so "what was true at commit abc?" is answerable for any commit in history.
Different abstractions on the same problem. Memoir's branch-snapshot is sharper UX for the active-development case; sverklo's bi-temporal is more rigorous for "what did this team believe at commit abc?" historical queries.
Feature comparison
| Sverklo | Memoir | |
|---|---|---|
| License | MIT | Apache 2.0 |
| Status | Production (v0.20.6) | Alpha (v0.1.9) |
| Storage substrate | SQLite + sqlite-vec | ProllyTree (Merkle B-tree) |
| Versioning model | Bi-temporal: valid_from_sha + valid_until_sha + superseded_by | Per-branch HEAD pointers (Merkle KV) |
| Point-in-time queries | Yes — any commit, any branch, any history depth | No — branch HEADs only. Source: VersionedKvStore only supports branch checkout, not commit checkout |
| Branch isolation on git checkout | Not by default (opt-in via filtering, planned) | Yes — biggest UX win |
| Memory scope | Memory bundled with retrieval, impact, audit, review | Memory-only library |
| MCP server | Yes — 36 tools, profile-filterable to 5 | Yes — memory tools only |
| Auto-capture hooks | No (manual sverklo_remember) | SessionStart / UserPromptSubmit / Stop hooks |
| Hybrid retrieval (BM25 + vector) | Yes — same pipeline that powers /mcp/ leaderboard | No (memory-only) |
| Languages | 10 first-class via tree-sitter, 14 via regex fallback | Memory store is language-agnostic |
| Public benchmark | 120-task / 5-baseline retrieval bench | None published |
| Install | npm install -g sverklo && sverklo init | pip install memoir-ai or Claude Code plugin |
| GitHub stars | — | 239 (2026-05-09) |
Public benchmark coverage
Sverklo is on the public 5-baseline retrieval benchmark — 120 hand-verified tasks across 4 OSS codebases (express, lodash, requests, sverklo). Sverklo F1=0.60 leading; jcodemunch-mcp wins P1 def-lookup outright at 0.78. Memoir is not on the public bench yet — it's memory-only, so the existing P1/P2/P4/P5 retrieval categories don't apply directly. A memory-specific benchmark (recall persistence across context compaction, point-in-time correctness, branch isolation correctness) is a gap in the field that the maintainers of sverklo-bench would entertain — open an issue at sverklo/sverklo-bench if you'd contribute task design.
In the meantime, the comparison above is feature-shaped — describing what each tool exposes, not how each tool scores on a common eval. Treat the above as positioning, not measurement.
When to use each
Choose Sverklo when
- You want one tool that bundles memory with hybrid code retrieval, blast-radius analysis, and PR review — not a memory-only library you'd glue to a separate retriever.
- Point-in-time queries matter — "what did this team believe about auth at commit abc?" is a question your agent or your reviewers actually need to answer.
- You want a production-stable surface (v0.20.6) over an alpha library (v0.1.9).
- Bi-temporal correctness across rebases / force-pushes / merges is more important than per-branch checkout ergonomics.
- You're already using sverklo for code retrieval and want the memory layer to share the same MCP server.
- You're allergic to standing up a separate Python service (Memoir) when your stack is Node-first.
Choose Memoir when
- You only need memory — no retrieval, no impact analysis, no PR review — and you want the most ergonomically branch-aware option.
- Long-lived experimental feature branches are common in your workflow and you want their memories isolated from main-branch context by default.
- The Claude Code SessionStart / UserPromptSubmit / Stop auto-capture hooks are a load-bearing UX feature for you.
- Your stack is Python-native and you want a Python-first memory library.
- You're building on top of Merkle B-trees specifically (e.g. content-addressable storage requirements) and the ProllyTree substrate is structurally aligned with your design.
- Alpha-stage software is acceptable in your environment.
Different abstractions on the same problem
Memoir's branch-snapshot pins memory to a moving reference (the branch HEAD). Sverklo's bi-temporal model pins memory to immutable references (commit SHAs). The branch reference is more ergonomic for the active-development case where you want "this branch's memory" filtered without thinking. The SHA reference is more rigorous for the historical-correctness case where rebases, force-pushes, and merges shouldn't lose memory provenance.
Memoir's own source comment acknowledges the gap: "VersionedKvStore only supports branch checkout, not commit checkout." Closing that gap requires a Merkle tree that addresses each commit independently, which is structurally most of what bi-temporal columns give you for free in a regular SQLite store. The two designs converge as Memoir adds commit-level checkout; the trade then becomes implementation choice (Merkle vs SQL) more than abstraction.
Full deep dive on the comparison: "We Already Shipped Git-for-Agent-Memory — Bi-Temporal Beats Branch-Snapshot".
Try Sverklo
MIT licensed. One command. Bi-temporal memory + hybrid retrieval in the same MCP server.
click to copy