Most products in this space want to be a platform, a model, or a cloud service. Hydrate is none of those. Here are ten assumptions people arrive with — and what is actually going on.
Hydrate has no model. It carries context between sessions of whichever model you already pay for — Claude, GPT, Mistral, Gemini. The model bill stays with the vendor; Hydrate just stops you from paying for it twice on the same context.
Your code, prompts, and memory never leave your machine unless you opt into team sync (which is a git remote you control). There is no Hydrate cloud, no shared backend, no telemetry pipe to us.
Hydrate stores facts and session summaries in local SQLite, with FTS5 for keyword search and optional embeddings for similarity. It is operational state, not a corpus. We are not competing with Pinecone or Chroma; you can run one of those alongside Hydrate if your product needs RAG.
There is no chat interface in Hydrate. The product is a memory layer underneath the coding agent you already use. The interface is your existing Claude Code / Copilot / Codex / Vibe session — Hydrate is the thing that makes it remember.
Hydrate runs in addition to those tools, not instead of them. It hooks into each runtime to inject context before prompts and capture facts after responses. You keep your existing subscription and IDE flow; Hydrate adds memory portability across them.
Team Memory uses git as the sync layer. You push to a remote you own (GitHub, GitLab, self-hosted), other developers pull. Code-review tooling becomes review tooling for shared decisions. No Hydrate-hosted sync infrastructure exists.
No model anywhere is trained on your code, prompts, or memory. Hydrate is not in the data-flywheel business. The architecture has no upload path to a training pipeline; there is no training pipeline.
Hydrate captures what you choose to capture (session summaries, facts, canon). You can inspect, redact, or delete any of it from the dashboard. The local store is a regular SQLite file at ~/.hydrate/data.db — open it in any sqlite browser. Nothing is hidden.
Hydrate ships builders that generate skills, hooks, and phased plans, but the product is the memory layer, not the templates. Skills live in your project repo where you can edit them; Hydrate just helps you bootstrap them.
Hydrate does not proxy LLM calls. It runs alongside your existing runtimes and intercepts at the hook layer (UserPromptSubmit, Stop, PreCompact, SessionStart). API requests go directly from your runtime to the vendor; Hydrate never sees them.
Hydrate is a local memory service that sits underneath your coding agent. It hooks into the runtime (Claude Code, Codex, Vibe, or any MCP client), injects relevant context before each prompt, and captures decisions after each response. The store is a SQLite file on your machine. Optional team sync is a git remote you own. There is no cloud, no model, no training pipeline, no proxy.
It is infrastructure, not a product surface. Most days you will not think about it. You will just notice that the next session knows what you decided in the last one.