Pippa's Memory Search Runs on the Mac Next Door

"Every message and every vault note is 1,024 numbers in a store on office, computed on server. The store's own names say which model made them and where."

The Index, Counted

Pippa's memory search is a vector index: each message she has exchanged and each note in her vault embedded into 1,024 floating-point numbers by the bge-m3 model, stored on office, queried by cosine distance and reranked. Read live and read-only on 2026-09-15, the store holds 15,697 message embeddings and 1,360 vault embeddings in two collections whose names carry their whole provenance — messages__omlx__bge-m3-mlx-fp16__1024: provider, model, precision, dimension. Two other collections, the bare messages and vault, hold zero rows. They are the Ollama-era names, and they reappear empty whenever a script runs outside the repository and asks for the default; the household dropped them once and they come back, which is the kind of fact only a read-only count reveals.

Why It Moved

Retrieval ran on Ollama first. The household's account of the move, given at this quest's plan gate: an Ollama change altered how the embedding model behaved, retrieval had to follow the model, and the embedding provider moved to the MLX server on the hub in June 2026, with reranking following; the MLX server has run without incident since, and its SSD caching makes parts of it faster than Ollama. This quest checked the code: the embedding service supports both providers, the reranker supports only the MLX one, and the collection name is built from provider, model and dimension precisely so that a store embedded by one runtime is never queried by another's numbers. That is the Ollama lesson's warning made durable: a runtime that moves under you can move the meaning of a vector, and an index that does not record its runtime cannot notice.

Which Half of the Caching Claim Is Exercised

The hub lesson's counters are the evidence for the last half of the story. The MLX server's advantage, as the household states it, is MLX-side SSD caching — reloading a repeated prefix's KV blocks from disk instead of recomputing. That is a generation feature: it pays when a long system prompt or a shared document is prefilled again and again before decoding. The hub's counters show 0 completion tokens across 143,626 requests and an SSD cache directory of zero bytes: the family's load on it is pure embedding and reranking, which have no prefix to reuse. So both halves are true and only one is in use — the server has run for months without a problem on the workload the family gives it, and the caching that would make it faster than the alternative belongs to a workload it does not yet carry. The memory search is the physics track's prefill stage as a household service: compute on the hub's 80 cores, 1,024 numbers back over the wire, a store on the control plane that names its own maker.

Code

search_index.py — the memory store counted, read-only, with its provenance in the names·python

#!/usr/bin/env python3
"""Pippa's memory search, counted: the vector store on the control plane, read-only.
Collection names carry provider, model and dimension, so the index states its own
provenance. Path from the environment; opened read-only with query_only."""
import os, sqlite3
db = os.environ["PIPPA_CHROMA"]                                     # the store's sqlite file
con = sqlite3.connect(f"file:{db}?mode=ro", uri=True)
con.execute("PRAGMA query_only=ON")
for name, n in con.execute("select c.name, count(e.id) from collections c left join segments s on s.collection=c.id "
                           "left join embeddings e on e.segment_id=s.id group by c.name"):
    print(f"{name:44} {n:7d}")
# office, 2026-09-15:
# messages                                           0     <- the Ollama-era bare name, recreated empty by a script run outside the repo
# messages__omlx__bge-m3-mlx-fp16__1024          15697     <- provider omlx, model bge-m3 fp16, 1024 dimensions
# vault                                              0
# vault__omlx__bge-m3-mlx-fp16__1024              1360

Exercise

Find the vector store behind any search you rely on, open it read-only, and count its collections. Write on your card the model, precision and dimension that made each — from the names if they are there, from the code if they are not — and whether the runtime that computes queries today is the one that computed the stored vectors.

Hint

If the names carry no provenance, look at the dimension: 1,024 is bge-m3's, other models differ, and a mismatch is a search that returns nonsense with confidence. If the store has empty collections with bare names, something is calling a default.