Direct answer: AllSource's published 11.9μs p99 result measures an indexed read from Core's concurrent in-memory map on the benchmark hardware. It does not measure an HTTP request, a historical replay, embedding generation, HNSW search, graph traversal, hybrid ranking, or a complete AllSource Prime memory lookup.
That distinction matters. Earlier versions of this page described the number as “agent memory.” That was too broad. This page now states the benchmark boundary explicitly.
What path produced 11.9μs p99?
indexed Core read → concurrent in-memory map → event or projection resultCore persists accepted events through a write-ahead log and Parquet storage. The indexed hot path reads from an in-memory map with sharded concurrency. WAL and Parquet provide recovery and long-term storage; Parquet is not what makes the hot read take 11.9μs.
What does the benchmark exclude?
The reference result excludes:
- network and TLS latency;
- gateway authentication and quota checks;
- JSON encoding and client parsing;
- replaying a long event stream to reconstruct historical state;
- generating or loading embeddings;
- HNSW vector search;
- graph expansion and temporal scoring;
- Prime's hybrid ranking and final response assembly.
Calling 11.9μs “hybrid recall latency” or “agent-memory latency” is therefore incorrect.
How fast is AllSource Prime recall?
There is no single universal Prime recall number. Latency depends on corpus size, embedding model, vector dimension, graph fan-out, requested result count, cache state, hardware, and whether Prime is local or reaches Core over a network.
Measure the exact path your agent uses. Record at least p50, p95, and p99 for:
- direct Core indexed reads;
- vector-only search;
- graph-only traversal;
- hybrid Prime recall;
- full client-to-response requests.
Those numbers answer different questions and should not be collapsed into one headline.
What does 469K events/sec measure?
AllSource's other common headline, 469K events/sec, is a published Core batch-ingest reference. It is not a synchronous, durable, single-event HTTP rate. Fsync policy, batch size, hardware, payload size, indexing, and network work all change application throughput.
See how to reproduce the 469K benchmark for harness details and caveats.
Which number should buyers use?
Use benchmark numbers only when their path matches your workload:
| Question | Measurement to use |
|---|---|
| How quickly can Core fetch an indexed item already in memory? | Core indexed-read benchmark |
| How quickly can Prime find semantically related memories? | Vector or hybrid-recall benchmark |
| How quickly can an agent retrieve memory in production? | End-to-end client, gateway, Core, and Prime measurement |
| How many events can one request batch accept? | Batch-ingest benchmark |
| What can survive an acknowledged write? | Durability-mode and failure-recovery test |
AllSource publishes the 11.9μs result as a Core indexed-read reference. Test Prime and hosted paths with your data before making a production decision.
