feat: update to version 3 endpoints and adding update and delete tool and adding oss support to mem0 plugin in hermes agent.

[kartik-mem0]

resolves #16401

What does this PR do?

Adds OSS (self-hosted) mode to the Mem0 memory provider, allowing users to run Mem0 locally with their own LLM, embedder, and vector store instead of requiring the Mem0 Platform API. Also upgrades the plugin from v2 to v3 API endpoints, adds mem0_update and mem0_delete tools and renames for better dx for existing cli users in mem0, and fixes circuit breaker false positives on client errors (404, 422).

Type of Change

• ✨ New feature (non-breaking change that adds functionality)
• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• Backend abstraction (plugins/memory/mem0/_backend.py): Mem0Backend ABC with PlatformBackend (cloud API) and OSSBackend (local mem0ai SDK). OSS backend handles PostHog telemetry shutdown to
  prevent Ctrl+C hangs.
• OSS provider definitions (plugins/memory/mem0/_oss_providers.py): LLM (openai, ollama), embedder (openai, ollama), vector store (qdrant, pgvector) with validation.
• Setup wizard (plugins/memory/mem0/_setup.py): Interactive (curses pickers) and flag-based (--mode oss --oss-llm openai) setup. Auto-installs optional deps (ollama, psycopg2-binary,
  qdrant-client). Auto-starts pgvector via Docker and Ollama if needed. API key masking for existing keys. Connectivity checks on save.
• V3 API migration (plugins/memory/mem0/init.py): Updated all tool endpoints from v2 to v3. Added mem0_update and mem0_delete tools. Added None-backend guard with mode-aware error messages.
  Circuit breaker now skips client errors (404, 422).
• Telemetry (plugins/memory/mem0/telemetry.py): Platform version tracking.
• Docs: Updated README.md with OSS setup instructions, flags reference, troubleshooting. Updated memory-providers.md with OSS provider tables.
• Tests: 77 tests across test_mem0_v3.py, test_mem0_setup.py, test_mem0_backend.py, test_mem0_providers.py. Removed obsolete test_mem0_v2.py.

How to Test

1. hermes memory setup → select "Open Source" → pick providers → verify config saved to ~/.hermes/mem0.json
2. hermes → ask agent to use mem0_add, mem0_list, mem0_search, mem0_update, mem0_delete
3. hermes memory setup → select "Platform" → verify cloud mode still works
4. pytest tests/plugins/memory/ -v → 77 tests pass

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this feature
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes
• I've tested on my platform: macOS 15 (Apple Silicon M5)

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings)
• I've considered cross-platform impact
• I've updated tool descriptions/schemas for new tools

[kartik-mem0]

@alt-glitch @kshitijk4poor all the changes are stable and working now can you guys do a review on this and lmk if this pr looks good to you guys?

[kshitijk4poor]

Thanks for this substantial upgrade to the Mem0 plugin — the OSS mode architecture is clean, the Mem0Backend ABC abstraction is well-designed, and 77 tests is excellent coverage. The core ideas here are solid and this is worth landing with a few fixes.

Critical

1. hermes_cli/memory_setup.py is a core file — plugin PRs must not touch it

The version-comparison logic added to _install_dependencies() lives in hermes_cli/ which is shared CLI infrastructure used by every memory plugin (Hindsight, Honcho, SuperMemory, etc.). A regression here breaks all of them. The version gate is needed because plugin.yaml now pins mem0ai>=2.0.1 — but that enforcement belongs in the plugin's own post_setup() hook, not in the shared core. Please move the version-check logic to plugins/memory/mem0/_setup.py::post_setup() and revert hermes_cli/memory_setup.py to its current-main state.

2. PostHog API key hardcoded in source

telemetry.py line 26 commits a PostHog write key to the public repo. Anyone can scrape the git history and inject arbitrary events into that PostHog project. This key should not be in source — if telemetry is kept, the key should be injected at build/release time or via a separate config mechanism.

3. Telemetry opt-out is undocumented

MEM0_TELEMETRY=false is mentioned only in the module docstring, nowhere a user would look. Please add it to README.md and the memory-providers user guide. Users — especially in enterprise environments — need a documented path to disable telemetry.

