OMP decouples your application code from the underlying memory backend. You write against a singleDocumentation Index
Fetch the complete documentation index at: https://docs.openmem.blog/llms.txt
Use this file to discover all available pages before exploring further.
Memory interface, and the SDK routes your calls to whichever provider you configure — without any changes to your application logic. The component that bridges OMP to a specific backend is called a provider adapter.
What is a provider?
A provider is any backend that stores and retrieves memories. Providers range from self-hosted databases (Postgres with pgvector) to managed cloud services (Mem0, Supermemory, Letta). The SDK ships with a translation adapter for each supported provider. When a provider implements the OMP protocol natively, the SDK can also communicate with it directly through a passthrough adapter.Supported providers
| Provider | Install extra | Constructor | Notes |
|---|---|---|---|
| Postgres + pgvector | (core) | Memory(provider="postgres", url=...) | Self-hosted reference backend |
| Mem0 | [mem0] | Memory(provider="mem0", api_key=...) | Translation adapter |
| Supermemory | [supermemory] | Memory(provider="supermemory", api_key=...) | Translation adapter |
| Letta | [letta] | Memory(provider="letta", api_key=...) | Translation adapter |
| Any OMP-native server | (core) | Memory(provider="passthrough", base_url=...) | Passthrough adapter |
Adapter types
OMP uses two fundamentally different adapter strategies depending on whether a provider speaks OMP natively.Translation adapter
A translation adapter maps OMP verbs and schema fields to the provider’s proprietary API. When you callmem.search(...), the adapter translates that into whatever API call the provider actually expects, then normalizes the response back into OMP types. Translation adapters exist for Mem0, Supermemory, Letta, and Postgres.
Passthrough adapter
A passthrough adapter is a thin HTTP client that forwards OMP requests directly to a provider whose own HTTP API already implements the OMP protocol. There is almost no translation — the adapter adds authentication headers and handles response parsing. The SDK auto-selects the passthrough adapter when it detects a native OMP server.Auto-detection
When you supplybase_url, the SDK probes GET {base_url}/capabilities before constructing an adapter. If the response contains an omp_version field, the provider speaks OMP natively and the SDK uses the passthrough adapter automatically. If the probe fails or omp_version is absent, the SDK falls back to the translation adapter for the specified provider.
Conformance tiers
Every provider is classified into one of four conformance tiers based on how it implements OMP. Tiers appear in the SDK, docs, and provider directory.OMP Native
The provider’s own HTTP API implements OMP v0.1+. The SDK uses the passthrough adapter. Requires passing the official conformance test suite.
OMP Compatible
An official adapter exists, built or endorsed by the provider. The SDK uses a translation adapter.
OMP Community
A third-party adapter exists with no official provider support. The SDK uses a translation adapter.
Not OMP
No adapter exists. The provider does not work with OMP.
add, search, get, delete, list, capabilities), pass the conformance test suite, return omp_version in /capabilities, and use the standard error model.
Provider instantiation examples
Memory instance, every verb (add, search, get, update, delete, list, context, capabilities) works identically regardless of the provider. Switching backends requires changing only the constructor call.