We built Hydrate for Copilot using Hydrate.
Nine weeks of implementation - a full VS Code extension, backend additions, audit + compliance surface, enterprise Windows MSI, benchmarking harness, and launch-ready website - with Hydrate itself managing the project memory. The canon set on day one was still authoritative on day sixty-three. When a late-stage instinct nearly contradicted it, Hydrate caught the drift before any code got written.
What we built
A VS Code extension making Hydrate a first-class citizen of GitHub Copilot; a handful of backend endpoints to serve it; the offline-resilience layer that wraps them; an audit surface + Markdown compliance report subcommand for EU AI Act evidence; a Windows MSI with Group Policy templates; a measurement harness that ran against two independent codebases; and the landing + benchmarks surfaces that sit under this page today.
The mechanic: canon + recall, every turn
On the first day of the sprint we pinned six canon facts into
the hydrate-copilot project scope. Five architectural
(one binary, one database; editor-agnostic HTTP API; source
attribution not source partitioning; monorepo; chat-first
inline-later). One release-hold added mid-sprint when the
commercial launch sequence required it. From that point onward,
every recall call in the project returned these facts at the top
of the rendered context - the model saw them on every turn
without being asked.
Over the subsequent nine weeks the project accumulated 195 recall calls and 24 compress calls. Every recall surfaced the canon as the first thing the model saw. When an instinct in a late-stage week would have contradicted a day-one decision (the most memorable example: late Phase 28, an instinct to "just add a second daemon for the Copilot path" - directly at odds with canon fact #1, one binary, one database), the canon block was already in the prompt. The correction happened in-place. No drift, no rewrite, no post-hoc dream-cycle contradiction report needed.
That is the quiet thing Hydrate does well. The model doesn't become smarter. It stops drifting.
What Hydrate recorded about itself
The hydrate-copilot project scope in Hydrate's own
SQLite store holds the ledger of its own construction. Exact
figures from that ledger, queried on 2026-04-22:
- 6 canon facts - each surfaced in the recall block above every in-project prompt
- 195 recall calls - ~59 tokens per call on average, dominated by canon + scope context
- 24 compress calls - against CLAUDE.md, the spec doc, and mid-sprint plan drafts
- 10 copilot-sourced measurement-harness calls
- 1 captured session - the sprint itself, ~110 MB of transcript
The same numbers drive the "Built with Claude Code" tile on the homepage. This page exists so a reader who wants the sprint's narrative - not just the cost figure - has somewhere to go.
What this case study is about
Most Hydrate pitches lean on the quantitative benchmarks - the ship-rate improvements, the cost-per-session figures, the token-reduction numbers. Those are the numbers a buyer asks for. But the Hydrate-for-Copilot build itself produced a different kind of evidence: a nine-week sprint where six canon facts held the architecture together through 195 recall calls and never got violated.
The product we built is the product that built it. The canon that pinned our architecture is the same mechanism a team would pin theirs. The recall path that surfaced those facts on every turn is the same path that surfaces decisions for a Copilot Enterprise developer joining a codebase on day one.
The benchmarks page covers what Hydrate does for a developer using Copilot. This page is about what Hydrate did for us while we built that.