Überleben des Faltenvorgangs: Eine Leiter für langlaufende Agentensitzungen und Kompression

Bergsteiger tragen die Ausrüstung für eine Expedition nicht den Berg hinauf; sie lagern sie dort ein. Ein langer Aufstieg wird in Etappen unterteilt, wobei jede Etappe mit dem ausgestattet wird, was für die nächste benötigt wird. Alles, was nicht gebraucht wird, bleibt unten und steht zur Verfügung, falls die Gruppe zurückkehren muss, wird aber niemals weiter nach oben transportiert. Was den Gipfel erreicht, ist das, was jede Etappe überlebt hat – also das, was man dort zurückließ.

Ein Kontextfenster verhält sich genauso. Die Kapazität ist festgelegt, der Weg hingegen nicht, und früher oder später muss etwas zurückgelassen werden.

Durch das Vorlagern von Informationen ergibt sich bereits eine Regel für die Hilfsmittel der Agenten: Das Cache darf niemals ungültig gemacht werden. Der stabile Teil soll erhalten bleiben, während Änderungen erst am Ende vorgenommen werden. Diese Regel behandelt eine Sitzung jedoch wie ein Standbild, obwohl Sitzungen eine zeitliche Dimension haben. Jede Sitzung altert. Das Gespräch entwickelt sich weiter, bis das Fenster voll ist und gefaltet werden muss.

Ein Falten verkleinert das Fenster – das ist der mechanische Aspekt. Der Preis dafür ist weniger offensichtlich, da das Falten dazu führt, dass der Cache ungültig wird. Man zahlt einmal dafür, alles, was übrig bleibt, wird neu geschrieben, und die Sitzung geht weiter. Dennoch ist die Ungültigkeitssetzung nur ein Nebenproblem. Entscheidend ist vielmehr die Auswahl dessen, was überhaupt erhalten bleibt. Eine gute Komprimierung bedeutet nicht nur Löschung: Sie verdichtet eine Historie zu einer Form, aus der der Agent weiterarbeiten kann. Zudem faltet sich eine lange Sitzung nicht nur einmal. Sie faltet sich, arbeitet weiter, faltet sich erneut – und früher oder später entsteht durch weitere Faltungen eine weitere Faltung.

Das verändert die Fragestellung zur Planung. Zu fragen, wann komprimiert werden soll, ist weniger wichtig als zu fragen, was nach wiederholten Falzvorgängen übrig bleibt und was bis dahin verloren gegangen ist. Die Zeit ist ein Kostenelement, denn jede Invalidation wird berechnet. Die Komprimierungsqualität ist ein Identitätsaspekt, denn sie bestimmt, ob die Sitzung danach noch dieselbe ist wie zu Beginn. Aus diesen beiden Gründen gehört die Komprimierung an die Spitze der Prioritätenliste und nicht an den unteren Rand.

Wo sich die Rechnung ansammelt

Jeder Anfrage wird in zwei Abrechnungsbereiche unterteilt. Einer ist das Präfix, das von Runde zu Runde erhalten bleibt. Der andere ist der Schwanz, der ständig wächst.

Das Präfix enthält die Systemanweisungen, Tool-Definitionen, den stabilen Repository-Kontext sowie die Regelfilter. Es wird nur einmal geschrieben, im Cache gespeichert und später zu einem kleinen Bruchteil des ursprünglichen Preises wieder ausgelesen. Seine Größe bleibt unverändert.

Der „Schwanz“ umfasst alles, was danach folgt: Dialoge, Aufrufe von Tools, deren Ergebnisse, Denkblöcke sowie Unterschiede. Er wächst ständig weiter.

Doch die Erweiterung selbst ist nicht das Problem – das wiederholte Aufladen schon. Eine neue Nachricht wird nicht allein übertragen. Das System sendet den entsprechenden Präfix erneut, berechnet die für das Lesen gespeicherte Gebühr sowie die Prämie für das Schreiben des neuen Inhalts, und der gesamte „Schwanz“ wird bei jeder dieser Lesevorgänge mit übertragen. Somit sind 150.000 Token des „Schwanzes“ keine inaktiven Werte, die einfach nur im Speicher liegen; sie werden bei jeder Anfrage erneut berechnet, unabhängig davon, ob das Modell sie für die nächste Frage benötigt. Die alte Historie wird im Grunde für die gesamte Dauer der Sitzung lizenziert.