4. Telemetry collects a hardware fingerprint

Every event sends processor (e.g. "Apple M3 Pro"), machine ("arm64"), os_version, os_release, python_version. That's a granular enough combination to re-identify individual installations. Consider limiting to high-level analytics (os_platform, python_major_minor, tool call success/failure) rather than hardware specifics.

Warnings

5. Circuit breaker fix is incomplete — mem0_list and mem0_search still trip on 404s

The stated goal is "fix circuit breaker false positives on client errors." _is_client_error() is correctly applied to mem0_update and mem0_delete, but mem0_list (line ~453) and mem0_search (line ~478) still call _record_failure() unconditionally. A 404 from an invalid user_id filter will still tick toward the breaker threshold in those handlers.

6. get_config_schema() is stale for OSS mode — hermes memory status misleads OSS users

The schema still returns only platform fields (api_key, user_id, agent_id, rerank). When OSS mode is active, the status command will show MEM0_API_KEY ✗ as missing and the plugin will look broken even when correctly configured. The schema should be mode-aware or updated to reflect OSS fields.

7. _setup.py imports private functions from core: _curses_select, _prompt

These underscore-prefixed internals of hermes_cli/memory_setup.py aren't part of a stable plugin API. If they're renamed or refactored upstream, the plugin breaks silently with an ImportError.

8. OSSBackend.get_all() ignores page/page_size — unbounded fetch for large collections

The OSS backend fetches all memories and ignores the pagination arguments. For users with thousands of memories, every mem0_list call is an unbounded load. The mem0ai SDK does support pagination — worth threading through.

9. plugin.yaml version not bumped

This adds OSS mode, two new tools, v3 API, and a new minimum dep version. 1.0.0 → 1.1.0 at minimum would be appropriate.

10. Both contributor emails missing from AUTHOR_MAP

chaithanya.kumar42a@gmail.com and kartik.labhshetwar@mem0.ai need entries in scripts/release.py's AUTHOR_MAP before this can merge cleanly.

Suggestions

• _write_env() in _setup.py duplicates _write_env_vars() in hermes_cli/memory_setup.py — consider importing the shared helper
• parse_flags() is a 60-line hand-rolled argv parser that can't handle --flag=value form and silently drops unknown flags — argparse would be simpler and more robust
• Mem0Backend ABC should declare close() with a default no-op rather than leaving callers to hasattr-guard it at runtime
• In OSS mode, mem0.Memory already fires its own PostHog telemetry internally — the new telemetry.py adds a second layer on top

Looks Good

• Mem0Backend ABC cleanly separates Platform vs OSS concerns; _unwrap_results() correctly normalises both response formats
• Circuit breaker, prefetch threading, and sync threading patterns are solid
• OSSBackend.close() correctly handles PostHog shutdown to prevent Ctrl+C hangs
• _load_config() resolution order (env → JSON → gateway-native ID) is well-designed and well-documented
• _recreate_collection_if_dims_changed is a thoughtful guard for the common OSS mistake of switching embedding models without recreating the vector collection
• Test structure (test_mem0_backend.py, test_mem0_providers.py, test_mem0_setup.py, test_mem0_v3.py) is clean and comprehensive — 210 tests pass

[kartik-mem0]

2. PostHog API key hardcoded in source

telemetry.py line 26 commits a PostHog write key to the public repo. Anyone can scrape the git history and inject arbitrary events into that PostHog project. This key should not be in source — if telemetry is kept, the key should be injected at build/release time or via a separate config mechanism.

This is a write-only PostHog project API key by design it can only ingest events, not read data or modify project settings. This is the standard PostHog deployment pattern (PostHog docs): the key is meant to be shipped in client-side code (JS bundles, mobile apps, CLI tools) and is not considered a secret.

Worst case if someone scrapes it: they can send junk events, which we can filter server-side via PostHog's ingestion filters. Rotating the key is also trivial on the PostHog dashboard.

That said, if the team prefers env-based injection, happy to move it behind MEM0_POSTHOG_KEY with a fallback just let me know.