v3.5 introduced bounded-storage controls, multi-agent coordination work, and cold-tier experiments. Current release guarantees are limited to behavior covered by the release test evidence.
V3 includes lifecycle, storage, coordination, and audit controls. A production claim additionally requires release-linked quality, latency, recovery, concurrency, and resource evidence.
SQLite remains the canonical source of truth. V3.7 includes CozoDB and LanceDB scale-engine paths, each protected by prepare, verify, promote, and rollback controls rather than an automatic backend switch.
SLM Mesh exposes peer, lock, event, inbox, and state primitives. Publish a concurrency number only after the frozen release passes contention, recovery, and consistency tests.
Cold-tier and compression behavior depend on the configured path and content. Measure fidelity, reduction, retrieval quality, and latency before enabling it in production.
Core memory operations can run locally and produce structured evidence. Optional providers, connectors, backups, proxies, and downloads may use the network.
Configured callers can coordinate work and target one explicitly selected SLM service. Mesh does not by itself replicate memories or turn multiple local stores into one distributed database.
SLM Mesh is a local coordination layer with lock, event, inbox, peer, and shared-state tools. It is not evidence of distributed memory replication or universal consistency.
Selected endpoint · local locks · events · inbox
The historical table below is retained as design context, not a current V3.7 release claim. Re-run the release benchmark harness on representative data before publishing numbers.
SLM adapts to your workflow — solo developer, multi-agent pipeline, or team shared memory server.
Single-client deployment using the local core. Run setup explicitly; Optimize cache and compression remain separately configured.
Multiple local agents using SLM Mesh coordination primitives. Validate contention, crash recovery, and state consistency for the target process topology.
SLM exposed as an MCP server. Tool availability depends on the selected profile and release; client compatibility requires a successful end-to-end contract, not only protocol support.
Do not copy invented scale knobs from marketing pages. Inspect the installed configuration schema, set only supported fields, and verify the resulting runtime behavior.
# Inspect release-current commands and configuration slm status --json slm doctor slm cache status slm compress status # Back up the configured data root before changing modes, # lifecycle policy, cache, compression, or mesh settings. # Then run representative quality, latency, recovery, # concurrency, disk, and memory tests.
Back up first, upgrade through the original installer, and verify migration before serving client traffic.
Use the same isolated installer that owns the current executable. Do not mutate a system Python installation.
Start from a copied data root, run the supported migration path, and verify remember, recall, update, forget, restart, and recovery.
Enable optional cache, compression, backends, providers, or mesh features only after their target-workload tests pass.
Install the release, set explicit storage limits, and benchmark your representative corpus before production use.