Memory Bank in Cline: Setting Up Project Memory for the Agent

Cline does not remember past conversations: every new task starts from a blank slate. Cline Memory Bank solves this with discipline rather than magic: the project keeps a few markdown files, and by rule the agent reads them before working and updates them afterwards. The approach has a token price, and it is easy to underestimate. Let's set up memory so that it helps without bleeding money.

What Memory Bank is

According to Cline's documentation, Memory Bank is a documentation methodology that turns a stateless assistant into a partner with persistent context. Technically these are ordinary files in the project folder, accessible to both you and the agent. The standard structure:

memory-bank/
├── projectbrief.md      # foundation: goals and requirements
├── productContext.md    # why the project exists, what it solves
├── activeContext.md     # current focus, recent changes, next steps
├── systemPatterns.md    # architecture and patterns
├── techContext.md       # stack, environment, constraints
└── progress.md          # what works, what is left, known issues

The files form a hierarchy: projectbrief.md is the foundation, three context files depend on it, and they feed activeContext.md and progress.md. activeContext.md changes most often: it is updated after every session.

This is not a feature built into the program. Memory Bank works through instructions: you add a rule that tells the agent to read these files and keep them current. That is why the approach also works in other tools; commands and integration may differ.

Cline Memory Bank: setup in five minutes

Step by step, following the documentation:

1. Create a rules file, for example .clinerules/memory-bank.md (.cline/rules/ is also accepted). Rules are markdown files with persistent instructions. Cline also sees .cursorrules, .windsurfrules and AGENTS.md.
2. Put the Memory Bank instructions into it: the file structure and the reading and updating order. A ready-made text is on the Memory Bank page of Cline's documentation; below we give a short version of our own.
3. Ask Cline: "initialize memory bank". It will create the structure.
4. From then on start work with the phrase "follow your custom instructions" and after significant milestones say "update memory bank".

A short version of the rule that is handy to keep in a project:

## Memory Bank (project rule)

Before each task read memory-bank/activeContext.md and memory-bank/progress.md.
Read the other files only if the task concerns architecture, stack or project goals.
After significant changes update activeContext.md (no longer than 40 lines) and progress.md.
Do not copy code or logs into memory-bank: give file paths instead.

Note the difference from the "reference" text in the documentation: there the agent must read all files at the start of every task. That is reliable but expensive, as shown below.

The token price of memory

The agent sends the accumulated conversation to the model at every step. Whatever it read at the start of the task stays in context and is paid for again with every following request. The formula is simple:

memory cost = file tokens × number of requests in the task × input price.

Prices as of October 18, 2026, claude-sonnet-5-5 through the OpenAI-compatible format: input is $0.4 per 1M tokens. Suppose six files together weigh 12,000 tokens and the task makes 25 requests.

12,000 × 25 = 300,000 tokens, 0.3 × 0.4 = $0.12 per task. At 20 tasks a day that is $2.40.

If you trim memory to 3,000 tokens (only two files are read): 3,000 × 25 = 75,000 tokens, 0.075 × 0.4 = $0.03 per task, or $0.60 a day at 20 tasks.

This is an upper estimate assuming the files stay in context for all 25 requests, with no cache discount. In the OpenAI format there is no cache discount for Claude: all input is billed at the input price. For GPT models, cache reads are visible in both formats. For cheap models the numbers differ: deepseek-v4.1-flash input costs $0.013, so the same 300,000 tokens cost 0.3 × 0.013 = $0.0039. But cheaper does not mean sufficient: compare models by price, context and strength index (39 for deepseek-v4.1-flash, 48 for claude-sonnet-5-5) and check whether the model copes with the task. The current price list: GET https://api.zukko.pro/v1/models or the Models page in the dashboard.

How to keep memory from bloating

A few techniques that work regardless of provider.

Keep files short. activeContext.md should answer "what are we working on" and "what is next", not store history. Move the past into an archive outside memory-bank/.

Read selectively. Do not make the agent open all six files for every small edit. The base reading is two files, the rest on demand.

Conditional rules. Cline can enable a rule only when you work with matching files. A YAML block goes at the top of the rules file:

---
paths:
  - "memory-bank/**"
  - "docs/architecture/**"
---

A rule with such a block is applied when the current work touches the listed paths. Without conditions all rules load into every request, and as the rule library grows that wastes tokens and dilutes the agent's attention.

Context management commands. /newtask packs the plan, finished work and relevant files into a new task with a clean context window, and /smol (alias /compact) compresses the current conversation. Before switching tasks, ask for the memory to be updated, then start the new one.

Links instead of copies. In memory files give paths (src/billing/invoice.py) rather than pasting code: the agent will open the file when needed.

Rules and workflows

Memory Bank is only one kind of persistent instruction. Next to it it is worth distinguishing:

• Rules (.clinerules/): code style, constraints ("do not touch /legacy"), project structure. They load automatically, so keep them short and concrete.
• Workflows: scenarios for repeatable operations (release, migration, review). They live in the workflows/ folder of the project or global configuration and run on request, so they spend tokens only when needed. How exactly to invoke a workflow in your version, see Cline's documentation.
• Global rules in ~/.cline/rules apply to all projects, and on conflict project rules take priority.

A simple split follows: what is always needed goes into rules, what is needed sometimes goes into workflows, and what changes from session to session goes into Memory Bank. The AGENTS.md file fits if you want shared instructions for several tools; see also the article on how to write CLAUDE.md↗, the principles are the same.

Connecting the provider

To make Cline work on a gateway key, choose an OpenAI-compatible API in the provider settings and enter the Base URL https://api.zukko.pro/v1, the fetch_... key from the dashboard↗ and a model id. Details are in the documentation↗ and the article on connecting Cline↗. A separate key with a daily dollar limit protects against an accidental loop, and other ways to cut spending are in the article on reducing token spend↗.

FAQ

Do I have to create Memory Bank by hand?

No, it is enough to add the rule and ask Cline to "initialize memory bank". It creates the structure itself and you edit the contents.

Must Cline read all Memory Bank files every time?

In the reference instructions from the documentation, yes. But you can limit it to two files and read the rest on demand, which lowers token spend.

How is Memory Bank different from a README?

A README describes the project for people and rarely changes. Memory Bank holds active context and progress that are updated almost every session.

What does such memory cost?

By the formula: file tokens × number of requests in the task × input price. For 12,000 tokens, 25 requests and $0.4 per 1M that is $0.12 per task. The balance is topped up from $1 via SBP (the payment page adds an 8.5% fee), a MasterCard card or crypto.