Cline Memory Bank: Files, Setup, Cost and Limits

The Cline Memory Bank is a set of custom instructions that make Cline keep six markdown files in your repository and read all of them at the start of every task. It is documentation the agent maintains itself, not a memory store: nothing is embedded, nothing is searched, and the whole folder re-enters the context window on each task.

Every fact below comes from Cline’s Memory Bank docs, its prompting guide and Cline’s own announcement post, checked on 18 October 2026.

What is the Cline Memory Bank?

The Cline Memory Bank is a documentation method, driven by custom instructions, that gives Cline project context across sessions. Six markdown files in a memory-bank/ folder describe the project, the architecture, the stack, the current focus and the progress. The instructions tell Cline to read them all before each task and to rewrite them when things change.

Cline’s docs frame the goal as turning Cline from a “stateless assistant” into a persistent development partner. The announcement post calls it a “community-created custom instruction set”, written by Cline’s product marketing team and published by the vendor. It ships no code. Any agent that can read markdown can follow the same pattern, which is why the convention spread to Roo Code, Cursor and others.

The six files and their hierarchy

1memory-bank/
2├── projectbrief.md      # Foundation: core requirements and goals
3├── productContext.md    # Why the project exists, problems it solves, UX goals
4├── systemPatterns.md    # Architecture, design patterns, component relationships
5├── techContext.md       # Tech stack, setup, constraints, dependencies
6├── activeContext.md     # Current focus, recent changes, next steps
7└── progress.md          # What works, what's left, known issues

The order is not alphabetical, it is a dependency chain. projectbrief.md is the source of truth. It feeds productContext.md, systemPatterns.md and techContext.md, and those three feed activeContext.md and progress.md. Change the brief and everything downstream is supposed to be revisited.

You can add more files or folders under memory-bank/ for complex features, integration specs, API docs, testing strategies and deployment procedures. The docs set no limit on how many, which matters once you see what reading costs.

How to set it up

1. Open Cline’s Memory Bank docs and copy the custom instruction block.
2. Save it as a Cline rules file, typically .clinerules/memory-bank.md. Rules files live in the repo, so the whole team gets the same behaviour. A global custom instruction works too, but then it applies to every project.
3. Optionally make the rule conditional, so the instructions only activate when memory-bank/ files are in play.
4. Tell Cline: “initialize memory bank”. It creates the structure and fills it from what it can read of the project.
5. Review what it wrote. The brief is the root of the hierarchy, so an inaccurate projectbrief.md poisons every file derived from it.
6. At the end of a work session, say “update memory bank”. That triggers a review of all files, not just the one that changed.
7. In a fresh conversation, say “follow your custom instructions”. Cline reads the bank and resumes.

The three commands

Cline’s built-in /newtask and /smol slash commands handle the related problem of a context window filling up, and Auto Compact does routine compaction. The docs suggest leaning on Auto Compact for day to day context and saving manual Memory Bank updates for real checkpoints.

When to update it

Cline’s docs list four triggers: when Cline discovers new project patterns, after significant changes, when you ask, and when context needs clarification. In practice:

• activeContext.md changes most often. Update it after each session.
• Re-read progress.md when you resume work.
• Do a full update memory bank after a milestone or a change of direction, or every few sessions during active development.

Skipping updates is the usual failure mode. The bank then describes a version of the project that no longer exists, and because the instructions make Cline trust it, stale documentation is worse than none.

What it costs

The custom instructions are explicit: “I MUST read ALL memory bank files at the start of EVERY task - this is not optional.”

That single line is the whole cost model. There is no retrieval step and no relevance filter, so every task pays for the entire folder. Cline’s docs give no token numbers for this, and the blog post gives none either, quoting only that model context windows “typically range from 32k to 200k tokens”. Two consequences follow:

• The cost scales with the folder, not the question. A one-line CSS fix loads the same architecture and deployment docs as a schema migration.
• Writing costs too. update memory bank is a full review of every file, which means reading them all and generating new versions.

That is the trade the Memory Bank makes: no infrastructure, total transparency, everything in git and readable by a human, paid for with context on every task. For small repos and short projects, that trade is good. For a long-running codebase with months of history, the folder grows past what you want to re-read each time, and the pattern runs out of room. The same tension shows up in agent memory versus documentation generally.

Memory Bank vs a memory server

The two are not exclusive. A memory bank is good at facts that should be stable and reviewed, like architecture decisions. A memory server is better at the long tail of what happened: which fix failed, which test is flaky, what the user asked for three weeks ago. Other coding agents split the same way, as the comparison of AI coding agent memory across tools shows, and Claude Code’s memory is the same file-based idea with a different file name.

Where Hindsight fits

Hindsight is an MIT-licensed memory server that covers what a markdown folder cannot: retrieval instead of re-reading. recall runs semantic, BM25 keyword, graph and temporal-range search in parallel, fuses the results, reranks them with a cross-encoder and trims to a max_tokens budget you set. So the cost is bounded per call and does not grow with history, which is the opposite of the Memory Bank’s cost shape.

It installs into Cline directly. The README lists Cline among its coding-agent integrations, with the generic installer npx @vectorize-io/hindsight-coding-agents install all picking up every agent it detects, and an MCP server as the alternative route.

On long histories the gap is measurable. On Vectorize’s own benchmark site Hindsight scores 73.9 on BEAM 1M and 64.1 on BEAM 10M; Mem0’s own comparison page puts Mem0 at 64.1 and 48.6 on the same two. Those numbers are vendor-reported on both sides, and the benchmark is run by Vectorize, so treat them as the vendors’ claims, not an audit. Where it matters for a coding agent: BEAM 10M is the test of remembering across a very long history, which is exactly where a growing memory-bank/ folder stops fitting.

Two limits to weigh. Hindsight returns more context per retrieval than Mem0 by default, around 4x by Mem0’s measurement, so set max_tokens if your budget is tight. And writes cost more, because retain and consolidation both call an LLM, where a memory bank update only costs what Cline already charges you. Hindsight publishes no compliance certifications; Mem0 lists SOC 2 Type 1 and HIPAA. For a fuller picture see Hindsight’s memory model and Mem0 vs Hindsight.

Should you use it?

Use the Cline Memory Bank if your project is small enough that six markdown files describe it, you want the memory in git and reviewable, and you do not want to run anything. It is free, inspectable and takes ten minutes to set up.

Reach for a memory server when the history is the point: when “what did we try last month” matters more than “what is the architecture”, when several agents or several repos need the same memory, or when re-reading the whole folder on every task has become the biggest line in your token bill. Many teams end up with both, a short hand-reviewed bank for stable facts and a server for everything that accumulates.