Hydrate is not just a Claude Code hook

Two shapes, one store

Hydrate is a local SQLite-backed memory store plus a HTTP server that reads and writes it. Anything that can talk to that server gets memory. Today, two shapes of integration exist:

1. Native Claude Code hooks. Two tiny binaries (claude-context, claude-capture) wired into Claude Code's UserPromptSubmit and Stop events. Zero friction. Fires on every turn automatically. The developer never calls a tool by hand. This is the shape most of our benchmarks exercise, because it captures every session without intervention.
2. MCP over stdio. A third binary, hydrate-mcp, that speaks the Model Context Protocol. The model chooses when to call Hydrate tools: hydrate_recall, hydrate_save_fact, hydrate_list_projects. Ships today on Gemini CLI. Works with Cursor, Cline, Continue, Windsurf, Zed, and Claude Desktop with a one-line config per client.

Both read from and write to the same SQLite file. Same facts, same session summaries, same pinned canon. The shape of the integration decides how the agent reaches the store, not what it finds there.

Why the MCP path matters for product risk

Claude Code's hook API is unversioned. A breaking change could ship in any minor release of the CLI. When people say "Hydrate is a Claude Code plugin," the implicit worry is that Hydrate dies the day Anthropic deletes hooks. That framing is wrong in two ways.

First, the hooks are thin. After the v0.3 refactor, each hook binary is around a hundred lines of glue. All the HTTP plumbing lives in a shared internal/hookclient package; the binaries are just parse-stdin → call-one-function → emit-stdout. If Anthropic ships a protocol change, the fix is localised and small. We already track tested Claude Code versions in hydrate doctor so the user sees a warning the moment the installed CLI drifts past the tested band.

Second, and more importantly: every agent that speaks MCP gets Hydrate automatically. Gemini CLI shipped with Hydrate memory the day we released hydrate-mcp. Cursor, Cline, Continue, and Zed inherit the same binary. If the whole Claude Code hook path disappeared tomorrow, Hydrate still works on every MCP-capable agent. The MCP path isn't insurance we plan to cash - it's the default answer to the question "does this integrate with X?" for any X that post-dates MCP.

The trade-offs, honestly

The hook path is better for the user who wants memory they don't have to think about. Every session captured, every prompt enriched, zero prompting. The MCP path is better for the user who wants explicit control - the model calls hydrate_recall when it decides it needs context. For most developers, both are fine; the choice is made for them by whichever agent they already use.

The MCP path does lose a little automatic capture. In a Cursor session, Hydrate only stores what the model explicitly saves via hydrate_save_fact; we don't have a background listener on the conversation. That's a real product gap, and it's on the roadmap. For now, the right mental model is: Claude Code users get memory in the background; every other agent gets memory on demand.

What this means for pricing

When we launched we considered making Hydrate "the Claude Code memory add-on". We didn't, and we're glad. Scoping it to one agent would have meant scoping it to one company's roadmap. Hydrate is a memory system that happens to have native Claude Code hooks - not the other way around. Free, Pro, and Enterprise all work on any agent that speaks MCP or fires Claude Code hooks. The integration shape doesn't change the tier you're on.

See for yourself

• Integrations overview - both shapes side by side
• Gemini CLI setup - the MCP path, end to end
• Claude Code setup - the hook path, 30-second install

Written 2026-04-19 after a business-partner conversation about platform-risk on the Claude Code hook API. The answer to that risk is in this post.