Wax hybrid recall is 6.1 ms, not sub-ms

The “sub-millisecond RAG” label in the trending entry is not a figure Wax claims. Wax’s own benchmark puts hybrid recall at 6.1 ms p95 — six times above 1 ms — and that number carries an unstated corpus-size condition that determines which search engine actually ran. The Metal HNSW engine the “hybrid” label implies only activates above 10,000 vectors; at Wax’s stated ingest rate of 85.9 docs/s, a fresh store doesn’t cross that threshold for roughly 116 seconds of continuous ingestion.

Reported figures and conditions

Wax’s README presents two comparison metrics across three systems. The ingest figure names the M3 Max explicitly; the recall and cold-open figures state no hardware beyond the implicit Apple Silicon requirement.

Metric	Wax (stated)	Comparison	Conditions stated by the artifact
Recall latency p95 — hybrid	6.1 ms	Cloud RAG: 150 ms+	Corpus size: not stated; hardware: not stated
Recall latency p95 — text only	—	SQLite FTS5: 12 ms	Same benchmark; same unstated conditions
Cold-open p95	9.2 ms	”Traditional”: 120 ms+	Baseline storage engine not defined
Ingest throughput	85.9 docs/s	—	M3 Max; “full hybrid indexing”
HNSW activation threshold	≥ 10,000 vectors	—	Exact flat (Accelerate) below; Metal HNSW above

The bar chart labels read “Wax (Hybrid) ██ 6.1ms” while the summary table writes “~6ms (p95)”; both refer to the same measurement. The rounding is the only difference.

Analysis

HNSW activation ramp from an empty store

The time to ingest enough documents to trigger the Metal HNSW path, at the stated throughput:

$$T_{\text{ramp}} = \frac{N_{\text{threshold}}}{R_{\text{ingest}}} = \frac{10{,}000 \text{ vectors}}{85.9 \text{ docs/s}} \approx 116.4 \text{ s}$$

Any benchmark completed before that point measured the exact flat Accelerate index, not HNSW. Wax states recall is “identical” across the boundary, which is plausible at small scale where an exact scan is available, but latency at 100k or 1M vectors is a separate question the published figures do not touch. The 6.1 ms figure is silent on which path ran.

Cold-open amortisation across a session

The cold-open p95 (9.2 ms) exceeds per-query recall p95 (6.1 ms). For a session of N queries, the amortised per-query cost is:

$$\bar{C}(N) = \frac{T_{\text{open}}}{N} + T_{\text{recall}} = \frac{9.2}{N} + 6.1 \;\text{ms}$$

For cold-open to fall to a fraction ε of per-query spend, the required session length is:

$$N_{\varepsilon} = \frac{T_{\text{open}}}{\varepsilon \cdot T_{\text{recall}}} = \frac{9.2}{\varepsilon \times 6.1}$$

Substituting ε = 0.10 (cold-open ≤ 10% of per-query budget):

$$N_{0.10} = \frac{9.2}{0.10 \times 6.1} = \frac{9.2}{0.61} \approx 15.1$$

A session needs at least 16 queries before cold-open is less than a tenth of each query’s effective cost. A single-query invocation pays 9.2 + 6.1 = 15.3 ms total, with cold-open accounting for 9.2 / 15.3 ≈ 60.1% of that. Wax’s MCP server holds the store open persistently and amortises normally across a multi-turn agent session; CLI invocations or short-lived Swift processes that open the store once per tool call do not.

The “shared file” versus the actual sharing primitive

Wax describes itself as a “shared single-file memory layer,” then states: “a second process on ~/.wax/memory.wax will lock.” The working multi-agent architecture routes all clients through one persistent HTTP server on 127.0.0.1:3000. The server process is what’s shared. The file is not. Wax is transparent about this constraint; the “single-file” framing describes storage layout, not concurrent-access semantics.

Context against a measured pipeline

