ARCHIVE: LiteLLM /v1/memory - KV store only (not a KB)

Last updated 05/11/2026 · litellm, memory, alexandria, architecture

LiteLLM (v1.83.10+, needs Postgres) exposes /v1/memory as a plain key-value CRUD table (key, value string, JSON metadata, pagination, key_prefix filter, user/team scoping via the API key’s user_id, created_by/updated_by audit). Verified live on ai.handtrixxx.com 2026-10-25 (create/get/list/delete roundtrip, test entry removed afterwards).

What it is NOT: no semantic/vector search, no BM25, no automatic extraction of facts from conversations, no automatic injection into prompts (docs show you must inject the value into the system prompt yourself), no skills, no markdown notes, no versioning beyond a metadata blob, no archive/importance concept. It only works for requests that go through the LiteLLM proxy, and entries are scoped per key identity (master key lands everything in default_user_id).

Verdict (2026-10-25): for the homelab’s memory+knowledge goals it adds no recall or a second source of truth; kb + mcp-memory (Alexandria) remain the store. (LibreChat itself was removed 2026-10-25, so this scratchpad use case no longer applies.) The bake-off (memory-system) already measured the real standard-software field (mcp-memory-service, Mnemosyne, YantrikDB, cognee, nocturne, QMD): none beat the thin custom MCP server on hit@1 + schema tokens + RAM; Alexandria is only ~5.7 MB binary / ~17 MiB RSS with 6 tools / ~669 schema tokens. Not evaluated: mem0 (adds an LLM extraction step + Qdrant - heavier, still no skills/git KB).

Source: Wiki.js