Saket Aryan
df70d7833f
Six defects in 0.3.x plugin telemetry. Defects 1, 2 and 6 were not three bugs: they were one spool protocol getting three properties wrong. Identity was decided by the wrong process. `harness` was stamped in record(), correctly, but `source` was read from a module global in flush() — so whichever process drained the spool named every event in it. Two processes never call init(): mcp_server.py, and the detached `python3 telemetry.py` sender that spawn_flush() starts. record() now stamps source beside harness, and the build generates core/_harness_id.py per host so identity resolves with no init() call at all. That also unifies two defaults that disagreed (`<host>_plugin` vs `MEM0_<HOST>_PLUGIN`), which could yield three source values for one plugin. Ownership was inferred, not held. Path.replace is os.rename, which preserves mtime, so a claim made after a quiet minute inherited the spool's age and was stealable the instant it existed. Claims are touched on creation and the per-batch rewrite doubles as a lease heartbeat. Progress was not durable. flush() returned on the first failed batch without truncating, so the retry re-posted from index 0 — 150 events delivered 250 times. It now rewrites the claim with the unsent remainder after every batch, bounding a crash to one repeated batch, and each event carries a uuid. Parked batches starved. They were only reachable when no spool existed, and because sessions keep recording there usually was one, so a batch parked by a failed send waited until the 7-day expiry deleted it unsent — despite its own presence being what starts the sender. flush() drains them in the same run, and expiry now applies only after a genuine retry has failed. code.install counted upgrades and repeat sessions. is_first_run() read the identity file, which only a successful flush writes, so an offline user recorded an install every session forever. A dedicated install-state.json is claimed atomically at record time; a non-empty data directory reads as an upgrade. The docs called this anonymous. Every event carries the account email, and the hashes were unsalted SHA-256 over a git remote URL or an absolute path containing the username. READMEs, the module docstring and a new docs section now say what the code does, and repo/session digests are salted per install. A cached email outlived an API key change. It is now re-resolved when the key's fingerprint differs, and $identify aliases anonymous->email only — aliasing one account to another merges person profiles irreversibly. All six shipped green because the shared core's only tests lived under one host, behind a conftest that calls init() at import. Core behaviour was never exercised uninitialised. Adds agent-plugin-core/tests with no init, including subprocess tests and coverage for the portable plugin, which has no flush worker and would pass a native-only test vacuously. Also puts the three surface headers on the SDKs, CLIs and integrations, and corrects a README claiming ZAPIER/STRANDS were already in the platform allowlist. Verified: 59 core tests, 203 claude-code, 11 cursor, 5 codex, 2 kimi, 6 antigravity. ruff and compileall clean. --check clean for all six hosts. TypeScript changes are not typechecked locally (deps not installed). Claude-Session: https://claude.ai/code/session_01C7tEmH86HAr7GoAAKCEHZb
Mem0 - The Memory Layer for Your AI Apps
Mem0 is a self-improving memory layer for LLM applications, enabling personalized AI experiences that save costs and delight users. We offer both cloud and open-source solutions to cater to different needs.
See the complete OSS Docs. See the complete Platform API Reference.
1. Installation
For the open-source version, you can install the Mem0 package using npm:
npm i mem0ai
2. API Key Setup
For the cloud offering, sign in to Mem0 Platform to obtain your API Key.
3. Client Features
Cloud Offering
The cloud version provides a comprehensive set of features, including:
- Memory Operations: Perform CRUD operations on memories.
- Search Capabilities: Search for relevant memories using advanced filters.
- Memory History: Track changes to memories over time.
- Error Handling: Robust error handling for API-related issues.
- Async/Await Support: All methods return promises for easy integration.
Open-Source Offering
The open-source version includes the following top features:
- Memory Management: Add, update, delete, and retrieve memories.
- Vector Store Integration: Supports various vector store providers for efficient memory retrieval.
- LLM Support: Integrates with multiple LLM providers for generating responses.
- Customizable Configuration: Easily configure memory settings and providers.
- SQLite Storage: Use SQLite for memory history management.
4. Memory Operations
Mem0 provides a simple and customizable interface for performing memory operations. You can create long-term and short-term memories, search for relevant memories, and manage memory history.
5. Error Handling
The MemoryClient throws errors for any API-related issues. You can catch and handle these errors effectively.
6. Using with async/await
All methods of the MemoryClient return promises, allowing for seamless integration with async/await syntax.
7. Testing the Client
To test the MemoryClient in a Node.js environment, you can create a simple script to verify the functionality of memory operations.
Getting Help
If you have any questions or need assistance, please reach out to us:
- Email: founders@mem0.ai
- Join our discord community
- GitHub Issues: Report bugs or request features