WordPress core — ~619k lines — security-audited by an AI agent for ~26,000 tokens: that is the one study measured on real code. The other two are functional proofs on small synthetic corpora — they show the shape works, not how fast. Three engineering questions, answered end to end with published code and recorded output. The questions came from calltree.ai and daily.dev; neither is a customer. Every number traces to a walkthrough in the repo.
WordPress core is ~619k lines — ~26× a 200k-token context window. An agent indexed it as a queryable code graph and read only what queries surfaced. Yellow is the whole audit's token bill; blue is what it costs just to load the code once.
TOKEN ACCOUNTING, NOT A LATENCY BENCHMARK · SOURCES IN docs/case-studies/wordpress-security-audit →
"Of calls about wifi issues, how many are 2.4GHz vs 5GHz, and what are the key issues?" — asked by calltree.ai. Half retrieval, half analytics: normally two stores and an ETL. One XERJ POST /_search returns the slice, the breakdown, the metrics, and the evidence.
SPLIT STACK = OLAP + VECTOR STORE + ETL, OR TWO ROUND TRIPS IN ONE ENGINE · AGGS-BEARING kNN RUNS THE EXACT SCAN, NO SPEED CLAIM · BUCKETS COUNT THE RETRIEVED SLICE · k=80 IS THE REQUEST PARAMETER, NOT A MATCH COUNT · SOURCES IN docs/case-studies/calltree-analytics →
daily.dev's founder asked: can XERJ replicate automatically from Postgres? A logical-replication slot streams every INSERT, UPDATE, and DELETE into XERJ — no reindex jobs — and one hybrid query fuses BM25 + vector rankings server-side, replacing the tsvector + pgvector two-query app merge.
ARCHITECTURAL COUNT FROM THE RECORDED RUN · SOURCES IN docs/case-studies/daily-dev-postgres-cdc →
Every walkthrough reproduces from the repo. Want it run against your codebase, your conversations, or your Postgres? Leave a work email and we'll set it up with you.