2026-04-22 · 7 min read

We ran 18 sequential Claude Code sessions across three developers. Team sync cut costs 39%.

Canon propagation is the mechanism. The numbers are from a controlled experiment: 9 sessions baseline, 9 sessions with Hydrate team sync, same tasks, same model, same prompts. Round 2 - where teammates build on each other's work - showed 51% cost reduction and 44% fewer turns. Here's what happened.

The setup

Three developers - alice, bob, carol - each in their own isolated Docker container with a separate Hydrate installation, a shared git remote, and no way to communicate except through code commits and Hydrate's team sync. They built a Go CLI tool called jsonls across 9 sequential sessions: alice builds the foundation, bob adds filtering and tail, carol adds export and linting, then each developer circles back for their second and third tasks.

We ran the entire sequence twice. The baseline run had HYDRATE_DISABLED=1 set - hooks still fired but exited immediately, no fact capture, no team sync, no context injection. The team run had full Hydrate: hydrate team sync before each session, hydrate team push after. Everything else was identical - same prompts, same model (claude-sonnet-4-6), same --max-turns 25 cap.

The headline numbers

39%

lower total cost with team sync

27%

fewer turns to complete each task

53%

fewer cache-read tokens consumed

Baseline: 8 sessions (s2 OOM-killed during infrastructure fix, excluded from totals), 88 turns, $1.664. Team: 9 sessions, 64 turns, $1.015.

The full data

Session	Dev	Task	BL turns	BL cost	TM turns	TM cost	Δ cost
s1	alice	Bootstrap Go module + parse	8	$0.112	9	$0.079	−30%
s2	bob	filter subcommand	OOM	-	7	$0.140	n/a
s3	carol	export subcommand	12	$0.243	6	$0.101	−58%
s4	alice	top subcommand	13	$0.258	6	$0.116	−55%
s5	bob	tail + --follow	11	$0.292	11	$0.140	−52%
s6	carol	lint + schema validation	12	$0.244	3	$0.129	−47%
s7	alice	version + build ldflags	12	$0.214	8	$0.113	−47%
s8	bob	Refactor: extract OpenInput helper	15	$0.244	10	$0.154	−37%
s9	carol	Makefile (build/test/lint/fmt)	5	$0.057	4	$0.044	−23%

Round boundaries: s1-s3 are first encounters, s4-s6 are round 2 (each developer's second task), s7-s9 are round 3. The round-2 effect is the strongest because that's where canon propagation has the most to offer - alice's conventions are established, and bob and carol can build on them without re-discovery.

The mechanism: canon propagation

Alice's first session established the codebase's character. Not in documentation - in facts captured by Hydrate and pushed to the shared team repo:

Module path is github.com/team/jsonls
All file I/O goes through internal/jsonlines.NewReader
Tests are table-driven with t.Run
Errors use fmt.Errorf("...: %w", err) - no third-party error packages
Dependency policy: stdlib-only, no cobra, no external parsers

In the baseline run, bob (s2) and carol (s3) both spent 3-5 turns exploring the module structure to discover these conventions. They read go.mod, read the existing subcommands, inferred patterns from what alice built. Standard work - but entirely redundant when those facts are already captured.

In the team run, bob and carol arrived at the start of their sessions with a context block that included alice's facts. They confirmed the patterns were in place rather than re-discovering them. Carol's lint task (s6) went from 12 turns to 3 turns - she knew gopkg.in/yaml.v3 was already in go.mod and that internal/jsonlines was the canonical reader. She didn't need to look. She built.

The round-by-round breakdown

Round	Sessions	BL avg cost	TM avg cost	Cost saving	BL avg turns	TM avg turns	Turn saving
Round 1	s1, s3 (s2 OOM)	$0.178	$0.107	−40%	10.0	7.3	−27%
Round 2	s4, s5, s6	$0.265	$0.128	−52%	12.0	6.7	−44%
Round 3	s7, s8, s9	$0.172	$0.104	−40%	10.7	7.3	−31%

Round 2 is the strongest because the canon is fully established (from round 1) and each developer is now extending a mature codebase built by colleagues they've never spoken to directly. The baseline developer must re-read everything. The Hydrate developer arrives knowing it.

What baseline developers actually did with those extra turns

We looked at the stream logs for the 12-turn and 13-turn baseline sessions to understand what the "exploration turns" were doing. The pattern was consistent across alice (s4), bob (s5), and carol (s6):

Turns 1-3: Read go.mod, read main.go, list the subcommands, understand the current CLI surface.
Turns 4-5: Read an existing subcommand implementation to understand the error convention, the flag parsing style, the reader abstraction.
Turn 6+: Begin building the new subcommand, now with enough context to make it consistent.

With Hydrate, turns 1-5 collapse to zero. The facts that would have been extracted via file-reading are already in the context block. The developer starts at turn 1 with the knowledge that took baseline sessions 5 turns to accumulate.

This is the literal cost of not having team memory. Not token waste - turn waste. A developer re-reading files their colleague already read is burning real money to re-derive decisions that already exist.

The cache-read signal

One number surprised us: baseline sessions consumed 1.59 million cache-read tokens across 8 sessions; team sessions consumed 745,000 - 53% fewer. We expected the team run to use more cache-read tokens, because the injected context from Hydrate is served from cache. Instead, the per-session total was lower.

The reason: baseline developers read the same files repeatedly across turns. Every Read tool call on a file that's already in the conversation context still generates cache-read tokens. Hydrate replaces those file-read loops with a single injected context block, which is cached once and never re-read. Fewer file reads means fewer cache-read events, even though the injected facts themselves are cached.

What this doesn't prove

This experiment used AI developers (Claude Code agents in Docker containers), not human developers. Human developers may notice conventions from code review, commit history, or informal communication in ways the agents couldn't. The effect on human teams would be different - possibly smaller where developers already have good communication habits, possibly larger where those habits don't exist.

The scenario was also greenfield: a fresh codebase with no legacy. Brownfield work - where conventions are implicit, partially documented, and often contradictory - is a harder test and not measured here.

The tasks were also mechanical. Implementing a subcommand to a known spec is not the same as architectural decision-making, debugging distributed systems, or the kinds of ambiguous work where a senior developer earns their salary. Hydrate can only inject facts that have been captured. If no one decided anything, there's nothing to propagate.

The point

The experiment is a controlled demonstration of a single mechanism: when one developer decides something, and Hydrate captures it, subsequent developers don't need to re-derive it. That's the whole story. The 39% cost reduction and 27% turn reduction are the arithmetic consequence of that mechanism applied across 18 sessions.

At team scale, the arithmetic compounds. A 10-developer team doing 3 sessions per day each generates ~30 sessions of fact propagation per day. Over a sprint, the facts every developer has captured become the shared knowledge base everyone inherits at session start. The codebase grows; the context a developer needs to be productive stays loaded.

Full methodology and raw data →