How Hydrate compares to everything else.

Pieces · the closest competitor

Pieces is the one tool on this page that shares Hydrate's core positioning: local-first memory for developers using LLM coding assistants. Their "LTM-2" engine claims nine months of on-device searchable memory, and they integrate via MCP with Claude, Cursor, GitHub Copilot, and Goose. They capture context OS-wide - IDE, browser, docs, chat - not just coding sessions.

Where they win over us: breadth. If you want memory that spans your whole computer, not just Claude Code, Pieces is the product. Their capture surface is wider.

Where Hydrate wins: architectural canon via CLAUDE.md (measured to flip Haiku from silent compliance to Opus-class pushback on adversarial prompts; see our benchmarks), git-based team sync with zero infrastructure (Pieces team sync goes through their cloud), and published benchmarks you can reproduce yourself with an API key and about $85 of credit.

Pricing comparison is impossible: Pieces doesn't publish tier figures. Our Free tier at $0 is a known quantity.

Supermemory · horizontal memory SaaS

Supermemory ships memory as a cloud service. Free tier at 1M tokens/mo, Pro at $19/mo for 3M, Scale at $399 for 80M, Enterprise custom. Supports multi-modal content (PDFs, audio, emails, web crawlers) and lists Claude Code, Cursor, OpenCode, and OpenClaw as Pro-tier plugins.

Where they win over us: content breadth. Supermemory is designed to be the memory of your professional life - emails, reports, documents, browser history - not just coding sessions. If your primary memory need is across productivity surfaces, they're closer to that than we are.

