Context
Surfaced during the 2026-06-19 Agent-OS memory-degradation investigation (operator-flagged: "multiple qwen instances need an investigation too"). The local lms server (headless, 127.0.0.1:1234 — distinct from the LM Studio desktop app) has four loaded instances of the same embedding model: text-embedding-qwen3-embedding-8b + :2 + :3 + :4, ~4.68 GB each (~14 GB, three redundant). This is the embedding model add_memory's WAL-drain uses.
A background sub-agent was delegated to investigate but died on a host-process exit before completing — hence this durable ticket.
Release classification: boardless (local Agent-OS infra hygiene).
The Problem
Three Neo clones run their own MCP servers (/Users/Shared/{claude,github,antigravity}/neomjs/neo), all pointing at the one lms server. Hypothesis: each clone's MC JIT-loads its own embedding instance (LM Studio auto-instances with the :N suffix when a model is requested while another instance is busy, OR repeated loads that never unload). ~14 GB of redundant model memory + possible routing ambiguity (which instance serves a given request).
Investigate (read-only first)
lms ps — current instances + state (busy/idle).- How Neo requests the embedding model —
ai/services/memory-core/TextEmbeddingService.mjs, the openAiCompatible /v1/embeddings POST, and any model-load/JIT behavior; does each MC process / clone trigger a fresh load?
- Whether the
:N instances are busy-driven parallel replicas vs orphaned never-unloaded loads (historical debt).
The Fix (candidate)
Consolidate to a single embedding instance — e.g., an LM Studio max-loaded-instances cap / TTL, or have Neo reuse one named instance across clones. Confirm the chosen shape doesn't regress concurrency.
Out of Scope
- The WAL embed-drain gap (non-github clones' WALs not drained) — separate finding, separate fix.
- The gemma-4-31b desktop-app load — a red herring (operator ejected it; unrelated to
lms server).
Origin Session ID
045a6048-1e1d-44c1-9738-7f09b62cc998
Context
Surfaced during the 2026-06-19 Agent-OS memory-degradation investigation (operator-flagged: "multiple qwen instances need an investigation too"). The local
lms server(headless,127.0.0.1:1234— distinct from the LM Studio desktop app) has four loaded instances of the same embedding model:text-embedding-qwen3-embedding-8b+:2+:3+:4, ~4.68 GB each (~14 GB, three redundant). This is the embedding modeladd_memory's WAL-drain uses.A background sub-agent was delegated to investigate but died on a host-process exit before completing — hence this durable ticket.
Release classification: boardless (local Agent-OS infra hygiene).
The Problem
Three Neo clones run their own MCP servers (
/Users/Shared/{claude,github,antigravity}/neomjs/neo), all pointing at the onelms server. Hypothesis: each clone's MC JIT-loads its own embedding instance (LM Studio auto-instances with the:Nsuffix when a model is requested while another instance is busy, OR repeated loads that never unload). ~14 GB of redundant model memory + possible routing ambiguity (which instance serves a given request).Investigate (read-only first)
lms ps— current instances + state (busy/idle).ai/services/memory-core/TextEmbeddingService.mjs, the openAiCompatible/v1/embeddingsPOST, and any model-load/JIT behavior; does each MC process / clone trigger a fresh load?:Ninstances are busy-driven parallel replicas vs orphaned never-unloaded loads (historical debt).The Fix (candidate)
Consolidate to a single embedding instance — e.g., an LM Studio max-loaded-instances cap / TTL, or have Neo reuse one named instance across clones. Confirm the chosen shape doesn't regress concurrency.
Out of Scope
lms server).Origin Session ID
045a6048-1e1d-44c1-9738-7f09b62cc998