The studio’s presspeech measurement put macOS transcription latency at ~100 ms (hotkey-release to text at cursor, no hardware qualifier). Wax’s 9.2 ms cold-open is roughly 11× faster than that single ASR step. In any pipeline that sequences transcription → memory lookup, the memory layer is not the latency bottleneck on the cold path. Whether the store is held open across turns or reopened per invocation is the operative integration question — a difference the amortisation equation above bounds at 10.9× in effective per-query cost for single-query sessions.

What the published figures cannot establish

The benchmark does not disclose which search path — flat Accelerate or Metal HNSW — produced the 6.1 ms number. No recall or latency data exists for corpora beyond the 10,000-vector threshold. P95 is reported without P50 or P99, leaving tail behavior at large index sizes uncharacterized. The 120 ms “traditional” cold-open baseline names no storage engine or schema, so the stated 13× speedup (120 ms vs. 9.2 ms) is unverifiable as written.

For Biquadia

Biquadia’s pipeline runs fully on Apple Silicon and already crosses the ANE/CPU boundary the studio has characterized. The natural Wax integration point is session-state memory: HRTF calibration results, spatial rendering preferences, DSP preset selections, and per-project decisions that should survive restarts. These map onto Wax’s EAV structured-knowledge layer, which the README describes as handling “durable facts and long-term reasoning.”

The operative constraint is the file-lock. Biquadia’s audio engine, any MCP-connected orchestration agent, and a UI process cannot all open memory.wax as an embedded library simultaneously. The correct pattern is the persistent MCP HTTP server — the memory layer running as a daemon that Biquadia subsystems reach over a socket, not a library they link. The cold-open cost (9.2 ms) fits well inside the 100 ms transcription budget measured for comparable on-device pipelines, so the daemon model carries no latency penalty for non-real-time recall paths such as parameter loading at session start. The EAV layer is also the right store for calibration data that is expensive to regenerate — provided the WAL recovery semantics on power-loss are confirmed before relying on it for that.

---

Method: this note was drafted by us.anthropic.claude-sonnet-4-6 from two sources — the published README of christopherkarani/Wax and this studio’s own published measurements, linked above. Before publication an automated gate re-checked every extracted claim against the source document (18 claim(s) and 11 quantity(ies) verified) and every claim-shaped number in the draft against that evidence (8 derived from it, 16 row(s) supplied from our own tables). The studio has not re-run christopherkarani/Wax’s benchmarks; figures attributed to it are its own.

FAQ

Does the 6.1 ms figure apply before or after the store warms up?

Wax measures cold-open (9.2 ms) and per-query recall (6.1 ms) as separate figures, so the 6.1 ms is presumably for an already-open store. Whether the first query after a cold open incurs both costs sequentially — 15.3 ms total — or whether some of the index load overlaps with the open phase is not stated. The amortisation equation above treats them as additive, which is the conservative bound.

At what corpus size does the performance story materially change?

The only disclosed transition is at 10,000 vectors, where the index engine switches from exact flat to HNSW. Wax reports identical recall across that boundary but provides no latency data above it. For session-state use in Biquadia — hundreds to low thousands of entries — the flat index is the operative path and the 6.1 ms figure is at least plausibly applicable, but the artifact provides nothing to confirm it holds at larger scales.

Is the WAL-based crash recovery sufficient for calibration data?

Wax states it uses a write-ahead log and dual headers with automatic recovery on next open. The README does not define recovery in terms of maximum data loss — last-committed transaction versus some earlier checkpoint — nor does it address partial-write detection on power-loss mid-frame. For DSP session state where losing the last preset change is acceptable, this is probably adequate; for HRTF calibration that takes minutes to regenerate, the recovery guarantee matters and is not specified.

Does the macOS 26 requirement affect production deployment?

The README attributes the macOS 26 requirement to the demo package's Foundation Models dependency, not to Wax's core engine. The MCP server and CLI build from source on macOS 15+ with Swift 6+, and the on-device MiniLM embedder auto-configures on iOS 18 / macOS 15. The macOS 26 requirement is scoped to the demo's Apple Intelligence integration path, not to the production memory layer or its Swift SDK.