Skip to main content

​
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 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 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.

Without a memory layer

  • 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.

Building it yourself

  • 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

​
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:
  • 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

​
Quick Start

  1. Get a MemoryLake key and a Boundary: Create an API key and a Boundary in the console.
  2. Pick a mode and swap the base URL: Choose BYOK or MemoryLake-hosted and point your SDK at the Router.
  3. Call as normal: Send requests exactly as you do today — memory is recalled and stored automatically.

​
Documentation

How It Works

Understand the transparent gateway and what happens on each request.

Quickstart

Go live in three steps with copy-paste code for BYOK and hosted modes.

Deployment Modes

Compare BYOK and MemoryLake-hosted, endpoints, supported providers, and key safety.

Observability

Trace requests, read the console call logs, and understand the error contract.

FAQ

Common questions about code changes, providers, security, and availability.