On the command line it looks like this:

Three commands show the project's philosophy well: writing, searching and generating an answer are separate. You can use only storage and retrieval, without making Memanto answer on behalf of your main agent.

What happens under the hood

Simplified, the stack has three floors. On top is the AI agent: Claude Code, Cursor, Codex, your own Python or TypeScript code, or any MCP client. In the middle is the Memanto Gateway: the CLI, a FastAPI REST layer, sessions, memory types, conflict handling, export and sync. At the bottom is Moorcheh: semantic storage and retrieval, in the cloud or in local Docker.

In their research paper the authors separate the gateway from internal services: CLI commands, REST requests and integrations all pass through one gateway, and behind it live separate Remember, Recall, Answer, Agent Manager, Session/Auth Manager, Conflict Resolution, Daily Summary and Memory Sync services.

Moorcheh's role deserves its own note, otherwise the picture is incomplete: Memanto is responsible for memory behaviour and the agent-oriented API, while the actual semantic search is delegated to Moorcheh. The authors call the approach Information-Theoretic Search - instead of the usual HNSW plus cosine similarity scheme, the engine uses its own binary representation and an information-theoretic score. The practical consequence that matters to a Memanto user: a written memory is searchable immediately, with no separate lengthy index-building stage.

One phrasing here is easy to misread. "No indexing wait" does not mean "no model involved at all". A plain remember writes already-formulated memory without a model. But if you ask Memanto to pull long-term facts out of a raw conversation, the --from-conversation operation does call a model - more on that below.

Installation

The CLI needs Python 3.10 or newer:

The first run opens a wizard and offers a backend choice: Moorcheh Cloud - then you need an API key, or Moorcheh On-Prem - then you need Docker and no cloud key. To check the install:

If you work from Node.js, target Node 20 and newer: that is the boundary written into the package.json of the official TypeScript SDK. Lower versions, which still turn up in older guides, the package no longer accepts.

Your first working memory

Memory lives inside an agent, so first create an agent for the project:

Creating it activates a session right away, so you can start writing:

Each record has three meaningful parts. The agent name isolates a specific project's memory. The content is one atomic thought worth keeping. And the type tells the system what it is looking at: a fact, a decision, an instruction or a preference.

A record also carries service fields worth knowing about from the start. Confidence is set with the --confidence flag and defaults to 0.8. Origin is set with --provenance and defaults to an explicit statement, while the system distinguishes six sources in all: explicit statement, inference, correction, validation, observation and import. There is also a title, tags and an indication of who wrote the record - a person or a particular agent. A batch of memories can be loaded at once from a JSON file with --batch.

Why thirteen memory types

An ordinary vector database keeps everything in one space. Memanto adds semantic classification, and not for looks: types give controlled retrieval - you can search decisions only, commitments only, or mistakes only.

The effect is practical: the question "what did we promise to finish?" can be limited to commitment, and "which mistakes have we already made?" to error. Noise is cut off before the model ever sees the results.

Search by meaning, and a ready answer

Plain words are enough:

The query does not have to repeat the memory's text. If "We chose Drizzle for the ORM" is stored, search will find it from phrasings like "what do we work with the database through?" or "which data layer was chosen?". And when the output needs narrowing, a type and a limit are added:

This is an important architectural habit: do not return fifty memories to the model just in case. The tighter the filter and the more sensible the limit, the less noise and the cheaper the following model call.

If you would rather not assemble the prompt yourself, there is one step further:

The difference is simple. recall returns memories, while answer finds relevant memory and passes it to the chosen model to get a finished response. When you already build your own prompt pipeline, recall is more useful - you decide how to insert memory into the system instruction. When you want a quick memory-RAG endpoint, answer is more convenient.

Agents, sessions and connecting your editor

Memanto separates a long-lived agent from a temporary session: the agent is a memory scope, the session is active access to that scope.

The REST API works with a session token. In the official quickstart the created session is time-limited - that way client code never holds permanent backend access, and the Moorcheh key itself stays on the Memanto server side.

Isolation here is not a formality. If two unrelated projects share one memory scope, the agent will one day recall a technical decision from the wrong project. Split scopes along the boundaries that genuinely should share knowledge.

The most interesting part for those who live in an editor: you do not need to write your own integration, the CLI installs the right configuration into the project itself.