In einem Fenster von 200.000 Token ist bereits ein großer Teil belegt. Je nach verwendetem System und weiteren Faktoren kann der tatsächlich freie Bereich für die Arbeit auf etwa 7.500 bis 15.000 Token schrumpfen.

Caches verfallen ebenfalls. Die Aktivität aktualisiert die Gültigkeitsdauer, was bedeutet, dass eine Pause dazu führen kann, dass der folgende Schritt zu einem „kalten“ Schreiben wird. Die Zeit, die ein Mensch zum Nachdenken benötigt, stellt eine verborgene Kostenfaktor für den Cache dar, der von niemandem angegeben wird.

So betrachtet ist auch das Komprimieren des „Schwanzes“ eine Operation am Cache. Eine einmalige Invalidierungsgebühr wird gegen das Ende der anhaltenden Mietgebühr eingetauscht. Das ist der gesamte Handel – und es existieren günstigere Möglichkeiten, bevor man darauf zurückgreift.

Eine Leiter mit fünf Schritten

Gegen das Wachstum des „Schwanzes“ gibt es fünf Maßnahmen. Es handelt sich dabei weniger um Alternativen als um Sprossen: Je höher man klettert, desto stärker wird die vorhandene Historie gestört.

Erster Schritt: Erstelle es niemals. Begrenze die Ausgabe auf das Werkzeug. Anthropics Texteditor-Werkzeug unterstützt max_characters und seine Web-Suche unterstützt max_uses. Codex begrenzt die Ausgaben einzelner Werkzeuge standardmäßig auf etwa 10.000 bis 16.000 Tokens, bevor sie in die Komprimierungsrechnung einfließen. Eine diszipliniertere Variante ist das Ausschneiden: Behalte Anfang und Ende bei und schneide den Mittelteil heraus – unter der Annahme, dass die Art und Weise, wie ein Befehl beginnt und wo er endet, wichtiger sind als der Inhalt dazwischen. Die Schwäche besteht darin, bereits vor dem Wissen darüber, was wichtig ist, zu kürzen, und ein Stacktrace, der den relevanten Frame fehlt, ist schlimmer als keiner.

Stufe zwei: speichern Sie es. Wenn die gesamte Beobachtung nicht benötigt wird, tragen Sie sie nicht weiter. Wenn das Ergebnis eines Tools einen Größenlimit überschreitet, schreibt das System es auf die Festplatte und hinterlässt eine Referenz. Das vollständige Artefakt bleibt erhalten, während der aktuelle Kontext nicht mehr existiert. Dies unterscheidet sich von der Trunkierung, da nichts weggeworfen wird. Ein Build-Log mit 500.000 Zeilen kann auf der Festplatte gespeichert bleiben, während der Kontext nur seinen Pfad, Metadaten oder einen suchbaren Index enthält – ein natives Such- oder Lese-Tool holt anschließend nur den relevanten Teil ab. Behalten Sie das Artefakt bei und entfernen Sie die Beobachtung. So wird der Speicher vom Kontext sauber getrennt, sodass die Informationen dauerhaft erhalten bleiben, ohne später zusätzliche Kosten zu verursachen.

Das Problem ist, dass das Harness die Möglichkeit bieten muss, den Inhalt erneut zu finden. Das Auslagern lohnt sich nur, wenn der Agent in der Lage ist, das Gespeicherte zu durchsuchen, zu lesen und zu verstehen; ohne das wird ein Kontextüberschuss durch ein Dateisystem voller nicht wiederabrufbarer Daten ersetzt.

Die Übereinstimmungen zwischen den Harnesses sind bemerkenswert. Claude Code speichert jeden Tool-Ergebnis, das größer als etwa 100.000 Zeichen ist, auf der Festplatte und gibt eine Vorschau sowie einen Pfad zurück, während Hermes ebenfalls eine Obergrenze von 100.000 Zeichen pro Ergebnis anwendet. Beide machen eine Ausnahme für das Lesetool, denn ein ausgelagertes Lesen liefert einen Pfad, den der Agent nur noch einmal lesen würde – ein Lesen, das auf einen bereits gelesenen Pfad ausgelagert wird, und so weiter in Endlosschleifen. Solche Schleifen sind leicht zu verfallen. Das einzige Tool, dessen Zweck darin besteht, Inhalte zurückzubringen, ist das, das auf keinen Fall auslagern darf.

