GO TO A SECTION

↑ ↓ to navigate · Enter to openExplore all sections →
FDEInterviews logo
arXiv preprint

MemGPT: Towards LLMs as Operating Systems

Treat the context window like RAM: a small editable working memory in the prompt, everything else in searchable storage, and the model paging data in and out itself through function calls.

Breakdown by FDE Interviews · 12 min read · Updated

About the original · 2023
AUTHORS
Packer, Wooders, Lin, Fang, Patil, Stoica, Gonzalez
FROM
UC Berkeley
PUBLISHED
Oct 2023 · arXiv preprint
CITED BY
1,624Semantic Scholar · Oct 2026
IN THIS BREAKDOWN · 10 SECTIONS

You can read 22% of this breakdown.

01

The paper in one minute

A language model only knows what is in its prompt. For a companion chatbot that talks to someone for months, or an analyst reading a document longer than the window, that is a hard limit. Charles Packer, Sarah Wooders, Ion Stoica, Joseph Gonzalez and colleagues at UC Berkeley borrowed a fix from operating systems. Programs see a large virtual memory while the OS moves pages between RAM and disk. MemGPT gives a model the same illusion of unbounded context.

The prompt, called main context, has three parts. System instructions are read-only and describe the memory system and the functions available. Working context is a small block of text the model can edit through function calls, used for key facts about the user and the persona it plays. A FIFO queue holds recent messages, function results and system alerts, with a recursive summary of older messages at its head.

Outside the prompt, external context has two stores. Recall storage keeps every message ever exchanged. Archival storage holds arbitrary text, such as documents, with vector search. The model moves data between tiers itself: it can append to or replace its working context, search recall or archival storage page by page, and insert results back into the prompt. A queue manager warns it when the prompt reaches about 70% of the window, so it can save what matters, and at 100% evicts about half the queue into recall storage and updates the summary. A request_heartbeat flag lets the model chain several function calls before replying, and events such as user messages, uploads or timers trigger it to run.

On a multi-session chat benchmark, MemGPT answered questions about earlier sessions far more accurately than the same models given a summary, and wrote conversation openers that drew more on what it knew about the user. On documents, it could page through retrieval results beyond what fits in the window, and it solved multi-hop key-value lookups that defeated plain models.

THE IDEA, VISUALLY
MAIN CONTEXT: THE PROMPT System instructions · read-only · memory rules + function schemas Working context · facts about the user and persona · edited by functions FIFO queue · [recursive summary] · recent messages · function results at 70%: memory warning · at 100%: evict ~half, re-summarize evicted search, page in Recall storage every message ever Archival storage any text · vector search external context: outside the prompt, reached by function calls THE MODEL MANAGES ITS OWN MEMORY working_context.append / replace update facts in the prompt archival_storage.search find long-term text, paginated recall_storage.search find old messages, paginated request_heartbeat=true chain another call before replying Events trigger inference: user messages, memory warnings, timers, uploads. DEEP MEMORY RETRIEVAL, MSC SESSION 6 (TABLE 2) GPT-3.5 Turbo 38.7% 66.9% GPT-4 32.1% 92.5% GPT-4 Turbo 35.3% 93.4% model alone, lossy summary of sessions 1-5 MemGPT, searches the full history NESTED KEY-VALUE LOOKUP (FIGURE 7) 140 UUID pairs, about 8k tokens; each hop is a lookup. GPT-3.5 alone: 0% at 1 hop. GPT-4 alone: 0% by 3 hops. MemGPT with GPT-4: unaffected by depth, by repeated search. MemGPT with GPT-3.5 or GPT-4 Turbo: falls from 2 hops. Document QA on 50 questions: baselines are capped by the retriever; MemGPT can page further but often stops early. GPT-3.5's weak function calling hurt MemGPT the most.
MemGPT splits memory into what is in the prompt and what is stored outside it, and lets the model move data between the two with function calls, the way an operating system pages memory. With search over the full history, it answered questions about past sessions far better than models given only a summary.
Research notes: the problem, approach and results
32.1 → 92.5%

deep memory retrieval accuracy with GPT-4, alone with a summary against MemGPT searching full history

70% / 100%

context fill levels that trigger a memory-pressure warning and a queue flush with re-summarization

0 → ~1

nested lookup: plain GPT-4 reached 0% by three hops; MemGPT with GPT-4 was unaffected by depth

THE PROBLEM

Context windows are finite. A long-running assistant forgets earlier sessions once they scroll out, and a document longer than the window cannot be read at once. Bigger windows are expensive and models use their middle poorly.

THE IDEA

Borrow virtual memory from operating systems. Keep a small working context and a message queue in the prompt; store everything else in recall and archival storage; give the model functions to edit its working context and search storage, plus warnings when the prompt fills.

THE RESULT

On questions about earlier chat sessions, accuracy rose from 32-39% to 67-93% depending on the model. On nested key-value lookups, MemGPT with GPT-4 kept succeeding as the number of hops grew while plain models fell to zero.

02

Why it matters to an FDE

Customers want assistants that remember: a support agent that knows the last three tickets, an analyst that keeps track of a long investigation, a coach that recalls goals from last month. MemGPT is the reference design for that, and the project behind it continues as open source.

Separate always-present facts from searchable history. A short working context (who the user is, their preferences, the current goal) belongs in every prompt. Everything else should live in storage the model can search. That split keeps prompts small and costs predictable.

Let the model see the budget. Warnings at a fill threshold give the model a chance to save important facts before eviction, instead of losing them silently.

Memory writes are product decisions. When the model decides what to store about a user, you need rules for what may be stored, how it is corrected, and how it is deleted on request. The paper does not address these; your deployment must.

Function-calling quality decides everything. With GPT-3.5, MemGPT lost much of its advantage because the model handled the memory functions poorly. Test the model you will deploy on the memory operations themselves.

THE FULL BREAKDOWN

Understand the mechanism. Try it on a real problem.

Unlock this breakdown and 99 more papers.

Premium opens every paper in full, plus every answer, concept, course and guide on the site. One payment for six months of access.

6 months · One payment · No auto-renewal

Get Premium · ₹2,000 / $25
  • ◇1 architecture diagram
  • </>1 runnable code experiment
  • ▦2 results tables
  • ?5 interview questions with answers
  1. 03Key takeaways

    The memory tiers, the control flow, the experiments, and misreadings to avoid

    Free account
  2. 04How it works

    The prompt layout, the eviction policy, function chaining, and each experiment's setup

    Premium
  3. 05The numbers that matter

    What each result shows, what the baselines were, and what was not measured

    Premium
  4. 06Try it yourself

    Truncation, recursive summary and paged search over recall storage on a synthetic five-session chat

    Premium
  5. 07Where it breaks

    The limits of self-managed memory and of the paper's evaluation

    Premium
  6. 08Using it on a deployment

    Building a memory system for a customer's assistant: tiers, writes, budgets and governance

    Premium
  7. 09Interview angles

    Five questions this paper prepares you for, with answer hints

    Premium
Back to the paper library →