Per the documentation, for editor integrations Memanto installs a tool-specific file - for example CLAUDE.md or a Cursor rule. There is a current-project mode and a global one:

The same agent can be connected to several tools at once - then Claude Code, Cursor and Windsurf all get a shared layer of project memory. There is a dedicated memanto connect multi command for that, and memanto connect remove takes a connection away.

When writing every memory by hand is too much

A plain remember is good when it is already clear what to save. But Memanto can take a raw conversation history and extract long-term records from it:

A single pass extracts at most twenty records - that is the default, and it can be raised or lowered with the --max-memories flag. The extraction model is overridden separately too, with --ai-model, and the source need not be a file: pass a dash instead of a path and the conversation is read from standard input.

This is where model extraction comes in. The dashboard offers a useful intermediate mode: first show the resulting memory cards, let you fix the type, text and confidence, and only then save. That is a good production pattern - important memory need not be trusted to fully automatic extraction, and for critical domains a review step before writing is wise.

Memory changes over time

One of the most interesting elements of Memanto is temporal queries. Memory is treated not as a current bag of facts but as a state that changes.

Through REST it looks like this:

Such queries answer questions like "which decision was in force before the migration?", "what changed over the week?", "which deadline was considered current at the start of the month?".

From the same nature of long-lived memory grows an inevitable problem: first "release on 15 August", then "release moved to 1 September". If you simply store both lines, the agent may pick the old one. There is a separate conflict workflow for that:

Having found a contradiction, the system offers options: keep the new record, keep the old one, keep both, delete both, or replace them with a manually worded memory. That is fundamentally better than silently overwriting when the history of a decision matters: the evolution of knowledge is preserved, and temporal queries let you reconstruct which state was current earlier.

Files, export and portability

Memory is not limited to short facts - files can be uploaded straight into an agent's memory. The documentation lists .pdf, .docx, .xlsx, .json, .txt, .csv and .md.

Here the line between agent memory and ordinary RAG gets thin, and the rule from the docs is sensible: save a short atomic fact through remember, and a large existing document through upload.

Memory is only useful as long as you can take it with you. Memanto exports the whole estate to Markdown, syncs MEMORY.md and works with the Open Knowledge Format:

OKF is described as a vendor-neutral set of Markdown files: you can read it by eye, keep it in Git and import it into another Memanto agent. Migration from other systems is provided too - Mem0, Letta, Supermemory and Langfuse, plus importing a ready OKF bundle back into an agent:

The REST API and the TypeScript SDK

The local API starts with a single command:

By default the server listens on http://localhost:8000, and the interactive OpenAPI documentation is at /docs. The client passes X-Session-Token, while the Moorcheh key stays on the server side and the client never needs it. A full cycle from Python looks like this:

The three steps are exactly the ones from the command line: activate a session for the memory scope, write typed memory, get records by the meaning of the question.

For Node.js there is a separate package:

This SDK has a detail worth knowing in advance: if you do not pass the address of an already running server, it starts a local Memanto server itself through uvx, waits for a health check, creates the agent if needed, activates a session and attaches the token to requests. So it is not a pure in-process JS library - behind the convenient client a Python server still gets launched. For predictable production deployment it is wiser to keep a separate, permanently running server and give the SDK its address.

A fully local setup

The On-Prem wizard deploys the Moorcheh backend in Docker and uses Ollama as the local embedder and answer model:

There are no ready-made default models here: in the local-stack configuration the provider and model fields for embeddings and answers are empty until you choose them in the wizard. Only the address is set in advance - the Moorcheh server runs on localhost:8080, and the Memanto gateway usually on localhost:8000. In the settings qwen2.5 is offered as one of the examples rather than as a default, and note that the first download of any local model can take several gigabytes. In this arrangement your code talks to Memanto, which talks to local Moorcheh and Ollama, and nothing leaves the machine.

Licensing: a nuance to check before adoption

The Memanto repository itself is MIT-licensed - visible both on GitHub and in pyproject.toml. But the local retrieval backend is a separate project, Moorcheh Community Edition, with a licence of its own.

The official Moorcheh On-Prem repository plainly calls the Community Edition source-available rather than OSI-approved open source, and describes free use for single-node and non-commercial deployment. Multi-node, enterprise and some commercial scenarios require a different licence.