Stufe drei: Halten Sie es draußen. Übertragen Sie die Aufgabe an einen Unteragenten. Ausgestattet mit den integrierten Werkzeugen des Harness kann er Dateien lesen, durch Protokolle blättern und das Repository überprüfen, wodurch ein umfangreicher privater Kontext erstellt wird, ohne dass etwas davon in den Überwachungsstrom des übergeordneten Systems gelangt. Sobald die Aufgabe erledigt ist, wird sein Arbeitsfenster verworfen und nur der Rückgabewert übertragen. Die Anbieter von Harnessen haben dies zu einer der am weitesten verbreiteten Funktionen in diesem Jahr gemacht.

Es gibt eine Grenze, denn Erkundung ist sicherer als das Ändern von Dingen. Ein Worker, der die falschen Dateien liest, zwingt lediglich zu einem Neustart. Ein Worker, der die falschen Dateien bearbeitet, hinterlässt Schäden, nachdem sein Kontext verschwunden ist – daher ist es wichtig, welchem Modell Änderungen anvertraut werden. Alte Armeen veranschaulichen das: Späher waren schnelle, austauschbare Personen, die vorausgeschickt wurden, da das Beobachten kostengünstig ist und der Bericht überprüft werden kann, während die eigentlichen entscheidenden Aktionen den besten Kommandeuren anvertraut wurden, weil sie nicht rückgängig gemacht werden können. Derselbe Aufteilungsschlüssel gilt auch hier. Übertragen Sie die Erkundung auf einen günstigen, austauschbaren Kontext, bewahren Sie das stärkste Modell für den Schritt auf, der die Welt verändert, und lassen Sie den Elternkontext bei der Überprüfung mitwirken. Der Elternkontext zahlt für die Antwort und nicht für die Untersuchung.

Stufe vier: Ersetzen Sie es durch einen Zeiger. Wenn der Inhalt bereits dauerhaft gespeichert ist – sei es als Datei, Artefakt, generierter Bericht oder Ausgaberesultat – benötigt das Gespräch lediglich einen Verweis darauf. Wieder darauf zuzugreifen bedeutet, dorthin zu gehen, wo sich das Material befindet, anstatt es mitzunehmen. Anthropics Speichermittel tut genau das, und OpenAI unterstützt ein ähnliches Verhalten durch Funktionsaufrufe. Der teure Gesprächszustand wird so zu einem günstigen Verweis auf einen dauerhaften Zustand. Es gibt jedoch eine Einschränkung: Die Ersparnisse gelten nur solange der zugrunde liegende Inhalt außerhalb des Fensters bleibt. Sobald er erneut gelesen wird, wird er wieder zum aktiven Inhalt und fängt sofort wieder an, Kosten zu verursachen.

Stufe fünf: Entfernen Sie sie danach. Löschen, komprimieren oder falten. Nur diese Stufe macht das bereits Gecachte ungültig. Ein Zug wird damit verbracht, die angesammelte Historie gegen etwas Kleineres einzutauschen, in der Hoffnung, dass der nächste Zug davon ausgehen kann. Die vollständige Transkription kann auf der Festplatte verbleiben, doch der aktuelle Kontext ist anders.

Von hier an wird die Ökonomie zu einer Wette. Übertreffen die Kosten, die durch das Vermeiden von „Miete“ für den Rest der Sitzung eingespart werden, die Kosten für das Neuverfassen der Historie jetzt? Frühzeitiges Komprimieren bedeutet, einen effektiven Cache wegzuwerfen, der Hunderte günstiger Züge ermöglicht hätte. Spätes Komprimieren bedeutet, dass bereits für eine große Menge an Historie „Miete“ gezahlt wurde, während das Modell in der Zwischenzeit vielleicht bereits schlechter darin geworden ist, diese zu nutzen. Die meisten Diskussionen über lange Sitzungen beginnen mit dieser Frage – doch das sollte nicht der Fall sein. Die fünf Stufen in der Reihenfolge:

