Ich halte gute Sessions mit Cline nicht künstlich am Leben. Ich starte lieber neu.
Das klingt kontraintuitiv. Da steckt doch schon so viel Kontext drin. Das fühlt sich effizient an. In der Praxis kippt das aber schnell. Je länger ein Chat läuft, desto mehr Altlasten schleppt er mit. Frühere Zwischenstände. Veraltete Entscheidungen. Halbfertige Ideen, die schon wieder verworfen wurden.
Dazu kommt der Preis. Mit zwei, drei Prompts komme ich für rund 2 Dollar erstaunlich weit. Beim vierten und fünften bin ich schon bei 10. Und ab da explodieren die Kosten, weil jede Runde den gesamten bisherigen Kontext mitbezahlt.
Meine Regel ist deshalb simpel: Wenn eine Session breit wird, teuer wird oder anfängt zu schwimmen, starte ich frisch. Neuer Task. Klare Aufgabe. Weniger Ballast. Das ist kein Notbehelf. Das ist die vernünftigere Arbeitsweise.
Das Problem mit dem Neustart
Der Haken ist offensichtlich. Sobald ich sauber neu starte, ist auch der implizite Projektkontext weg.
Dann beginnt die übliche Wiederholungsarbeit. Worum geht es im Projekt? Welche Architektur steht schon? Was habe ich gestern entschieden? Welche Stellen sind heikel? Was ist schon erledigt, was noch offen?
Genau diese Amnesie überbrückt die Memory Bank.
Was die Memory Bank eigentlich ist
Der Name klingt größer, als die Sache ist. Cline bekommt damit kein echtes Langzeitgedächtnis. Es ist im Kern ein geordneter Satz Markdown-Dateien im Projekt. Eine Arbeitsakte für den Agenten.
Bei Cline besteht die Struktur aus Dateien wie projectbrief.md, activeContext.md, techContext.md oder progress.md. Dazu kommt .clinerules für projekt- oder workflow-spezifische Regeln. Ein konkretes Beispiel: Meine activeContext.md für diesen Blog enthält drei Zeilen dazu, welche Artikel gerade in Arbeit sind, welche Entscheidung zuletzt bei der Seitenstruktur gefallen ist, und wo ein bekannter Stolperstein liegt. Nicht mehr.
Darin landet bewusst nicht alles. Genau das wäre wieder kontraproduktiv. Nur die Dinge, die sonst zwischen zwei Sessions verloren gehen: Projektziel, Architekturentscheidungen, aktueller Stand, nächste Schritte, Eigenheiten.
Das ist nicht spektakulär. Aber es ist praktisch.
Wer pflegt die Memory Bank?
Das Überraschende: nicht ich. Cline macht das selbst.
In den .clinerules steht die Anweisung, die Memory Bank nach relevanten Änderungen zu aktualisieren. Und das Modell hält sich daran. Wenn sich während einer Session die Architektur ändert, ein neuer Stack dazukommt oder eine Entscheidung fällt, schreibt Cline die betroffenen Dateien am Ende der Aufgabe eigenständig fort.
Das ist interessant zu beobachten. Der Agent entscheidet selbst, was projektrelevant genug ist, um festgehalten zu werden, und was nur Rauschen war. Meistens trifft er das erstaunlich gut. Manchmal schreibt er zu viel rein, manchmal zu wenig. Aber die Grundtendenz stimmt.
Mein Part beschränkt sich auf zwei Dinge: Ab und zu drüberlesen, ob die Einträge noch stimmen. Und eingreifen, wenn etwas veraltet ist. Veraltete Einträge sind schlimmer als keine Einträge, weil der Agent dann selbstbewusst in die falsche Richtung läuft.
Kein Cline-Feature, eher ein Muster
Interessant finde ich, dass der Ansatz inzwischen über Cline hinausgewachsen ist. In der Community tauchen Memory-Bank-Strukturen für Cursor auf, für Claude Code gibt es CLAUDE.md, und manche lagern das Ganze über MCP-Server aus, damit der Projektordner sauber bleibt.
Das zeigt, dass das Problem real ist. Und dass die Lösung nicht in besseren Modellen liegt, sondern in besserem Projektmanagement für Agenten. Wer mit Coding-Agenten ernsthaft arbeitet, muss Projektwissen irgendwann bewusst auslagern. Sonst fängt man ständig wieder von vorne an.
Was es nicht löst
Trotzdem lohnt es sich, ab und zu reinzuschauen. Wenn sich Quatsch in die Memory Bank einschleicht, läuft der Agent beim nächsten Start selbstbewusst in die falsche Richtung. Das schadet dann mehr, als es hilft. Und sie löst auch nicht das Kostenproblem einer laufenden Session. Wer beim sechsten Prompt schon bei 20 Dollar ist, hat das gleiche Problem mit oder ohne Memory Bank.
Die Memory Bank ist nicht die Lösung für zu viel Kontext. Sie ist der Grund, warum ich mir weniger Kontext leisten kann.
Was bleibt
Je länger ich mit Cline arbeite, desto weniger glaube ich an den einen perfekten Megachat, der ein Projekt von Anfang bis Ende trägt. Ich glaube an kleinere, klarere Sessions mit sauberem Startpunkt. Und daran, dass Projektwissen einen festen Ort braucht, der nicht aus Chat-Verlauf besteht.
Ich starte Cline lieber frisch, weil das günstiger und oft besser ist. Und ich pflege die Memory Bank, damit ich mir diesen Reset leisten kann.