The plain definition, what a gateway does on its own, what memory adds to it, and how it differs from a memory API and from the memory built into one chatbot.
An AI memory gateway is an API gateway for AI models that adds memory to every call. Like any LLM gateway, it gives an application one endpoint and one key for models from many providers and routes each request to the model named in it. Unlike a plain gateway, it keeps a persistent memory outside the model: before a request reaches the model, the gateway retrieves the memories that fit and adds them to the prompt, and after the reply it can save what was decided. Because the memory lives in the gateway rather than in one app or one model, the same memory serves every model and every application that calls through it.
An LLM gateway, sometimes called an AI gateway or a proxy, sits between your code and the model providers. The vendors describe the job in nearly the same words.
LiteLLM describes its gateway as one OpenAI-compatible endpoint for more than a hundred providers: if a client can use the OpenAI API, it can use the gateway, with no client code changed. OpenRouter gives access to hundreds of models through a single API endpoint. Vercel's gateway centralizes credentials and fails over across providers from any infrastructure.
Cloudflare's AI Gateway adds analytics and logging, then caching, rate limiting, request retries and model fallback. Portkey adds a universal API, simple and semantic caching, fallbacks, conditional routing, guardrails and load balancing. LiteLLM adds virtual keys with budgets, spend tracking per key and team, and logging to observability tools.
A plain gateway is stateless about the person or the project behind the call. A cache may return the same answer to the same request, and logs record what was sent, but none of the gateways above carries what you decided yesterday into today's prompt on its own. The nearest thing is LiteLLM's per-key memory store, a /v1/memory API from version 1.83.10, where your own code fetches the entries and adds them to the prompt. Each call otherwise starts from nothing, exactly as the model does.
A memory gateway keeps the routing and adds a loop around every call.
The gateway searches a memory store for the entries that fit the request: your preferences, the project's decisions, what was settled last week. It adds them to the prompt before the request leaves for the model.
When the exchange settles something new, the gateway saves it, and when a new fact contradicts an old one, the old one is superseded instead of accumulating. Designs differ here. Mastra's gateway, for example, runs observer and reflector agents that compress the chat history into a dense observation log, which Mastra says compresses history 5 to 40x.
Facts about you should follow you everywhere, while a project's details should stay in that project. A memory gateway needs a way to tell the two apart, usually from the key or the folder the call came from.
Because the gateway changed the prompt, a good one shows its work on every reply: which memories it used, what it learned, and the time and tokens memory added. Without that, you cannot audit what the model was told.
Memory that cannot be seen, corrected or forgotten is a liability. The controls belong at the gateway, where the memory lives, so a forget applies to every model and every app at once.
A memory API, a memory service reached by connector, and a chatbot's built-in memory all give an AI some memory of you. They differ in where the memory lives and how an app reaches it.
These are not rivals so much as different shapes, and more than one can be true at once: a memory gateway can hold the same memory a plugin captures in your editor.
The others
Memory gateway
Memory API (mem0 and similar)
The others: A managed memory layer your code calls, mostly with explicit add and search; mem0 also ships an OpenAI-compatible client that adds memory to chat completions, an SDK swap rather than a base-URL gateway. mem0's platform describes itself as the fully managed memory layer for AI apps and agents, with no vector store or infrastructure to run.
Memory gateway: The memory calls happen inside the gateway; your code changes a base URL and a key and keeps calling the model.
Memory service reached by connector (MemoryRouter and similar)
The others: One memory that tools reach through an MCP connector or API calls, after what one assistant remembers about you has been moved into it.
Memory gateway: The memory is added inside the model call itself: the request passes through the gateway and picks up memory on the way, with no connector or memory call in the app.
Built-in memory (ChatGPT, Claude)
The others: Lives inside one product and makes that product better; ChatGPT web, local Codex and Claude Code each keep their own store.
Memory gateway: Independent of any one product, and the same for every model you route through it.
Then a memory gateway is a base URL and a key, and every model you call through it gets the same memory. Any other shape means adding a memory call before and after each request.
When the model changes, in-app memory and prompt files stay behind. Memory in the gateway comes along, because the gateway is the one place every call passes through.
Claude Code and Codex make model calls too. A gateway that both can route through gives your app and your coding agents one memory instead of three.
A single-model app with its own user database may not need a gateway at all. Retrieval over a fixed set of documents is RAG, not memory (the memory-layer explainer draws that line). And a gateway that remembers you is not the same as one that remembers each of your app's end users; check which one a product offers before you build on it.
Everything above describes the category. Atlaso Gateway is one memory gateway, being built now, and the waitlist gets in first.
Point your app at api.atlaso.ai/v1 with an Atlaso key. Every model takes OpenAI's request format, so only the model name changes. It launches with models from Anthropic, OpenAI, Google, DeepSeek and xAI, and the model you pick is always the one called.
One command installs a small helper on your computer, and they keep running on your own Claude or ChatGPT plan. One command undoes it.
Each call shows the memories it used, what it learned, and the time and tokens memory added. What it learns is marked "you said" or "AI suggested, you accepted", with Undo; say "forget that" and no tool uses it again.
Atlaso Gateway and the Atlaso Plugin are two ways into the same memory, so what Cursor captured through the Plugin is there on a Gateway call. Where the Gateway is on, the Plugin steps aside, so nothing is saved twice. The first release remembers you, the person holding the key, not each end user of your app.
An API gateway for AI models that adds memory to every call: one endpoint and one key for many models, plus a persistent memory kept outside the model, retrieved into each request before it reaches the model and updated from the reply. The memory is shared by every model and every app that calls through the gateway.
Still have a question?
Write to usEvery category fact on this page comes from one of these pages, read on 26 October 2026; every Atlaso fact is from the Gateway page's own questions.
Join the waitlist and your apps and coding tools get one memory that arrives with each call. Free to join.
Join the waitlist