1. Erstellen Sie es niemals: Stoppen Sie das Wachstum der Historie bereits an der Quelle.
2. Es preisgeben: Die umfangreiche Beobachtung entfernen und das Artefakt behalten.
3. Es draußen lassen: Die Untersuchung in einen anderen Kontext verschieben.
4. Darauf verweisen: Eine günstige Referenz im Gespräch hinterlassen.
5. Später löschen: Komprimieren oder zusammenfalten und mit dem Verlust leben.

Der günstigste Kontext ist kein komprimierter Kontext – es ist ein Kontext, der nie hätte existieren müssen.

Werkzeugsets als Wette darüber, wo Kosten anfallen

Es spielt eine Rolle, wo sich die Definition eines Werkzeugs befindet. Definitionen nehmen den Präfix ein – eine feste Gebühr, die einmal geschrieben und gespeichert wird. Die Ergebnisse nehmen den Nachsatz ein – eine variable Gebühr, die ständig entsteht. Die Wahl eines Werkzeugsets ist daher eine Wette darauf, welche Zone die Kosten für Informationen tragen soll. Wenige Werkzeuge bedeuten einen kleinen Präfix, aber mehr Rohbeobachtungen im Nachsatz; viele Werkzeuge bedeuten zusätzliche Präfix-Token, die aufgewendet werden müssen, um kleinere, strukturiertere Beobachtungen zu erhalten.

Terminus 2 ist das Extrem der Schlichtheit: ein headloses Terminal, das auf dem Unix-Glauben beruht, dass ein allgemeines Werkzeug unbegrenzt zusammengesetzt werden kann. Codex wird oft mit ihm in einen Topf geworfen, was nur teilweise gerechtfertigt ist. Sein natives Prefix ist keineswegs klein – es enthält etwa 20 ständig verfügbare Tools, ein Mehr-Agenten-Set sowie eine Kombination aus Versionen v1 und v2. Durch Aufschieben, das Indizieren von MCP- und Connector-Tools in einer Suchmaschine sowie deren Laden, wenn sie benötigt werden, wird Überlast vermieden. Codex setzt seine Minimalisierung tatsächlich auf den „Schwanz“ des Tool-Ökosystems. apply_patch veranschaulicht dies, da ein kurzer Diff tausende von Zeichen eines umgeschriebenen Files ersetzt und Obergrenzen für die Ausgabe jedes Tools verhindern, dass Rohdaten anwachsen. Beide Ansätze führen auf ähnliche Ergebnisse, aber über unterschiedliche Wege: Terminus 2 hält das Prefix klein, Codex hält den „Schwanz“ klein.

Claude Code und Hermes verwenden einen größeren Teil des Präfixes für spezialisierte Tools, die strukturierte Beobachtungen statt roher Daten zurückgeben. Wenn man LSP, Planungsmodus, Worktrees und Cron mitzählt, erreicht Claudes Katalog über 40 Einträge, während Hermes etwa 55 erreicht – diese sind in Toolsets für Terminal, Dateien, Speicher, Fähigkeiten, Delegation und mehr gegliedert. Das Muster besteht darin, dass Grep Übereinstimmungen statt einer ganzen Datei zurückgibt: ein etwas größeres Präfix, um Tausende von Tokens am Ende zu vermeiden.

Die zu ziehende Vergleich ist also nicht bezüglich der Anzahl der Tools. Es geht darum, ob zusätzliche Ausgaben für Präfixe ausreichen, um das Wachstum am Ende zu verlangsamen und so das Falten hinauszuzögern. Es handelt sich dabei um denselben Kompromiss zwischen Vorabbereitung und Just-in-Time, nur auf einer höheren Ebene angewandt. Anthropic formuliert dies klar: Tool-Definitionen können bei Bedarf entdeckt werden, anstatt bei jeder Anfrage mitgeliefert zu werden. Claude Code erreicht dies mithilfe eines ToolSearch-Mechanismus, der die Namen der aufgeschobenen Tools sichtbar lässt und die vollständigen Schemata zurückhält, bis das Modell danach fragt; dieser Mechanismus aktiviert sich automatisch, wenn die MCP-Tool-Definitionen etwa 10 Prozent des Kontextfensters ausmachen. Selbst die Sortierung wird gewählt, um das Präfix zu schützen, da die alphabetische Sortierung den Definitionsblock zwischen den Anfragen bytegenau unverändert lässt und somit cachebar macht. Das Präfix ist so konzipiert, dass es unabhängig von seiner Größe „warm“ bleibt.

