TeleMem: a Mem0-compatible memory layer that adds per-character profiles and video QA
TeleMem is a high-performance drop-in replacement for Mem0, featuring semantic deduplication, long-term dialogue memory, and multimodal video reasoning.
At a glance
- What is it?
- TeleMem is an Apache-2.0 Python library that presents the same add() and search() surface as Mem0 while adding isolated per-character memory, a video to frames to captions to vector DB pipeline, and a local Qwen plus FAISS default. The compatibility claim is the part worth checking first, because a drop-in import only holds as far as the argument and return shapes actually match.
- Who is it for?
- TeleMem is worth trying if you already run Mem0 in Python and want per-character memory isolation or video memory without changing your call sites, since the README states that add() and search() accept the same arguments and return the same {"results": [...]} shapes. It is the wrong choice if you depend on Mem0's managed cloud service or on memory features the README does not list, because compatibility is asserted for the API surface, not for every backend behaviour.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem TeleMem targets: memory that survives a conversation and a character boundary
Most agent stacks treat memory as a single flat store keyed by user. That works until you need two personas in the same session, or until the thing you want to remember is a video rather than a sentence. TeleMem's README frames the project around multi-turn dialogues, character modeling, long-term information storage, and semantic retrieval, and it claims to be the only open-source memory layer that automatically builds isolated, per-character memory profiles. The stated audience is role-play, companion AI, NPCs, and multi-persona assistants, plus agents that need to store, retrieve, and reason over video content. The project's own summary of its goal is to use an agent's hindsight to improve its foresight. If your memory requirement is a single user profile with text facts, this is more machinery than the problem needs.
How the memory layer is put together: a Mem0-shaped API over Qwen and FAISS
The architecture visible in the README is a Python library that wraps an embedding model and a vector index, with the default configuration running end-to-end on your own hardware using Qwen and FAISS. No cloud service is required in that default path. On top of the index sits a context-aware enhancement mechanism, which the README names as the source of the accuracy and speed claims, and a semantic deduplication step that is listed in the project description. The README also mentions efficient buffering and batch writing as the explanation for millisecond-level semantic retrieval, though it does not publish the buffer size or flush policy, so the write path is the thinnest part of the public description. The compatibility layer is the notable design choice: the README states that add() and search() accept the same arguments and return the same {"results": [...]} shapes as Mem0, so existing code keeps working. That is an API contract, not a storage contract, and the distinction matters if you rely on Mem0 internals.
Character memory is the differentiator, and the release notes show it is still being corrected
Per-character memory profiles are the feature that separates TeleMem from a generic vector store with a metadata filter. The README describes them as isolated and built automatically, which implies the extraction step decides which character a fact belongs to rather than requiring you to pass a character id. That inference is the risky part of the design: automatic attribution can put a fact in the wrong profile, and there is no documented review step in the material. The v1.8.0 release notes describe a character-memory extraction fix and state that infer=False, prompt, and memory_type are now fully honored, which tells you those parameters were previously not fully honored. Anyone evaluating the character feature should read the v1.8.0 notes in full and test extraction on their own transcripts rather than assuming the behaviour from the marketing line.
Video memory: frames, captions, vectors, then ReAct-style question answering
The multimodal side is described as a complete pipeline of video frame extraction, caption generation, and vector database construction, after which the README states that agents can store, retrieve, and reason over video content like text memories. Question answering over that content is described as ReAct-style and multi-step, meaning the agent issues more than one retrieval or reasoning step rather than answering from a single nearest-neighbour lookup. Frame extraction and caption generation both cost compute and, depending on the captioning model you point at, API calls, so the video path is materially more expensive than text ingestion. The README does not state a frame sampling policy, a caption model default, or how caption text and any visual embeddings are combined at query time. Treat the video feature as the least specified part of the project until you read the pipeline code.
Getting it running: pip, a one-line import swap, or uvx for the MCP server
Installation is a standard PyPI package: pip install telemem. The drop-in path is a single import change, import telemem as mem0, after which the README states your existing Mem0 calls continue to work. For agent hosts that speak the Model Context Protocol, the project publishes an MCP server that can be started with no install using uvx telemem, and the v1.9.0 release notes say the server migrated to the official MCP Python SDK v2 against spec 2026-07-28, with all 8 tools declaring titles, behavior annotations, and structured output while remaining compatible with older MCP clients. The v1.10.0 release notes add opt-in DeepSeek Harness support through a Cordis/MCP patch that starts TeleMem with uvx, registers all 8 memory tools under the mcp__telemem__* prefix, and forwards provider configuration. The v1.6.0 notes list Ollama, DeepSeek, and Kimi configs plus LangChain and LlamaIndex examples, so provider selection is configuration rather than code. The README does not print the config file schema in the excerpt available here; check the documentation site for the exact keys before wiring it into a deployment.
Where TeleMem is the wrong tool, and what the compatibility claim does not cover
The drop-in guarantee is scoped to add() and search() argument and return shapes. It does not promise that stored memories, index formats, or configuration files are interchangeable with Mem0, so a migration is a re-ingestion, not a file copy. If you depend on Mem0's hosted service, TeleMem's local-by-default design is a different operating model: you now own the embedding model, the FAISS index, and the machine they run on. The README's accuracy figure of 86.33% on the ZH-4O Chinese multi-character long-dialogue benchmark, described as 19% higher than Mem0, is a single benchmark on a Chinese multi-character dialogue task; it is not evidence about English single-user retrieval, and the README does not report results for that case. The speed and token-cost claims are stated without published methodology in the material available here. Telemetry is disabled by default as of v1.8.0, which is a point in the project's favour for anyone with data-residency constraints, but you should confirm that setting in your own configuration rather than assume it.
The honest alternative: Mem0 itself, and why you would stay
The obvious alternative is Mem0, which TeleMem explicitly targets for compatibility. The difference in approach is that Mem0 is the reference implementation with a hosted offering and a broader set of integrations, while TeleMem reimplements the same call surface around a local Qwen plus FAISS stack and adds two things Mem0's README does not claim: automatic per-character memory isolation and a video understanding pipeline with ReAct-style question answering. If your workload is text-only, single-persona, and you want a managed backend, staying on Mem0 avoids the migration and the operational work of running your own embedding model. If you need character isolation or video memory, or you cannot send conversation data to a hosted service, TeleMem is the one that addresses those constraints directly. A plain vector database with a metadata filter is the third option, and it costs you the extraction and deduplication logic that both libraries provide.
Maintenance, licence, and what to check before you commit
TeleMem is licensed under Apache-2.0, which permits commercial use and modification and includes an explicit patent grant, with the usual requirement to retain notices and state changes. It is not legal advice; read the LICENSE file if you are redistributing. The release cadence visible in the repository is roughly monthly across 2026, with v1.10.0 in August 2026 and the last push in September 2026, and the v1.8.0 notes mention an offline contract test suite, which is the kind of artifact that makes upgrades cheaper to validate. The maintenance cost you take on is the local stack: the embedding model, the FAISS index, and the captioning model for video all need to be sized and kept current by you. Upgrading between minor versions has already changed extraction behaviour once, in v1.8.0, so pin the version and re-run your own retrieval checks after each bump rather than trusting the compatibility statement alone.
Editorial conclusion
TeleMem is worth trying if you already run Mem0 in Python and want per-character memory isolation or video memory without changing your call sites, since the README states that add() and search() accept the same arguments and return the same {"results": [...]} shapes. It is the wrong choice if you depend on Mem0's managed cloud service or on memory features the README does not list, because compatibility is asserted for the API surface, not for every backend behaviour. Before adopting, verify three things against your own data: that your existing Mem0 calls run unmodified under import telemem as mem0, that the local Qwen plus FAISS default gives you the retrieval quality you need on your language, and that the character-memory extraction behaves as expected on your transcripts, since the v1.8.0 release notes describe a character-memory extraction fix rather than a first implementation.
Community notes