The correct phrasing is therefore: the Memanto core is MIT, while the local Moorcheh backend has separate licensing terms. You cannot carry MIT automatically across the whole local stack, and this must be checked before commercial adoption.

Memanto and Mem0: a similar task, a different emphasis

Mem0 is a library-style memory layer. In the typical scenario it takes a conversation and automatically extracts compact facts from it, and its strength is a programmable memory API with a replaceable model, embedder and vector store.

Memanto is a memory service on top of Moorcheh. Its basic remember writes already-formulated typed memory directly, while extraction from a conversation exists as a separate operation. The emphasis here is on coding-agent integrations, types, time, conflict handling, the CLI and export.

Neither approach is "more correct". If your application needs a library where you assemble the memory pipeline yourself and swap the vector database, Mem0 looks natural. If you want to quickly give several agents a shared project memory, manage it from the terminal and connect Claude Code, Cursor or Codex - Memanto's architecture is more convenient.

The published numbers belong to the same comparison. The creators report 89.8% on LongMemEval and 87.1% on LoCoMo; in their research the final configuration uses a single semantic query and Gemini 3 for inference, without a knowledge-graph pipeline. These results should be read as the system authors' results on one particular evaluation configuration, not as a guarantee that any Memanto application will beat any Mem0 application: the quality of a memory system depends on the model, query construction, the data, the retrieval limit, the threshold, typing and the way you measure. The good news is that the team publishes the evaluation repository and datasets, so comparative claims can be checked and reproduced rather than taken on faith.

When Memanto is needed, and when it is redundant

It fits well when Claude Code, Cursor or Codex must remember the project between sessions; when several coding agents have to rely on shared decisions and rules; when you need to remember not only facts but decisions, mistakes and commitments; when it matters to ask "what changed?" and "what was known on this date?"; when memory must be exported into readable Markdown; when you want a ready set of CLI, REST API and dashboard instead of assembling a backend yourself.

It will be redundant in a short one-off stateless chat; when the data already sits neatly in tables and you need exact SQL queries rather than search by meaning; when all you need is a static RAG store of documents; when a couple of standing rules fit into CLAUDE.md or AGENTS.md more easily than a separate memory service gets deployed.

Seven mistakes on first acquaintance

Saving everything. Memory is not useful by volume: what stays in it should genuinely help the agent's future actions.

Labelling everything as fact. That throws away Memanto's main advantage. A decision is not a fact, a commitment is not a preference, and a mistake is not just an event.

Keeping one agent for all projects. That is an easy route to context bleeding between projects. Memory must be split along real boundaries.

Ignoring conflicts. Old and new information will start arguing over time - that is what the conflict workflow and temporal history are for.

Assuming local automatically means private. If Moorcheh runs locally but embeddings or answers go through OpenAI or Cohere, part of the data still leaves. For a closed environment use local Ollama models.

Not reading the backend licence. Memanto's MIT does not cancel the separate terms of Moorcheh Community Edition - especially before commercial deployment.

Not pinning versions. The project moves fast, and pyproject.toml at the time of checking still classifies the package as Alpha. In production it makes sense to pin versions and read the changelog before upgrading.

In short: Memanto is interesting not because it also has semantic search. Its strong idea is turning an agent's memory into a separate manageable object - with a type, time, conflicts, sessions, portability and ready integrations with development tools.

Sources

This material was checked against the repository, the official documentation, the TypeScript SDK reference, the on-prem documentation and the project's published research paper on 9 August 2026. Supplemented on 14 August 2026 against a fresh clone: the set of integrations corrected, the claim about default models in the local stack withdrawn, the Node version requirement aligned with what the package records, and service fields on a record, the extraction cap for conversations, the multi-connect commands and the full list of migration sources added. Memanto moves fast, so commands and constraints are worth re-checking against the current version before adoption.

• GitHub: moorcheh-ai/memanto
• Memanto Documentation
• Installation & Setup
• CLI Quickstart
• REST API Quickstart
• Memory Operations
• Temporal Memory
• Memory Types
• TypeScript SDK
• Integrations
• On-Prem Quickstart
• Moorcheh On-Prem Community Edition
• Research: Typed Semantic Memory with Information-Theoretic Retrieval for Long-Horizon Agents
• Memanto Benchmarks / Research