Die Achse behält ihre Nützlichkeit bei, doch ihre Rolle ändert sich. Sie entscheidet nicht darüber, ob komprimiert werden soll. Sie bestimmt vielmehr, wie viel Geschichte zunächst angesammelt wird. Und diese Geschichte ist nicht homogen. Suchergebnisse lassen sich oft erneut ableiten, Entscheidungen hingegen nicht. Ein Dateipfad kann rekonstruiert werden, während der Grund für die Ablehnung eines Ansatzes möglicherweise nicht bekannt ist. Je länger eine Sitzung andauert, desto teurer wird es, diese beiden Arten von Speicher zu verwechseln.

Delegation als Speichergrenze

Delegation zeichnet sich dadurch aus, dass sie Geschichte loswird, ohne den Cache des Elternteils zu berühren – und das ist wertvoller als ein Rabatt auf die Ausführung von Arbeiten. Ein Subagent hat sein eigenes Kontextfenster. Es kann einen riesigen „Schwanz“ entwickeln, das Fenster füllen, intern komprimieren und anschließend verschwinden – ohne ein einziges Wort der Geschichte des Elternteils umschreiben zu müssen.

Eine gängige Annahme muss korrigiert werden. Es ist verlockend, sich ein Forken desselben Modells vorzustellen, bei dem ein Kind den angesammelten „Tail“ des Elternteils zusammen mit dessen „Prefix“ erbt. Die überprüfbaren Implementierungen tun dies meist nicht. Claude Code, OpenCode, Codex und Hermes starten jeweils separate Worker-Kontexte – nicht eine Kopie des gesamten „Tails“ des Elternteils. Einige können den Worker auf ein anderes Modell setzen; Codex verwendet zu Startzeit eine Modell-Überlagerung, während Claude Code es jedem Subagenten ermöglicht, zwischen Sonnet, Opus oder Haiku zu wählen. Das ist jedoch nicht universell gültig, und der Delegate von Hermes verfügt nicht über eine direkte Möglichkeit, das Modell zu wechseln. Was zwischen den Systemen übertragen wird, ist der separate Kontext – nicht die Modellwahl.

Dies weist auf etwas Größeres als einfaches Forken hin. Der „Kind-Prozess“ kann weggeworfen werden: Er kann vierzig Dateien lesen, Protokolle durchscannen und eine Namenskonvention festlegen, wobei der gesamte Kontext verschwindet, während ein Absatz zurückkommt. Delegation dient als Gedächtnisgrenze. Der Elternteil weist eine Aufgabe zu und gibt an, was benötigt wird – was einer im Voraus durchgeführten Kompression entspricht, da der Arbeiter weiß, wer seine Ausgabe lesen wird und welche Entscheidung diese unterstützen muss. Wenn ein Unteragent zurückkehrt, überprüft der Elternteil in der Regel das Ergebnis. Dies erfordert nur wenige Schritte und ist klug.

Die Komprimierung erfolgt rückwärts, nachträglich. Sie muss für einen noch nicht existierenden Leser zusammenfassen und mögliche anschließende Fragen vorwegnehmen. Die vorherige Kompression hat den Vorteil, dass ein bekannter Leser vorhanden ist. Dies führt zu einem Budgetierungsprinzip: Man budgetiert für das, was zurückkommt, nicht für den Prozess selbst. Ein Worker kann Hunderttausende von Tokens verbrauchen, ohne dass einer davon zu Elternspeicher wird. Der zurückgegebene Text wird hingegen zum Speicher. Vierhundert Tokens einer Antwort landen im „Tail“ des Elternelements und werden bei jeder späteren Aktion berechnet; dadurch kann ein roher Diff über eine lange Sitzung hinweg teurer sein als ein teurer Worker, der nur einen einzigen nützlichen Satz zurückgibt. Die Untersuchung ist vorübergehend, die Antwort gehört zur Geschichte – und diese Antwort muss wiederum einer weiteren Verarbeitungsschleife standhalten.

