How to get the most out of Hydrate.

Start with architecture.

The first session of a project seeds your memory store. Everything downstream reads from it. A vague s1 produces vague facts produces vague s2.

The strongest pattern we've measured is hybrid mode: one expensive, architecturally-loaded session to set conventions (Sonnet or Opus), then Haiku + Hydrate for the rest. Hydrate captures the decisions - CSS tokens, component boundaries, naming - and Haiku reads them back in-style.

# Session 1 - seed the architecture
claude --model claude-sonnet-4-6 "Set up the Pulse landing page:
  Next.js 16 + Tailwind 4, dark-first with CSS var tokens, a hero
  + features + footer. Make it production-grade."

# Sessions 2-N - Haiku carries it
claude --model claude-haiku-4-5 "Add a pricing section with three tiers"
claude --model claude-haiku-4-5 "Add dark mode toggle, respect prefers-color-scheme"
# …

Hybrid mode total spend in our benchmark: $1.41, vs $3.13 for pure Sonnet - 45% of cost at Sonnet-tier design quality.

Scope your projects.

Hydrate stores facts at three levels: org (Enterprise policy), user (your preferences), and project (this codebase). Project is the default for anything a classifier considers project-specific - "pricing tiers are Free/Pro/Team", "we use pnpm", "the docs live at /docs".

A cd into a project directory scopes Hydrate automatically - there's no explicit "activate project" command. Cross-project work stays clean because the scope-union retrieval only pulls in the project you're actually in.

# Review facts scoped to the current project
hydrate facts list --scope=project

# Promote a fact to user-scope (applies across every project)
hydrate facts promote fact_7f3a --to=user

# Delete a stale fact
hydrate facts forget fact_7f3a

Trust the injection, but verify.

Occasionally a fact drifts out of sync with reality - you decided to rename the accent colour, but the old name is still in Hydrate's store. The model then "knows" something that isn't true any more.

Two defences: weekly hydrate facts review surfaces facts that haven't been confirmed recently, and hydrate facts diff shows which facts were injected into your last session so you can spot stale ones in context.

# See what Hydrate told Claude Code last session
hydrate facts diff --last-session

# Walk through all facts older than 14 days
hydrate facts review --stale-days=14

Dashboard as your thermometer.

Open http://localhost:49849/dashboard in a browser tab (default port; run cat ~/.hydrate/server.port if yours differs). It shows input / output / cache-read / cache-creation per project, a tokens-saved estimate from memory injection, and a per-project table sorted by last-touched.

The number to watch is cache-read ratio. When it drops below ~60% on a long-running project, your fact store has drifted far enough that injections no longer hit cache cleanly. That's your signal to run hydrate facts review.

Back up before handoff.

Pairing with a teammate? Moving a project from one machine to another? Back up the project's memory as a portable bundle. They hydrate restore it and their Claude Code inherits every decision you've made.

# Back up everything Hydrate knows about this project
hydrate backup --project=pulse

# On the receiving side
hydrate restore pulse.hyd.json

Team tier makes this automatic - shared project facts propagate across seats without a backup / restore dance. For Free and Pro, the encrypted bundle is the escape hatch.

Dehydrate is a different feature, included on every tier. It's a hygiene tool: it ingests your CLAUDE.md and docs/ into Hydrate's memory and rewrites the markdown into a lean summary (or stub). Claude Code still gets the full context via memory injection. Backup / restore is about portability; dehydrate is about keeping your source markdown maintainable. Different problem, different command. See the dehydrate docs →