EverOS Files

A server that stays healthy for days, not hours. Three faults in this release compounded on exactly the deployments that ran longest: a long-lived index leaked file descriptors until searches took seconds, interactive searches queued behind the cascade's background embedding, and a memory root holding more than one project had each project's index rows overwrite the other's. All three are fixed, and a LanceDB root that the last fault already damaged repairs itself on the first start after upgrading.

Changed

• [embedding].max_concurrent defaults to 10 instead of 5. The EmbeddingSettings class default (50) is aligned to the same value; the shipped default.toml always overrode it, so the effective default moves from 5 to 10. (#486)

• Milvus collections must be rebuilt once after upgrading. They gain the __pk primary-key column; the server refuses to start on an old collection and names everos cascade rebuild, which recreates them from markdown.

• Response ids are unique within (app_id, project_id), not globally; the shape of id is unchanged.

• The cascade optimizes a LanceDB table at most once a minute, not once every ten seconds. Each optimize pass leaves an _indices/<uuid>/ directory behind until cleanup reclaims it, so the old 10 s floor set the ceiling on how many could pile up: about 126k directories a day and ~1.8M at the retention horizon. The 60 s default costs a sixth of that (~21k a day, ~300k at the horizon, roughly 1.2 GB) and keeps a full index sweep inside its 60 s deadline. The interval is a built-in floor on how often a table may be optimized, not a setting; a write-heavy deployment sees an index that trails its markdown by up to a minute longer than before.

Fixed

• A long-running server no longer leaks file descriptors on LanceDB index readers. Every optimize() mints a new index version whose reader is kept in a session cache, and that reader holds the descriptors of its _indices/<uuid>/ files. Lance keys those cache entries by dataset version and never evicts them when cleanup deletes the files underneath (lance-format/lance#7718), so the count grew for the life of the process: a 65-minute soak went from 74 to 558 index descriptors with no plateau, and a deployment on a 1024-descriptor limit exhausts it in hours. EverOS capped only one of the session's two caches and left the metadata cache unbounded, which is the one that decides whether the count converges. Both are now capped ([lancedb].metadata_cache_size_bytes, default 1 MB): the same soak holds between 6 and 82 descriptors, falling as often as it rises. Reported upstream as lance-format/lance#9934.

• An interactive search no longer queues behind the cascade's embedding work. Query embeddings and background write embeddings shared one process-wide semaphore, so a burst of writes put the query a user was waiting on at the back of the queue. Under three concurrent writers, vector search p50 measured 46 s and p95 112 s, while the keyword leg — which needs no embedding — answered in 0.35 s. Queries now draw on their own budget ([embedding].query_max_concurrent, default 4): vector p50 drops to 0.60 s and p95 to 3.70 s under the identical load. Total in-flight requests to the endpoint become max_concurrent + query_max_concurrent rather than a silently shared bound. (#473)

• The same owner's memories in two projects no longer overwrite each other in the derived index. Index rows were merged on id alone, and id is unique only within one (app_id, project_id): a user's episodes, atomic facts, agent cases, foresights, skills and profile written under a second project replaced the first project's rows (markdown was never affected). Every table now declares PRIMARY_KEY = ("app_id", "project_id", "id"); LanceDB merges on it and Milvus keys its collections on the composed __pk column. Profile search and get, the handlers' change detection and the vector backfill address rows by the full key; the backfill also keeps each row's own vector within a batch, and reflection deprecates atomic facts only inside the project it merged.

• A multi-project LanceDB root indexed before this release gets its overwritten rows back by itself. The first full pass over the root after upgrading (server start, or everos cascade sync) re-reconciles every indexed markdown file against the index once and records that in .index/.index_reconcile_version. Entries whose rows are present and unchanged are skipped by digest, so a healthy root pays one read pass and no embedding; only the rows that were lost are re-embedded. everos cascade sync --force-all runs the same pass on demand. Two roots need that command instead: a server started with EVEROS_DISABLE_CASCADE=1 never runs the pass (stop it and run everos cascade sync --force-all once), and a multi-project root where reflection ran before this release needs everos cascade rebuild once, because the pass does not clear the deprecated_by stamps one project's reflection left on another project's rows.

• POST /cascade/quiesce freezes a complete index. Its drain stopped at the worker's per-drain bound, and inside a server it could also stop while the background worker still held the last batch, which the stop that follows then orphaned in processing; the ledger an upgrade re-queues made both routine. The drain now runs until the ledger holds nothing pending, waiting for the worker's in-flight batch, and everos cascade sync / rebuild use the same loop.

• A cascade pass embeds a file's changed entries in one batched request, not one request per entry. The four daily-log handlers (episode, atomic fact, foresight, agent case) each called the embedding endpoint once per entry, so a turn that wrote ~20 atomic facts queued ~20 single-input requests on the process-wide embedding semaphore, and the next search's query embedding waited behind all of them: about five times the endpoint's latency at the previous default max_concurrent = 5. The handlers now send every text of a file through embed_batch, which [embedding].batch_size splits into requests (23 entries become 3 requests at the default 10), so after a single turn's writes the query embedding waits for one request; a large backlog still queues ahead of it (#473). (#486)

• Changing a knowledge document's category keeps it inside knowledge/. PATCH /knowledge/documents/{doc_id} with category_id set to .. moved the document's directory up into the project directory, where the markdown scan no longer finds it. The category now goes through the same rule as document creation, so . and .. fall back to Others, and the move is refused if its target would leave knowledge/. A document an earlier move left outside is moved back on its next category change. Reported by White0xdi3.

Upgrade

:::bash
pip install --upgrade everos   # or: uv sync

pip install --upgrade everos is enough for most roots: the first full pass after the upgrade (server start, or everos cascade sync) re-reconciles every indexed markdown file against the index once, re-embeds only the rows that were lost, and records that it ran in .index/.index_reconcile_version. A healthy root pays one read pass and no embedding.

Three roots need a command instead:

• A root where reflection already ran across projects — everos cascade rebuild once. The automatic pass does not clear the deprecated_by stamps one project's reflection left on another project's rows.
• A server started with EVEROS_DISABLE_CASCADE=1 — it never runs the pass. Stop it and run everos cascade sync --force-all once.
• A Milvus derived index — everos cascade rebuild once. Collections gain the __pk primary-key column and the server refuses to start on an old collection.

Full changelog: v1.4.1...v1.4.2