Memory Bank (Cline / Roo / Cursor)

What it is

Cline and Roo Code made this method popular. It uses a folder of small, separate files instead of one giant file. The agent’s memory resets after each session. So, a rule makes it read every file in the folder before each new task. Some files describe the project and rarely change. Others, like activeContext.md, track your current work. Roo also adds a decisionLog.md file, where new decisions are added to the end.

Setup

1. Add a rule, like a .clinerules file or custom instruction. The rule tells the agent: “Read all memory-bank/ files at the start of every task; they are the source of truth.” This step is required.
2. Ask the agent to “initialize memory bank.” It will create the basic files from your code and documents.
3. Work as you normally would. When you make a big change, tell the agent to “update memory bank” or “UMB.” The agent will review all the files, rewrite activeContext.md, and add new entries to decisionLog.md.
4. Periodically, you must reconcile the files. This means merging the log file back into the main project files. This keeps them from becoming outdated. You also need to re-sync the folder when you change computers or work with teammates.

Sample directory structure

your-project/
├─ .clinerules              # "read memory-bank/ every task; it is the source of truth"
└─ memory-bank/
   ├─ projectbrief.md       # what the project is        (stable — drifts)
   ├─ productContext.md     # who it's for / why         (stable — drifts)
   ├─ systemPatterns.md     # architecture, conventions  (stable — drifts)
   ├─ activeContext.md      # current focus              (update often)
   ├─ progress.md           # done / remaining           (update often)
   └─ decisionLog.md        # append-only decisions      (Roo; newest at bottom)

Here’s the trick: the rule file contains no facts about the project. It only points to the folder. This prevents a common problem where the agent reads a summary and misses the real details. The log file always has the latest information, so the other files can be slightly out of date.

Pros & cons

Common user feedback

This feedback comes from GitHub, Cline's own documents, and other articles. (Note: One source, MemoryLake, sells a competing product, but other neutral sources confirm the issues it raises.)

• Token cost is the biggest complaint. One developer used ~300k tokens after only ~5 updates, causing high costs and delays (GitHub #2979). Cline agrees, saying “Memory Bank isn’t about minimizing tokens” and calling it “overkill” for tasks under a day (Cline on X).
• “Only updated when somebody remembers to update it.” A common problem is that the memory becomes outdated. Users say things like “forget to update them and Cline drifts,” “I forgot to update the Memory Bank last sprint” (MemoryLake).
• It can silently fail to update. A known bug causes updates to fail without warning. The agent will say it updated the files, but writes nothing to disk. One user reported: “You did not actually update the files.” (GitHub #1911).
• No team or multi-computer support. The memory is stored in your local project folder. You have to copy the folder manually between computers or teammates. Cline and Cursor do not share memory state (MemoryLake).
• The required workflow is demanding. The official guide suggests many steps. You must read every file for each task, run “update memory bank” often, and “update memory bank at ~2 million tokens and end the session” (Cline best practices).

How it did in our benchmark

We tested the agent on six facts that had been updated. The new facts were in decisionLog.md. The old facts were in the other files. The score shows how many of the six facts the agent got right.