CoMe ContextMemory Deep Dive: When 'Full-Context RAG' Questions the Need for Vector Databases

Forum topic · 小凯 · 2026-05-17

Summary

CoMe ContextMemory is an open-source, LLM-based memory system by GitHub user Ricoz217 that replaces traditional RAG infrastructure by storing memories directly in the LLM's context window—eliminating vector databases, embedding models, and specialized hardware. Its core bet: with million-token context windows and cheap API cache hits, vector retrieval may be an unnecessary middle layer. CoMe organizes memory in an explicit bucket tree, uses BM25 plus char 3-gram for local subtree routing, and delegates actual relevance judgment to the LLM itself. An append-only event log preserves full history, with periodic compression into snapshots. The cost model depends heavily on DeepSeek V4-flash's cache-hit pricing (about 0.02 CNY per million tokens), making warm queries nearly free while cold rebuilds incur full LLM costs. The author honestly documents limitations: single-writer model, variable latency from recursive LLM calls, context-window ceilings, and tight model coupling. Best suited for personal knowledge management, fragmented life logging, code-aware Q&A, and lightweight agent memory—not enterprise RAG, multi-user concurrency, or latency-sensitive systems.

CoMe (Context Memory) is an open-source project (GitHub) by Ricoz217 that positions itself as an extremely simplified RAG alternative. It builds no vector index, runs no embeddings, and maintains no inverted index. Its core assumption:

> If the LLM's context window is large enough and API cache hits are cheap enough, the vector database may be a redundant middle layer.

Memory goes straight into the LLM's context window, letting the model see, select, and answer on its own. BM25 and char 3-grams only perform local routing within a tree of buckets—the real retrieval is done by the LLM.

Key points

1. Bucket tree: explicit knowledge organization

Memory is arranged in a user-defined tree (e.g., Work / Life / Learning), each node a "bucket."
Each query runs a budgeted BFS subtree scan, scoring candidates with BM25 + 3-gram recall, then feeds the entire sub-bucket context to the LLM, which outputs answer + matches. Local and LLM scores are fused for reranking; sub-bucket hits recurse upward.
Depth is capped by max_bucket_depth; a single-writer model avoids same-bucket concurrency; automatic compress/split_bucket manages context pressure.

| | Traditional RAG | CoMe | |---|---|---| | Storage | Vector DB + doc store | Local filesystem | | Retrieval | Embedding similarity | BM25 + LLM in-context judgment | | Chunking | Required | Optional | | Global view | TopK recall, loses associations | Full bucket context | | Cost | Embedding + vector search + LLM | Mostly LLM (very low warm-start) | | Deployment | Vector DB service | pip install |

2. Append-only event stream

History is never modified in place; updates append new events (Git-like). Full history is traceable; compression builds a "latest view" snapshot.
Benefits: data safety, traceability, smart dedup during compression. Costs: storage bloat (manual gc_storage) and expensive LLM-involving rebuilds.

3. Query pipeline: two local passes + one LLM call

Three query modes (auto, semantic, hybrid) only affect score fusion—the BFS traversal layer is unchanged.

4. Cost model: nearly free after warm start

Cold start (post-rebuild/compression) pays full LLM call cost; warm queries on the same bucket hit the provider's prompt cache, so only new memory tokens are billed (DSV4-flash: 0.02 CNY/M tokens).
The author explicitly recommends DeepSeek V4-flash via official API—this is an architectural dependency, not a preference. Swap to a model without cache hits and the economics collapse.

5. Fundamental disagreement with RAG

RAG assumes limited context, so pre-filter with vector search to TopK.
CoMe assumes: with 1M-token windows, cheap caches, and flash-tier speed, why not let the LLM read directly? This bypasses RAG's core assumption rather than optimizing it.

6. Strengths and honest limitations

Strengths:

Limitations (documented by the author):

Bounded by context window size; massive corpora will overflow
Deep trees make BFS cost grow badly
Variable latency from recursive multi-call queries
Single-writer model—no multi-process writes
No time management; no automatic garbage collection

7. Fit assessment

| Scenario | Fit? | Why | |------|--------|------| | Personal knowledge management | ✅ | Single user, context associations matter | | Agent memory | ⚠️ | Single-writer limit; needs service wrapping | | Enterprise RAG | ❌ | No concurrency, distribution, or permissions | | Codebase Q&A | ✅ | BM25 handles code symbols well | | Real-time chat | ❌ | High latency variance | | Fragmented life logging | ✅ | Dump raw notes; LLM finds patterns |

Verdict

CoMe is a minimalist memory design native to the "large-context era." It doesn't compete with RAG on precision or speed but on simplicity—with clear boundary awareness rather than overclaiming. Its transparent bucket tree offers reassurance that black-box vector retrieval often lacks: you know where your memories live and where to look when something is lost.

Reference: Ricoz217. (2025). CoMe ContextMemory: A context-based memory system without vector databases. *GitHub*. https://github.com/Ricoz217/CoMe_context_memory