> ## Documentation Index
> Fetch the complete documentation index at: https://docs.memorylake.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Overview
> A drop-in memory gateway that adds persistent memory to your LLM calls with a base-URL change
## Quick Introduction
Memory Router is a transparent gateway that sits between your app and the model. Point your existing SDK at MemoryLake, attach a memory Boundary, and every conversation gains long-term memory — no new SDK, no retrieval pipeline to build.
* **Minimal integration** — change the base URL and pass a `boundary_id`; keep your SDK and code as they are
* **BYOK or hosted** — bring your own provider key (encrypted in transit, never stored), or use MemoryLake-hosted models with a single key
* **Shared memory pool** — the Router and the [MemoryLake API](/features/memorylake/overview) read and write the same memories, so there is one source of truth
Memory Router is currently in **private preview**. If the Memory Router card is not yet visible under **Integrations** in your console, contact [support@memorylake.ai](mailto:support@memorylake.ai) to request access.
Memory Router speaks the OpenAI and Anthropic protocols natively. Your prompts, streaming, and tool calls stay identical.
## The Problem It Solves
Every LLM call is stateless. To fake continuity you re-send the entire history on every turn — which is slow, expensive, and eventually overflows the context window. Bolting on a vector DB and retrieval pipeline solves it, but it is weeks of plumbing you have to build and maintain.
* Full chat history re-sent on every call — token cost climbs with conversation length.
* Long sessions hit the context-window ceiling and start truncating mid-task.
* Memory lives in one app — switch models or sessions and the context is gone.
* Stand up a vector DB, embeddings pipeline, chunking, and retrieval logic.
* Write extraction, dedup, and relevance ranking — then keep it tuned.
* Maintain it across every provider and every model you support.
Memory Router collapses all of that into a base-URL change plus one query parameter. **The memory layer is the gateway.**
## What You Get
| Capability | What it means |
| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| **Minimal integration** | Change the base URL and pass `boundary_id`. Keep your SDK and your code as they are. |
| **BYOK or hosted** | Bring your own provider key (encrypted in transit, never stored) or use MemoryLake-hosted models with a single key. |
| **Automatic memory** | Relevant memories are recalled and injected before the call; new memories are extracted asynchronously after it — never delaying the response. |
| **Scoped by Boundary** | A [Boundary](#boundaries:-the-memory-scope) defines exactly which workspace, projects, and actors a conversation's memory belongs to. |
| **Shared memory pool** | The Router and the MemoryLake API read and write the same memories — one source of truth. |
| **Traceable** | Every response carries an `X-Trace-ID` header, and each call lands in the console Logs with model, token, and key-source details. |
## Boundaries: The Memory Scope
Memory on the Router is **opt-in per request**. A **Boundary** binds a conversation to its memory scope — a workspace, one or more projects, a human actor, and an assistant actor. You create a Boundary once in the console, then pass its id on each call:
```text theme={null}
POST /openai/v1/chat/completions?boundary_id=
```
* **With `boundary_id`** — memories in that scope are recalled and injected, and new memories from the conversation are stored back into it.
* **Without `boundary_id`** — the request passes through to the model unchanged, with memory disabled.
This makes memory explicit and controllable: the same endpoint can serve memory-enabled product traffic and plain passthrough traffic side by side.
## Direct API Call vs. Memory Router
| | Direct provider call | With Memory Router |
| ------------------------ | ------------------------------ | ----------------------------------------------- |
| Long-term memory | You build and host it | Built in, automatic |
| Keys & accounts | A provider account is required | BYOK or use just a MemoryLake key |
| Code changes | New SDK + retrieval pipeline | Base-URL change + `boundary_id` |
| Across sessions & models | Memory is siloed per app | Shared memory pool |
| Memory scoping | Ad-hoc, per app | Explicit Boundaries per workspace/project/actor |
| Visibility | None by default | `X-Trace-ID` + console call logs |
## Quick Start
1. **[Get a MemoryLake key and a Boundary](/features/memory-router/quickstart#step-1:-get-a-key-and-a-boundary)**: Create an API key and a Boundary in the console.
2. **[Pick a mode and swap the base URL](/features/memory-router/deployment-modes)**: Choose BYOK or MemoryLake-hosted and point your SDK at the Router.
3. **[Call as normal](/features/memory-router/quickstart#step-3:-call-as-normal)**: Send requests exactly as you do today — memory is recalled and stored automatically.
## Documentation
Understand the transparent gateway and what happens on each request.
Go live in three steps with copy-paste code for BYOK and hosted modes.
Compare BYOK and MemoryLake-hosted, endpoints, supported providers, and key safety.
Trace requests, read the console call logs, and understand the error contract.
Common questions about code changes, providers, security, and availability.