Where Hydrate wins: data custody (Supermemory holds your data; we don't - nothing leaves your laptop), per-seat pricing (their token-metered model is $19/mo for 3M tokens; ours is $9/mo with no token meter at all), Claude Max subscription doesn't get double-billed (Supermemory charges per token you send; we charge per seat regardless of Claude usage), and the CLAUDE.md canon channel.

Honest read: if you need memory across emails/PDFs/web *and* Claude Code, Supermemory covers more ground. If you need memory only for coding and care about keeping your data off cloud infrastructure, we're the better fit.

MemPalace · local RAG palace, retrospective ingestion via MCP

MemPalace is a Python local-memory system that ingests existing data - code files, Claude/ChatGPT exports, Slack logs, markdown docs - into a ChromaDB vector store organised by a spatial metaphor (wings, rooms, halls, drawers, tunnels). It exposes 29 MCP tools to any MCP-compatible assistant (Claude, ChatGPT, Cursor, Gemini CLI), with no API key required for the core local workflow. The headline feature beyond plain RAG is a knowledge-graph layer - kg_query, kg_timeline, traverse - giving entity relationships and chronological stories across wings.

The architectural difference is the most important thing to understand and isn't obvious from the docs. MemPalace indexes things that already exist - you point mempalace mine at a directory and the AI later queries it explicitly via the mempalace_search tool. Hydrate captures things happening right now - the Stop hook fires at end of session, the UserPromptSubmit hook injects relevant context before the next prompt, and the developer does nothing manually. One is a retrospective index; the other is a live session memory layer. The Reddit threads where users hand-build the MemPalace workflow are exactly the workflow Hydrate automates at the hook layer.

Where MemPalace wins over us: the knowledge graph is genuinely ahead - cross-wing traversal, entity timelines, and "what happened with the auth migration over six months" queries have no equivalent in Hydrate's current shape (the comparable work lives one layer down in SiteEngine AI). Historical ingestion is also stronger - if you have three years of conversation exports, Slack logs, and project files lying around, MemPalace can mine all of it; Hydrate accumulates forward from install. The wings/rooms/halls taxonomy is human-browsable in a way Hydrate's injection-optimised SQLite store deliberately isn't.

Where Hydrate wins:

• Zero developer overhead. MemPalace requires mempalace init, mempalace mine, and the AI explicitly calling mempalace_search. Hydrate's Stop and UserPromptSubmit hooks fire automatically - context arrives before the prompt, no tool call required.
• Team sync with canon propagation. MemPalace has agent tagging per drawer but no equivalent of hydrate team push/pull. One developer cannot push canonical facts that other developers' sessions automatically receive. The APJ Ltd result - six facts, three developers, zero conflicts - is not achievable with MemPalace's architecture as documented.
• Hydration packs. Committing an .hpack file to a repo and having a new developer import it on day one is a tested, benchmarked workflow (3.15× cheaper onboarding). MemPalace has no equivalent packaging mechanism for architectural knowledge.
• Authoritative canon channel. MemPalace stores everything as searchable nodes; nothing is pinned into the project-instructions tier of CLAUDE.md. Architectural rules sit beside ordinary recall instead of above it.
• Proven cross-vendor bidirectional sync. MemPalace claims MCP compatibility with multiple tools but does not document bidirectional memory round trips. The Claude Code ↔ Mistral Vibe experiment - five turns, facts proposed by Carol on Vibe extended by Alice on Claude Code and returned - has no MemPalace equivalent.
• Published benchmarks. MemPalace ships no benchmark data. Hydrate publishes Dick 6/6, Harry 5/6, $0.42 total, 2/7 → 7/7 sessions shipped, with source and live previews you can reproduce.

Honest verdict: MemPalace is a more serious entry than ContextForge or Mem0 - it is genuinely local-first, architecturally thoughtful, and cross-vendor, and the knowledge graph layer is the work of someone who understands the memory problem deeply. But it addresses an adjacent market: a local personal knowledge base with AI access, for people who want to make existing knowledge queryable. Hydrate is session-continuity infrastructure for live coding workflows. The right one-liner if it comes up: MemPalace mines what you already have; Hydrate remembers what you're building right now. The single-developer retrospective use case is the genuine overlap; team sync, onboarding, live-session, and cross-vendor bidirectional sync remain without a direct competitor.

Repowise · codebase intelligence layer (different problem, adjacent market)

Repowise is a Python tool that builds four indexes over a repo: a tree-sitter dependency graph (PageRank, betweenness centrality, Louvain community detection, dead-code analysis), git intelligence (hotspots, ownership, co-change pairs, bus factor), an LLM-generated living wiki, and a "Decision Intelligence" layer that parses # WHY:, # DECISION:, and # TRADEOFF: markers from source comments. Surfaces it via 7 MCP tools (get_overview, get_context, get_risk, get_why, search_codebase, …). Published benchmarks on pallets/flask: −36% cost, −19% wall time, −89% files read vs. baseline Claude Code, at parity quality. AGPL-3.0, ~1,400 stars at time of writing.

This is genuinely impressive engineering and it solves a different problem from Hydrate. Repowise answers "what does this codebase look like structurally, and how should an AI navigate it?". Hydrate answers "what happened in previous sessions on this project, and what decisions were made?". These are adjacent but distinct. A developer could legitimately use both.

Where Repowise wins over us: static codebase analysis (PageRank / community detection / dead-code via in-degree) is serious graph-algorithm work that tells an AI which files matter most before it reads a line — Hydrate has no equivalent and shouldn't try to. Git behavioural signals (co-change pair detection, bus-factor analysis) are novel; grep and static analysis cannot find them. The LLM-generated living wiki — 10 page types, 8 generation levels, token-budgeted assembly, incremental rebuild per commit — is substantial documentation infrastructure Hydrate doesn't ship.

Where Hydrate wins:

• Zero-friction capture. Repowise's 5-call sequence (get_overview → get_context → get_risk → get_why → search_codebase) requires the AI to call those tools at session start. Hydrate's UserPromptSubmit hook injects context before the prompt begins — no tool call required. This is Hydrate's most durable architectural advantage and it is not something Repowise tries to compete on.
• Decision memory vs. structural memory. Repowise knows the codebase structure. It does not know that last Tuesday you decided to use JWT over session cookies, or that Tom's convention for error handling is what the team standardised on. Those decisions live in session transcripts; Repowise has no mechanism for them.
• Team decisions at session granularity. The APJ Ltd result — six facts pushed by Tom, pulled by Dick and Harry, clean integration — is about propagating human decisions, not code structure. Repowise's ownership / bus-factor analysis tells you who knows the code; Hydrate's team sync tells the AI what the team decided.
• Cross-vendor bidirectional sync. Repowise offers MCP across Claude Code / Cursor / Cline. It does not demonstrate the bidirectional live-session memory that the Claude Code ↔ Mistral Vibe experiment proves.

Honest verdict: the market is segmenting cleanly into three problems — structural codebase intelligence (Repowise, Cody, Sourcegraph), retrospective archive search (MemPalace, Pieces, Supermemory), and live session continuity + team decision memory (Hydrate). None replaces the others. Hydrate owns the third — the one most tightly coupled to live developer workflow, the one that requires automatic capture, team sync, and cross-vendor portability.

One stylistic note worth lifting: Repowise's docs include a "failure probability matrix" — an honest list of when Repowise won't help. We do the same in our benchmark write-ups; we should make that callout more prominent here.

Mem0 · memory infra for agent builders

Mem0 solves a different problem. They're aimed at developers building AI agents - chatbots, customer-service bots, assistants - and give those agents a persistent memory via Python/JavaScript SDK. They claim 80% token reduction through memory compression, cite 100,000+ developers, and support enterprise self-hosting on Kubernetes or air-gapped servers.

Not a real competitor for the same buyer. If you're building an agent, Mem0 is a sensible choice. If you're a developer using Claude Code and want your own assistant to remember what you built yesterday, Mem0 doesn't address your use case - there's no IDE or coding-assistant integration published.

Hindsight (Vectorize) · agent memory infra with a proper local-first mode

Hindsight is the closest tool on this page to Hydrate's genuinely local-first posture - open-source Docker self-host, no cloud required, plus a pay-per-token SaaS (Retain $15/M tokens, Recall $0.75/M, Reflect $3/M) and enterprise BYOC for teams that want managed infra. The surface is three verbs - retain(), recall(), reflect() - called from your agent code; consolidation into "observations" and multi-strategy retrieval (semantic + keyword + graph + temporal) happen behind the scenes. Claude Code appears as one supported integration alongside Python and Node SDKs.

The audience split vs Hydrate is the clean bit. Hindsight is for people building AI agents - you write the agent, you decide when to call retain, the library handles the rest. That's the right architecture for a customer-support bot or a long-running research agent. Hydrate is for people using Claude Code, Mistral Vibe, or an MCP client (Cursor, Cline, Zed, Gemini CLI) as their AI assistant and wanting it to remember the project - a hook, not a library. Different shape of problem; different shape of tool.

Where this is the right pick instead of Hydrate: you're building your own agent (not a Claude Code user) and need a memory system inside that agent's application code with a bulletproof open-source self-host option. Hindsight is the better tool; Hydrate isn't a library and won't help. Where Hydrate is the right pick instead: you use Claude Code for day-to-day coding and want memory that just works without plumbing retain-calls into your editor. Installation is a one-line curl and done.

Zep · graph memory for AI agents

Zep builds a temporal knowledge graph of an agent's context - entities, relationships, fact invalidation. Their open-source core (Graphiti) is available; the managed service is cloud. They target teams building agents, not developers using coding assistants.

Same positioning as Mem0: adjacent market, not direct competition. Worth knowing about if your engineering work includes building agents in addition to using LLM coding assistants - the two use cases can be served by different tools without much overlap.

Letta (formerly MemGPT) · agent framework

Letta is the heir to the 2023 MemGPT paper - a local-first framework for building personalised agents with persistent memory. Open source. CLI and desktop app. Very solid technical foundation.

Again, adjacent: Letta is for building agents, not for using coding assistants. If you want to build a custom agent that remembers things and pays no per-seat fee, Letta is the right tool. It won't help your Claude Code session remember yesterday's refactor.

Windsurf · full IDE with baked-in memory

Windsurf is a complete editor (formerly Codeium) with an agent called Cascade, autonomous terminal execution ("Turbo Mode"), and a "Memories" feature that remembers things about your codebase and workflow. They compete by owning the editor.

Where they win: if you want an integrated everything-in-one experience and you're happy to switch editors, Windsurf is a complete offering. The memory is one feature inside a bigger product.

Where Hydrate wins: editor independence. Our users stay on Claude Code, Cursor, Zed, Cline, or Gemini CLI - whichever editor they already have. Hydrate is a memory layer, not an editor replacement. You can adopt Hydrate without giving up anything. Adopting Windsurf means switching editor.

Sourcegraph Cody · codebase-search assistant

Cody's differentiator is deep integration with Sourcegraph's search over massive codebases. It's the right choice for enterprise engineering teams working on millions of lines of code across many repositories, where "find the right code" is the bottleneck.

Not really a memory tool. Cody fetches relevant context from your codebase on demand; it doesn't remember what you decided yesterday or maintain architectural canon. Different axis.

Claude Projects · Anthropic's native feature

Claude.ai has a "Projects" feature where you can upload documents and set custom instructions per project. For a consumer or light-use case on the Claude web/desktop product, it is genuinely useful and already paid for by your Pro or Team subscription.

Where it falls short for Hydrate's target user: Claude Projects doesn't work with Claude Code. The CLI tool developers use for real coding work sits outside the Projects surface; whatever you've uploaded into your Claude.ai project is not visible to claude --print. Hydrate's whole reason for existing is the gap between "the Claude product" and "the Claude Code CLI". Projects doesn't bridge it.

ContextForge (IBM) · MCP context aggregation gateway

ContextForge is an open-source (Apache 2.0) MCP gateway from IBM that lets you aggregate multiple MCP servers behind a single endpoint, with features like context compression, caching, and prompt optimization. It runs as a self-hosted Docker container and is aimed at teams that want a shared, managed MCP layer rather than per-developer local servers.

Where they win over us: if your problem is orchestrating many MCP servers - combining memory, code search, docs, and data sources behind one endpoint - ContextForge is purpose-built for that aggregation job. The Apache 2.0 license makes it enterprise-safe for any deployment model.

Where Hydrate wins: ContextForge is an infrastructure layer, not a memory product. It has no concept of session-derived facts, architectural canon, or decay-weighted recall. It aggregates context you configure; Hydrate extracts context from your actual coding sessions and injects it intelligently at prompt time. Different job - one is a gateway, the other is a memory engine.

Graphify · graph-based code context for LLMs

Graphify builds a knowledge graph of your codebase - files, functions, imports, relationships - and exposes it via MCP so LLMs can navigate your code structure rather than just embedding-search over raw text. Useful for answering "where is X defined and what calls it?" with structural precision.

Where they win over us: if your memory problem is structural code understanding - "what does this module depend on?", "which files would break if I change this interface?" - Graphify's graph representation is the more precise tool. It models the code, not the decisions.

Where Hydrate wins: Graphify has no concept of session history, architectural decisions made by the team, or the "why we chose this pattern" context that lives in your chat transcripts. It knows your code exists; Hydrate knows what you decided about your code. Complementary tools, not head-to-head competitors - a team could use both without conflict.

Caveman · Claude Code compression hooks, open source

Caveman is an open-source collection of Claude Code hooks and utilities centred on keeping CLAUDE.md manageable. The core idea: run caveman-compress before a session and your project markdown is compressed by Claude into a tighter version; a UserPromptSubmit hook then injects a mode-aware reminder on every turn, stripping inactive-mode rows so the model doesn't see stale context. Simple, transparent, zero installation friction.

Where it wins over us: if you want a thin hook layer you can read in an afternoon and have full control over, Caveman is the right pick. No binary, no SQLite, no moving parts.

Where Hydrate is architecturally ahead:

• Compression is write-time via Claude (one extra LLM call). Hydrate compresses at read-time using a TF-IDF NLP compressor - no LLM call in the capture path, no cost, no latency spike.
• No semantic retrieval. Caveman injects a static block on every turn. Hydrate scores each fact against the current prompt by embedding cosine similarity and only injects what is relevant - a significant difference once your fact store has more than a few dozen items.
• No session history storage. Caveman's reminder is a rule you configure; Hydrate's injection is built from what actually happened in past sessions. The two tools capture different things.
• No authoritative canon channel. Caveman compresses the markdown you have into shorter markdown. Hydrate's hydrate sync writes pinned rules into the project-instructions layer of CLAUDE.md - a different authority tier, measured to improve model compliance on architecture-sensitive prompts.

Honest verdict: Caveman and Hydrate are solving adjacent problems. Caveman manages what you write in CLAUDE.md; Hydrate manages what the model learns from your sessions. A team could reasonably use both.

Rocky · Claude Code session memory via SessionStart hook, open source

Rocky is a lightweight open-source tool that captures Claude Code session outputs and replays them into the next session via a SessionStart hook. The intent is solid: give Claude Code a memory of what you worked on last. The implementation is clean and readable.

The architectural gap is the hook event. SessionStart fires once, at the opening of a session. UserPromptSubmit - the hook Hydrate uses - fires on every single prompt. That distinction is not cosmetic: Claude Code compacts its context window during long sessions, and any facts injected only at session start will be compacted out. Hydrate re-injects on every prompt, so relevant context is always in the active window regardless of session length.

Remaining gaps from the analysis:

• No mode-filtered injection. Hydrate selects summary_32 in standard mode and summary_16 in economy or turbo - token cost scales with the mode. Rocky injects a fixed payload.
• No semantic retrieval. Rocky replays previous session output; Hydrate scores recalled sessions by embedding cosine similarity to the current prompt and only surfaces relevant ones.
• No LLM-free summarization. Hydrate's session summaries are built by a TF-IDF NLP compressor (three tiers: 64 / 32 / 16 words) with zero LLM calls in the capture path. That matters for cost when you're closing sessions frequently.
• No CLAUDE.md compression or authoritative canon channel.

Honest verdict: Rocky is a good 50-line proof of concept for the idea that session memory should carry between Claude Code runs. Hydrate is what that idea looks like fully built out - with the hook event corrected, three-tier compression, semantic retrieval, and the canon channel. If you tried Rocky first and wanted more, Hydrate is the natural next step.

claude-mem · Claude Code transcript-to-memory extractor, open source

claude-mem (thedotmack/claude-mem, Apache 2.0) is an open-source tool that turns finished Claude Code sessions into searchable memos and feeds matches back into later sessions. It runs as Claude Code hooks plus a few slash commands; everything lives on the developer's machine. The author's research pass shaped our own nextphase roadmap, so the overlap is real — both tools agree that pre-prompt injection beats retrieval-on-demand.

Stack: Node.js + Bun + uv (Python) + SQLite + Chroma vector DB. Hook surface: SessionStart, UserPromptSubmit, PostToolUse, Stop, SessionEnd.

Where the surfaces overlap: transcript extraction into atomic units; injection on session start.

Where the design choices differ: claude-mem stores typed observations without time-based decay, so older memos sit alongside newer ones at equal weight. Hydrate weights every fact by recency and re-rank on each retrieval. The project also claims cross-vendor reach via an adapter layer for seven harnesses; in practice the canonical surface is the Claude Code hook set. Hydrate's 22 MCP tools work natively from Cursor, Cline, Zed, Gemini CLI and Mistral Vibe without an adapter translation layer.

Where Hydrate is broader today:

• Sub-agents. Hydrate ships three Claude Code sub-agents — hydrate-recall-agent, hydrate-distill-agent, hydrate-canon-curator-agent — each scoped to the minimum MCP tool surface for its workflow. claude-mem doesn't ship a sub-agent layer.
• Hydration Packs. Hydrate writes .hpack bundles that a teammate (or an on-call dev on an unfamiliar service) loads with one command and gets the architecture, conventions and known-broken edges injected on the next prompt. claude-mem's memos are personal and per-machine.
• Team Memory as Git. Hydrate's team-sync layer is a git repo you already control — push from one machine, pull on another, code-review the canon like code. claude-mem is single-user.
• Cross-vendor MCP. 22 Hydrate MCP tools work from Cursor, Cline, Zed, Gemini CLI and Mistral Vibe, not just Claude Code. claude-mem stays in the Claude Code hook surface.

Where claude-mem is the right pick instead: you only use Claude Code, you only have one machine, and you want the simplest possible install footprint. claude-mem is a tighter tool for that single shape of problem. Where Hydrate is the right pick instead: you work across more than one tool, more than one machine, or with other developers — anywhere the "memory has to leave this laptop" line gets crossed.

claude-bootstrap (Maggy) · goal + fatigue scaffolding for long Claude Code sessions, open source

claude-bootstrap (alinaqi/claude-bootstrap, rebranded Maggy, MIT) wraps Claude Code with two ideas Hydrate doesn't yet ship: a goal-node lane that keeps the current intent pinned through compactions, and a fatigue model that watches session-health signals and nudges the developer to distil before a session collapses. These are good ideas. We're tracking parity, not pretending to already have them.

Stack: Python + Bash + FastAPI + SQLite + WebSocket. Hook surface: Stop, PreCompact, PreToolUse, plus a lifecycle layer that auto-restores on SessionStart. Claude Code only; cross-vendor reach is delegated via shell to other tools.

What claude-bootstrap ships that Hydrate doesn't yet:

• Goal-node lane. A protected fact category for the current task's intent, distinct from pinned canon — survives compactions and dream/compress cycles by design. On the Hydrate roadmap as nextphase-4-goal-node-lane (status: pending, design pass needed).
• Fatigue signals. Passive session-health pane — token utilisation, scope scatter, re-read ratio, error density — that suggests /hydrate-distill before failure mode kicks in. On the roadmap as nextphase-6-fatigue-signals (status: pending).
• PreToolUse re-injection. claude-bootstrap re-injects the goal stack on every tool call — Maggy's "Layer 2 guaranteed" pattern. On the roadmap as nextphase-5-pretooluse-reinject (depends on nextphase-4 landing first).
• Polyphony. Docker-isolated multi-agent orchestration: spawn multiple Claude Code agents in separate containers under one coordinator. That is a different problem from Hydrate's Team Memory as Git (multi-developer canon merge with a manifest and history). Both are useful; they do not substitute for each other.

What Hydrate ships that claude-bootstrap doesn't: Hydration Packs (portable project context), Team Memory as Git, cross-vendor MCP (22 tools beyond Claude Code), per-fact decay with FTS5 + cosine + recency-weighted retrieval, a canonical hydrate sync → CLAUDE.md channel for authoritative rules, and a Free-tier dashboard with the runway KPI.

Where claude-bootstrap is the right pick instead: long single-developer Claude Code sessions where the failure mode is losing the current goal mid-compaction, or where you want a passive fatigue-detection signal on your screen today. Where Hydrate is the right pick instead: any workflow that crosses a machine, a teammate, or a vendor boundary. We will catch up on the goal-node and fatigue surfaces; cross-tool, cross-machine memory portability is the architectural bet only Hydrate is making.

Ormah · involuntary-memory pre-prompt injection, open source

Ormah (r-spade/ormah, MIT) ships the closest direct architectural sibling to Hydrate we have found. Its tagline, "memory should be involuntary," covers the same shape of idea: facts surface before the next prompt rather than waiting for a tool call. Where claude-mem and claude-bootstrap each scope to Claude Code, Ormah's reach is wider out of the gate — Claude Code, Codex, Claude Desktop, plus an HTTP API and a CLI.

Stack: Python + local embeddings + knowledge-graph storage. Surface: "whisper" hooks for pre-prompt injection, an MCP server, and an HTTP API. Decay is described as "scored and decayed" — the mechanics are not documented.

Where the surfaces overlap: pre-prompt injection as the primary read path (not retrieval-on-demand); local-first storage; cross-vendor reach via MCP.

Where Hydrate is different:

• Documented per-fact decay. Hydrate's time-based decay rule and the FTS5 + cosine + recency-weighted ranker are specced in docs/thesis/04_MEMORY_RETRIEVAL.md. Ormah's scoring-and-decay mechanics are described in narrative terms; the formula is not public.
• Encrypted Hydration Packs. Hydrate writes portable .hpack bundles for moving project context between machines and projects. Ormah's portability is implicit ("copy the local directory") with no bundling format.
• Team Memory as Git. Hydrate's multi-developer canon merge is a git repo with a manifest. Ormah is single-developer.
• Compact-survival pair. Hydrate's PreCompact and SessionStart hooks snapshot before Claude Code's auto-compaction and restore on the next session. Ormah handles long sessions through transcript backfill after the fact; there is no PreCompact-equivalent.
• Go stdlib audit surface. Two binaries you can read in an afternoon. Ormah's Python plus embeddings plus graph runtime is a wider audit surface for security review.

Where Ormah is the right pick instead: single developer, want the broadest agent-side reach (HTTP API and CLI in addition to MCP), comfortable with a Python plus embeddings-plus-graph stack, and the team-memory and pack features are not on your shortlist. Where Hydrate is the right pick instead: anywhere the line "memory has to leave this laptop" gets crossed — a teammate, another machine, a portable project bundle, or a compliance review that wants a small audit surface.