Untagged cells are embedded with Nomic but served as MiniLM — semantic search fails on every fresh 0.52 install

[alecmarcus]

Summary

On 0.52.0 a freshly created cell carries no vec:model tag. The ingest path embeds untagged cells with the bundled singleton — now Nomic, truncated to STORE_DIM=128 — while the serving path interprets untagged as MiniLM and fail-closes because the pre-0.52 MiniLM model is no longer installed.

Net effect: flex init runs to completion, prints "Flex is ready.", and every semantic query against the resulting cell raises.

Reproduction

curl -sSL https://getflex.dev/install.sh | bash -s -- claude-code
flex core search --cell claude_code "SELECT v.id, v.score FROM vec_ops('similar:anything') v LIMIT 3"

RuntimeError: legacy minilm cell requires its retained pre-0.52 model; the model is not installed
  flex/engine.py:204 in _query_embedder_for

Also emitted at MCP startup, into ~/.flex/logs/mcp.err where it is easy to miss:

[flex-mcp]   claude_code: legacy minilm cell requires its retained pre-0.52 model; the model is not installed
[flex-mcp] Background warmup finished with 1 error(s) (1 cached)

Cause

vec:model is written in exactly one place in the package — retrieve/embeddings.py:18 (set_active_model). Nothing on the init path calls it, so new cells are untagged.

Write — modules/claude_code/compile/worker.py:188:

tag = _cell_tag(conn)
if tag in (None, 'minilm'):
    return encode(texts)          # legacy fast path, bypasses _resolve_ingest_target

onnx/embed.py::encode() loads models/nomic-v1.5-fp32/model.onnx at matryoshka_dim=STORE_DIM (128). There is no MiniLM path left in that module.

Read — engine.py:199:

elif tag not in (None, 'minilm'):
    raise ValueError(...)
# Only 'minilm' or absent use the retained pre-0.52 space.
if not _LEGACY_MODEL_PATH.exists():
    raise RuntimeError("legacy minilm cell requires its retained pre-0.52 model")

So untagged means "whatever singleton ships today" to the writer and "MiniLM specifically" to the reader. Those agreed until 0.52 swapped the bundled model and dropped MiniLM from the installer; only the reader was updated to fail closed.

Impact

My cell holds 126,893 Nomic@128 vectors that nothing in the package will read. FTS/keyword retrieval works; vec_ops does not. The installer reports success, and the MCP server is registered and serving.

Worth noting the fail-closed check is doing exactly the right thing here — both spaces are 128 wide, so if MiniLM were still installed this would be silent garbage ranking rather than an exception.

Workaround

flex reembed <cell> re-encodes from content at native 768 and stamps vec:model + vec:serve_dim=256, after which ingest and serving agree.

Hand-stamping vec:model=nomic-v1.5-fp32 also makes queries resolve to Nomic@128 and match the stored vectors, but then _encode_for_cell starts routing new chunks through _resolve_ingest_target at native 768 — producing precisely the mixed-width cell its own docstring warns about.

Suggestion

Have init stamp the tag it actually embedded with, or route ingest through _resolve_ingest_target unconditionally so the "never diverges from serving" guarantee in its docstring holds for untagged cells too.

Environment

getflex 0.52.0 · macOS (Darwin 25.5.0, arm64) · Python 3.14.3 · module claude-code

[alecmarcus]

Correction to the Impact section above, plus a second failure mode found while testing through the MCP server.

1. Keyword/FTS is also dead, not just vec_ops.

I originally wrote "FTS/keyword retrieval works; vec_ops does not." That is wrong. _open_cell_for_search (cli.py:1368) calls _engine.register_vec_udf(db, state) at open time, before the query is examined, so the embedder resolves and raises for every query against the cell:

flex_search(cell="claude_code",
            query="SELECT k.id FROM keyword('ModifyCeiling','SELECT id FROM chunks') k LIMIT 5")
→ legacy minilm cell requires its retained pre-0.52 model; the model is not installed

So an affected cell is entirely unqueryable through both the CLI and MCP — not degraded to keyword-only. That raises the severity: the install produces an index that cannot be read at all.

2. Self-contradictory "Unknown cell" error.

Separately, my claude_code cell ended up with active = 0 in registry.db, which makes mcp_server.py:266 (if not metadata or not metadata.get("active", 1)) reject it — while the error's own available list, built without that filter, still contains it:

{"error": "Unknown cell: claude_code", "available": ["claude_code", "instructions"]}

An error that names the cell as unavailable and available in the same breath is hard to act on. Worth either filtering available through the same predicate or saying "cell is inactive — flex warm <name>".

I could not determine what set active = 0; registry.set_active is the only writer I could find, and its callers are flex warm (which I had not run) and reembed, whose --dry-run path returns before _freeze_active_state. The registry timestamp puts the change ~7 minutes after flex init completed. Flagging it as unexplained rather than claiming a cause.

Note for anyone hitting both at once: reembed restores the prior active state on exit, so re-activating with flex warm <cell> before reembedding avoids having it restored to inactive afterward.