Was die Plattformen bieten

Die Modellplattform bestimmt, wie viel von dieser Infrastruktur das Harness selbst aufbauen muss.

Anthropic bietet zwei Arten von Hilfe für unterschiedliche Probleme an. Die erste, clear_tool_uses_20250919, ist präzise. Wenn der Prompt eine Schwellenwert erreicht (standardmäßig 100.000 Eingabetoken, wobei die drei neuesten Tool-Nutzungen beibehalten werden), löscht sie die alten Tool-Ergebnisse auf dem Server und ersetzt sie an jeder Stelle durch einen Platzhalter. Die Option clear_at_least verteilt die Kosten für die Löschung, indem sie eine Mindestmenge zur Löschung vorschreibt. Die zweite Art, compact_20260112, ist die aufwändigere Variante: Es erfolgt eine vollständige Zusammenfassung auf Serverseite, wodurch eine neue Version des Gesprächs erstellt wird, anstatt in das Bestehende eingegriffen zu werden.

Claude Code ist ein gutes Fallbeispiel, da selbst das Harness, das von dem Unternehmen hergestellt wird, das diese Primitiven bereitstellt, seine schwereren /compact-Versionen auf seiner eigenen Seite zu koordinieren scheint. Die Unterstützung dafür stammt aus Community-Reverse-Engineering-Arbeiten, die auf einer einzigen öffentlich zugänglichen GitHub-Quelle zurückgehen, und nicht aus Anthropics öffentlicher Dokumentation. Die Leichtbereinigung findet auf dem Server statt, während die Entscheidung darüber, welcher Konversationszustand beibehalten wird, vom Client gesteuert wird.

OpenAI konzentriert sich auf die Komprimierung. Sein Endpunkt /v1/responses/compact gibt einen verschlüsselten, undurchsichtigen Blob zurück, den der Client unverändert weiterleitet, teils um einen Angriff durch Eingabe-Manipulationen zu verhindern, bei dem eine manipulierte Zusammenfassung spätere Schritte beeinflussen könnte. Es gibt dort nichts, was einer präzisen Bereinigung entspricht, weshalb Codex selbst die Größe der Tool-Ausgabe verwalten muss. Unter beiden Pfaden gibt es außerdem einen groben Notfallplan: Falls das Fenster dennoch überläuft, wirft Codex den ältesten Historieeintrag weg und versucht es erneut.

DeepSeek bietet nur sehr begrenzte Möglichkeiten zur Kontextverwaltung. Das Caching von Präfixen auf Serverseite senkt zwar die Kosten, löst aber das Problem des festen Fensters nicht – daher muss jede dort verwendete Lösung den gesamten Kompressionsprozess selbst übernehmen. Die offizielle DeepSeek-Lösung erstellt einen solchen Prozess und tut dies, ohne etwas zu zerstören: Die abgelegten Ereignisse bleiben im Protokoll erhalten und können weiterhin abgerufen werden. Eine getestete Drittanbieter-Terminal-Schnittstelle überspringt diese Arbeit und komprimiert nicht proaktiv.

Wichtig ist nicht die Qualität des Komprimierungsendpunkts einer einzelnen API, sondern wer dafür verantwortlich ist, zu entscheiden, was erhalten bleibt. Hermes ist ein aufschlussreicher Grenzfall, da er mehrere Anbieter umfasst und nicht davon ausgehen kann, dass einer von ihnen die richtigen Primitiven anbietet. Deshalb verwendet er als Grundlage einen eigenen Client-seitigen Kompressor mit zwei Schwellenwerten: 50 Prozent gemäß seiner eigenen Token-Verrechnung und 85 Prozent nach einer groberen Überprüfung auf Gateway-Ebene, die Sessions erfasst, die zwischen den Abläufen wachsen, während niemand zuschaut. Sobald der aktuelle Anbieter etwas Besseres bietet, wird dies zurückgestellt.

