Every metric below is measured on a clean Linux host through the real CLI and MCP tool paths — nothing is modelled, and anything estimated is labelled as estimated by the data itself rather than by the prose around it. The methodology and the limitations come first, because a benchmark without them is a marketing number.
All values are measured on a clean Linux x64 host (AMD EPYC 9454P, 125 GB RAM, Node 24, NVMe) via scripts/perf-benchmark.mjs against the real zephr CLI + MCP tool paths — single-node, local-first SQLite. Recall is the lexical/BM25 hybrid retrieval path (single-threaded); semantic vector recall runs on the in-DB pgvector primary. See docs/operations/PERFORMANCE-BENCHMARK-2026-07-23.md for full methodology and raw evidence.
AMD EPYC 9454P, 125 GB RAM, Node 24, NVMe, Linux x64. Single-node, local-first SQLite. This is not a distributed test, and no number here should be read as a cluster result.
100 / 1K / 10K stored beliefs in a single worktree. Recall is the lexical/BM25 hybrid path, single-threaded. Semantic vector recall runs on the in-DB pgvector primary.
No multi-tenant isolation tested. No network latency. No adversarial input. Cross-client handoff is an in-process format round-trip, not a full CLI subprocess end-to-end run.
Host: AMD EPYC 9454P 48-Core Processor / 125.5GB / Node v24.18.0 / linux-x64 · generated 2026-07-23 · source: scripts/benchmark-results.json
node scripts/perf-benchmark.mjsThree recall workloads, measured at three store sizes. The replay presents the committed measured values — it does not re-measure. The command to produce them yourself is below.
$ zephr recall "the PKCE decision" --store 100
measured values from the committed results artifact — the replay presents them, it does not re-measure
bars share one scale (max p99 26 ms) so the shape of the curve is the honest comparison
Recall@10 query latency for 100 / 1K / 10K stored beliefs, through the real zephr_recall handler — lexical/BM25 hybrid, single-threaded. The bars share one p99 scale, so the shape of the curve is the honest comparison rather than three independently flattering charts.
recall@10: 100%
recall@10: 100%
recall@10: 100%
recall@10 is the measured hit rate of the target belief in the top ten results — not a quality score and not a relevance judgement.
Core operations measured through the real zephr CLI and MCP tool paths. Each card carries the methodology string straight from the benchmark output, so the sentence describing how a number was produced travels with the number.
Sequential single-writer writes per second — idempotent remember with a content digest.
real zephr_remember handler, sequential single-writer, file-backed SQLite
Time to create a recovery snapshot and independently verify its integrity.
create = better-sqlite3 backup (WAL-truncated); verify = store.verifyBackup (integrity_check + schema/table validation); cliTotal = full `zephr-mcp snapshot` subprocess
CLI warm-start time — page-cache hot, median of subsequent invocations.
subprocess wall time; cold = first invocation, warm = median of subsequent (page-cache hot). `project list --help` is not a valid invocation (--help rejected), so `version` (pure startup) and `project list` (startup + registry read) are measured.
The snapshot phases separated from the full CLI command, because a number that quietly folds in process startup is a different number.
Each number is a wall-time sample from the real tool or CLI subprocess on the benchmark host. Nothing is synthetically modelled. If a value were estimated rather than measured, its badge would say so — the label comes from the data file, not from the copy on this page.
Values are measured — imported from scripts/benchmark-results.json. This card's layout is illustrative; the numbers in it are not.
Continuity envelope round-trip — build → canonicalize → parse → validate — with the identical format across Claude Code, Cursor, and Codex. The per-client adapter delta is not isolated, because the format round-trip applies uniformly; presenting three different numbers would imply a measurement that was not taken. Tested against 32 tools declared in lib/platform/shared-facts.ts.
0.5 ms
measured · in-process format round-trip
0.5 ms
measured · in-process format round-trip
0.5 ms
measured · in-process format round-trip
Average round-trip: 0.5 ms. The full CLI command round-trip (269 ms) is the honest end-to-end figure — it includes roughly two Node process startups, and it is the one to quote if you care about the wall time a developer actually waits.
node scripts/perf-benchmark.mjs --filter continuity7 client integrations declared in shared-facts.ts · cross-client handoff tested against Claude Code, Cursor, Codex
Close
Every benchmark on this page links to its source, and every source is a file in the repository. The trust model these numbers support is documented the same way.