You're sceptical. Good.
There are too many AI tools, and most fade in a quarter. Below is the same FAQ I'd answer if you buttonholed me at a meetup.
If a question is missing, file an issue at github.com/getHydrate/hydrate-public. We add the ones that come up twice.
Is this just RAG?
No. RAG retrieves from a fixed external corpus you've prepared ahead of time (docs, manuals, codebases at rest). Hydrate is the opposite arrow: it writes during a coding session — capturing your prompts, the model's decisions, the files you touched, the facts the agent learned — and then retrieves from that write-history on the next prompt.
The corpus is your own work, growing with every session. docs/thesis/15_THREE_LAYER_MEMORY.md goes into the three-layer model.
Is this just vector search?
No. Hydrate runs FTS5 keyword match, cosine similarity over local embeddings, and a decay function over both. No single retrieval mode dominates — different prompts surface different shapes of memory. See docs/thesis/04_RETRIEVAL.md for the blend.
Why not CLAUDE.md?
CLAUDE.md is static. You curate it by hand; it goes stale; you re-curate it. Hydrate is the retrieval layer that injects only the relevant subset of your project knowledge into each prompt — automatically, ranked, time-decayed.
Already invested in CLAUDE.md? hydrate dehydrate migrates a CLAUDE.md into
facts in one command so you don't lose what you've curated. Pro feature.
Why not the MCP "memory" server?
Hydrate ships an MCP server today (hydrate-mcp). The question is not
whether there's an MCP server, it's what backs it. Hydrate's backing
store survives /clear, /compact, machine restart, and
cross-runtime jumps (Claude to Codex to Vibe). The stock MCP memory server forgets when
the session ends.
Does memory really carry across Claude, Codex, and Vibe?
Yes, and it does so via per-event hook binaries, not just MCP.
Each of the three runtimes has its own family of hooks
(claude-context, codex-context,
vibe-context, and so on); Claude and Codex share
an adapter layer that normalises each runtime's stdin JSON to
a single canonical event, while Vibe's binaries are standalone
implementations that read the same shared helpers. The
user-visible result: a fact captured during a Claude Code
session is immediately retrievable from a Codex or Vibe
session, and vice versa. The per-event mapping table is at
/docs/hooks; the architecture write-up
is thesis chapter 27.
Why not Mem0 / Zep / claude-mem?
These are four different products with four different tradeoffs. We wrote one-pagers for each so you can compare apples to apples:
- /compare/claude-mem/: head-to-head benchmark
(
compact-survival: Hydrate 63% vs claude-mem 7%, n=30 per tool, 95% CI 46 to 78%). - /compare/bytebell/: enterprise team memory.
- Mem0 and Zep head-to-heads are in the works; see the comparisons index for the current set.
What runs locally vs what's transmitted?
Local by default. Your facts live in a SQLite database at
~/.hydrate/data.db. Nothing is transmitted unless you explicitly enable
enterprise sync to a server you control. No telemetry, no analytics call-home, no model
fine-tuning on your data.
Verify it yourself: lsof -p $(pgrep hydrate-server) shows every file and
socket the local server has open.
What if hooks break?
Fail-open invariant. Every hook shim (claude-context,
claude-capture, codex-context, etc.) is designed to exit 0
with empty output on every failure mode — unreachable server, slow response, malformed
JSON, anything. Your prompt never blocks waiting on Hydrate.
This is enforced as Invariant #1 in
CLAUDE.md
and tested in bench/regression/tests/t1-* and
t2-codex-hook-fail-open.sh.
What's the overhead?
p50 hook latency is in single-digit milliseconds; p99 is bounded by a 100 ms timeout that lets your prompt continue regardless. Live numbers, n and 95% CI, in bench/hook-latency/RESULTS.md .
If the local server is slow or unreachable, the hook exits immediately rather than waiting.
What about model bills?
Hydrate uses extractive NLP for fact capture by default — no LLM call per turn. Optional LLM-backed dream cycles run on your existing API key, batched, with cost caps you set. The default-off design exists specifically so the Free tier costs you nothing per token.
Is this a venture-backed startup that will pivot in 18 months?
No. Hydrate is a small independent project. The local product will always be free. Pro and Team licences fund development. The data format (SQLite) is open enough that you could fork and maintain your own copy if we vanished tomorrow.
How do I uninstall cleanly?
hydrate uninstall-hooks
rm -rf ~/.hydrate
brew uninstall hydrate # or: rm ~/.local/bin/hydrate*No registry keys, no LaunchAgents, no leftover processes.