Das ist ein solides allgemeines Design. Die Verwaltungssoftware sollte standardmäßig die Komprimierung übernehmen, da sie Informationen besitzt, die ein Server möglicherweise niemals zu Gesicht bekommt, und diese an die Plattform weitergeben, wenn diese dies verdient hat. Unabhängig davon, wer die Komprimierung durchführt, bleibt die Frage dieselbe: Was ist akzeptabel zu vergessen?

Zurück zum Lager

Alles oben Genannte ging davon aus, dass die Sitzung niemals endet. Doch Sitzungen enden tatsächlich. Laptops werden geschlossen, Prozesse beenden sich, CI-Aufgaben werden abgeschlossen, und jemand gibt /resume ein in der Erwartung, genau da weitermachen zu können, wo man aufgehört hat.

Es handelt sich um den einfachsten Befehl überhaupt – doch er führt zur teuersten Art der Sitzungsfortsetzung. Er besteht aus sieben Zeichen inklusive Schrägstrich, ähnelt /help oder /clear, erfordert keine Argumente, keine Bestätigung und stößt auf keinerlei Widerstand. Nichts daran gibt seinen Preis preis, und die Benutzeroberfläche ist so gestaltet, dass das Wiederaufnehmen des Vorgangs wie selbstverständlich erscheint.

Das Gespräch kann wiederhergestellt werden, der Cache jedoch nicht. Eine wieder aufgenommene Sitzung ist kein pausierter Prozess. Das System spielt den Transkriptinhalt vom Datenträger ab und erstellt erneut die Nachrichtengeschichte, sodass der Dialog aus dem Speicher wiederhergestellt wird – während das „warme Präfix“ dies nicht kann. Daraus ergeben sich zwei unterschiedliche Kosten für die Wiederherstellung.

Erstens geht es um Geld. Der Präfix-Cache von Anthropic hält standardmäßig fünf Minuten lang, oder eine Stunde, wenn die erweiterte Version erworben wurde, und wird nur durch Aktivität aktualisiert. Ein „Resume“ ist die extreme Form der Inaktivität – eine Phase, in der überhaupt kein Prozess läuft. Der zuvor günstige Präfix wird wieder völlig unbrauchbar, und im nächsten Schritt muss der vollen Preis bezahlt werden, um ihn neu aufzubauen. Der teuerste Fall ist das Wiederherstellen einer Sitzung, die mehrere Tage lang gelaufen ist – ein guter Grund, Sitzungen sorgfältig zu verwalten.

Der zweite Punkt betrifft die Informationen. Wenn die Transkriptgröße größer ist als das verfügbare Fenster, muss das System dieses möglicherweise zusammenfalten, bevor eine neue Aktion ausgeführt werden kann. Dabei handelt es sich um eine besonders riskante Zusammenfaltung, da die Kompression bereits stattfindet, bevor geklärt werden konnte, was wirklich wichtig ist. Eine Einschränkung, die eine Entscheidung aus früheren Schritten erklärt, könnte in der Transkriptversion vorhanden sein, in der komprimierten Version jedoch fehlen. Das System setzt seine Arbeit mit einem kleineren Fenster sowie einer glaubwürdigen Historie fort – nicht unbedingt mit der Historie, die die früheren Entscheidungen sinnvoll gemacht hat.

Alles, was einer Zusammenfassung standhält, überlebt auch eine Wiederherstellung – und das ist der entscheidende Grund für eine langlebige Zustandsverwaltung. Projektbezogene Regeln können erneut aus der Festplatte geladen werden, Dateien neu gelesen, eine To-Do-Liste neu erstellt und ein generierter Build-Log gespeichert sowie referenziert werden. Eine Entscheidung, die nur im Gespräch existiert, hat keine externe Quelle. Wenn sie nur deshalb bestehen blieb, weil sie in der Transkription festgehalten wurde, muss sie bei der Wiederherstellung erneut eingeführt werden; falls die Zusammenfassung sie entfernt hat, kann sie endgültig verloren gehen.

Daher bezieht sich die Rangfolge sowohl auf Langlebigkeit als auch auf Kosten. Vom robustesten bis zum zerbrechlichsten: Zustände, die rekonstruiert werden können, langlebige externe Zustände, aktuelle Gesprächszustände und anschließend vorübergehende Beobachtungen. Je niedriger eine Position ist, desto mehr ist sie einer Zusammenfassung ausgesetzt.

Zwei Arten, wie das Zusammenfassen fehlschlägt

Das Falten versagt auf zwei Arten. Der offensichtliche Fall ist leicht zu erkennen: Die Kompression funktioniert, anschließend füllt sofort eine große Menge an Ausgabeinhalten das Fenster wieder auf, die Verarbeitungskonfiguration komprimiert erneut, es tritt wieder dieselbe Ausgabe auf, und der Zyklus wiederholt sich – wie das Abpumpen von Wasser aus einem Boot, während gleichzeitig ein Loch darin gebohrt wird. Claude Code gibt die Wiederholungsversuche auf, anstatt Ressourcen in einem endlosen Loop zu verbrauchen, und verfügt über eingebaute Logik, um festzustellen, dass es stecken geblieben ist und keinen Fortschritt macht. Das ist das richtige Verhalten, doch der Loop selbst ist ein Zeichen dafür, dass die falsche Vorgehensweise angewandt wird. Idealerweise wechselt der Agent zu einem anderen Ansatz, anstatt denselben Tool erneut zu verwenden. Wenn ein einzelnes zu großes Datei die Kompression ständig erzwingt, ist ein niedrigerer Schwellenwert keine Lösung. Stattdessen sollten nur eine begrenzte Anzahl von Zeilen gelesen, die Suche in einem eingeschränkten Umfang durchgeführt, auf langlebige Ausgabeinhalte gezielt oder die Datei an einen Subagenten weitergeleitet werden, dessen Arbeitsfenster ersetzt werden kann. Jedes Mal, wenn die Anpassung der Komprimierung beginnt, fragen Sie, ob die Lösung drei Ebenen höher liegt oder in einem völlig anderen Ansatz besteht.

Der langsame Versagen ist subtiler. Bei der Komprimierung gehen Informationen verloren, und lange Sitzungen komprimieren niemals nur einmal. Sie komprimieren, arbeiten, komprimieren erneut, arbeiten weiter, komprimieren nochmals: Zusammenfassungen aufeinandergetürmt.

Mehrfache Faltungen

Eine erste Zusammenfassung kann hervorragend sein und dennoch zu einer schlechten dritten führen. Der zweite Zusammenfasser sieht niemals die ursprünglichen Daten, nur die von dem ersten Zusammenfasser gewählte Darstellung. Der dritte sieht weder die ursprünglichen Daten noch die Darstellung, sondern nur das Urteil des zweiten bezüglich des Urteils des ersten. Man sieht, welche Auswirkungen das auf Fakten und Gründe hat. Die erste Zusammenfassung könnte „Der Ansatz B wurde gewählt“ beibehalten. Die zweite könnte „B ist die aktuelle Implementierung“ beibehalten. Die dritte könnte „Die Implementierung verwendet B“ beibehalten. Jede Aussage ist wahr, doch warum Ansatz A abgelehnt wurde, ist verschwunden. Das System hat nicht die Entscheidung verloren – es hat jedoch das verloren, was die Entscheidung verständlich machte, und das ist der spezifische Schaden, der durch mehrfache Zusammenfassungen entsteht.

Was sollte erhalten bleiben

Über verschiedene Systeme hinweg konvergieren strukturierte Zusammenfassungen in etwa auf dieselben Kategorien:

• Intention: Was soll erreicht werden?
• Zustand: Was wurde gelernt oder geändert?
• Arbeit und To-Do-Listen: Was wurde erledigt und was bleibt noch zu tun?
• Offene Punkte: Welche Fragen sind noch ungelöst, eingeschränkt oder werden noch abgewogen?

Die Bezeichnungen variieren je nach Tool, doch die Struktur wiederholt sich, was darauf hindeutet, dass sie dem kleinstmöglichen praktischen Zustand entspricht, den eine Sitzung beibehalten muss. Mehrere Tools fügen außerdem Schritte zur Wiederherstellung von Dateien hinzu, damit der Arbeitsbereich nach einem Zusammenfalten neu geladen werden kann.