Die Architektur des Vergessens

Sprachmodelle wirken auf ihre Nutzer wie kollegiale Gesprächspartner: Sie antworten in der ersten Person, beziehen sich auf frühere Aussagen, scheinen Code zu verstehen und Absichten zu erfassen. Diese Wirkung ist eine sorgfältig konstruierte Illusion. Technisch besitzt ein Sprachmodell kein Gedächtnis. Es hat einen Kontext, den seine umgebende Anwendung bei jedem Aufruf vollständig neu übermittelt, und die Kontinuität einer Sitzung entsteht allein daraus, dass sie den gesamten Gesprächsverlauf bei jedem Schritt erneut übergibt.

Diese Architektur hat eine Konsequenz, die sich erst im produktiven Einsatz zeigt. Das Kontextfenster wird zur knappsten Ressource des Systems, sobald ein Sprachmodell aus dem Editor-Chat in eine Kommandozeile wandert und dort Aufgaben über Stunden bearbeitet. Die agentischen Kommandozeilen-Werkzeuge der Anbieter beantworten alle dieselbe technische Frage: Wie verwaltet man ein knappes, flüchtiges Arbeitsgedächtnis so, dass eine längere Sitzung produktiv bleibt? Gemeint sind Claude Code von Anthropic, Codex von OpenAI, Gemini CLI von Google, Qwen Code von Alibaba, OpenCode aus der Open-Source-Gemeinschaft und Copilot CLI von GitHub. Fünf der sechs Codebasen sind dank Open-Source-Lizenzen offen einsehbar, und wer sie nebeneinander liest, findet überall dieselben vier Lösungsmuster wieder, dazu fünf Achsen, an denen die Designentscheidungen dann doch auseinanderlaufen.

Was das Kontextfenster begrenzt

Alle sechs Anbieter unterliegen denselben Begrenzungen, die aus der Architektur der zugrundeliegenden Transformer-Modelle folgen und in der Forschungsliteratur ausführlich dokumentiert sind.

Hart begrenzt. In den aktuellen Spitzenmodellen ist eine Million Tokens, was rund 750.000 englischen Wörtern entspricht, der neue Standard. Anthropic hat das Million-Token-Fenster für Claude Opus 4.6 und Sonnet 4.6 im März 2026 generell verfügbar gemacht. Claude-Code-Nutzer auf Max-, Team- und Enterprise-Plänen bekommen es ohne Konfiguration als Standard. OpenAI bietet die Million in GPT-5.5, in der Codex CLI begrenzt auf 400.000 Tokens. Google liefert sie in Gemini 2.5 Pro, Alibaba in Qwen 3.5-Plus. Ältere und kleinere Modelle wie Claude Sonnet 4.5 bleiben bei 200.000 Tokens, was bis 2025 der Industrie-Standard war. Trotz dieser Vergrößerung skaliert die Attention-Operation der Transformer-Architektur quadratisch mit der Sequenzlänge: Doppelter Kontext bedeutet vierfachen Rechenaufwand. Sparse-Attention- und State-Space-Verfahren dämpfen diesen Effekt, heben ihn aber nicht auf, und ein einziges Token jenseits der harten Grenze lässt den API-Aufruf scheitern, weil sich zur Laufzeit nichts nachlegen lässt.

Flüchtig und zustandslos. Bei jedem einzelnen Modellaufruf überträgt die Anwendung die gesamte bisherige Historie erneut: System-Prompt, alle Nachrichten, alle Tool-Aufrufe und alle Tool-Ergebnisse. Anbieterseitiges Prompt-Caching, das stabile Präfixe der Konversation zwischenspeichert, senkt die Token-Kosten für wiederholte Übermittlungen erheblich. Anthropic berechnet für Cache-Reads nur ein Zehntel des regulären Input-Preises. OpenAI gewährt automatisch fünfzig Prozent Nachlass auf wiederverwendete Eingabe-Tokens, bei neueren Modellen in einzelnen Fällen mehr. An der grundlegenden Mechanik ändert das nichts. Der Eindruck von Erinnerung entsteht weiterhin durch organisierte Wiederholung.

Alterung. Lange vor dem harten Limit fällt die Antwortqualität ab. Den Begriff Context Rot prägte 2025 ein technischer Bericht von Chroma Research für genau dieses Phänomen. Die Autoren testeten 18 Frontier-Modelle, darunter GPT-4.1, Claude Opus 4 und Gemini 2.5, und beobachteten den Effekt bei jedem einzelnen. Anthropic hat den Begriff inzwischen in die eigene Dokumentation übernommen, und die Best Practices für Claude Code beziffern den Eintrittsbereich für die hauseigenen Million-Token-Modelle mit 300.000 bis 400.000 Tokens, also bei dreißig bis vierzig Prozent Füllstand. Der LoCoMo-Benchmark von Snap Research umfasst Konversationen mit durchschnittlich 9.000 Tokens und bis zu 35 Sitzungen. Empirische Auswertungen darauf zeigen modellübergreifend, dass selbst Long-Context-LLMs deutlich hinter menschlicher Leistung zurückbleiben, sobald die Sitzung lang wird. Ein größeres Fenster verschiebt das Problem zeitlich, ohne es zu lösen.

Die Aufmerksamkeit des Modells verteilt sich auf mehr Tokens, und alter Ballast zieht es vom aktuellen Fokus weg. Damit ignoriert das Modell eher relevante Anweisungen, was die Forschung Instruction Omission nennt, das stille Weglassen von Anweisungen, ohne dass das Modell darauf hinweist. Eine Arbeit von Distyl AI aus dem Jahr 2025 zeigt, dass selbst die besten getesteten Frontier-Modelle bei 500 parallelen Anweisungen nur noch eine Genauigkeit von rund 68 Prozent erreichen. Die Anweisungen passen problemlos ins Fenster, das Modell sieht sie und befolgt trotzdem nicht alle.

Aus diesen drei Eigenschaften folgt eine technische Notwendigkeit. Eine agentische CLI muss ihren Kontext aktiv bewirtschaften: ältere Inhalte verdichten, irrelevante Tool-Ausgaben verwerfen, wichtige Erkenntnisse in dauerhafte Dateien auslagern, vor jeder neuen Aufgabe gezielt rekonstruieren, was relevant ist. Was das auf der Anwenderseite bedeutet, steht im Feldbericht zum Kontextmanagement. Wie genau die sechs Werkzeuge das tun, ist der eigentliche Gegenstand des Vergleichs.

Was alle sechs Werkzeuge gleich lösen

Die sechs Codebasen stimmen an vier Stellen überein, obwohl Programmiersprachen, Anbieter und Designphilosophien auseinandergehen. Die Konvergenz ergibt sich aus denselben Constraints, die alle Anbieter zwingen, denselben Lösungsraum zu erkunden.

Ein gemeinsames Muster ist Auswahl statt Vollständigkeit. Keines der untersuchten Werkzeuge kopiert wahllos Dateien in den Kontext. Jedes entscheidet, welche Instruktionsdateien es lädt, welche Tool-Ergebnisse es behält, welche Memory-Ebenen aktiv sind. Auswahl ist die vorderste Verteidigungslinie gegen Context Rot. Gemini CLI etwa klassifiziert eingelesene Dateien in vier Stufen, die intern FULL, PARTIAL, SUMMARY und EXCLUDED heißen, und entscheidet pro Datei, wie viel davon im Kontext landet. Claude Code räumt in der Mikro-Kompaktierung gezielt alte Tool-Resultate ab, ohne den Gesprächsverlauf anzutasten.

Ebenso verbreitet ist die hierarchische Discovery von Instruktionsdateien. Alle sechs CLIs suchen ihre Projektregeln auf dem Pfad von der Projektwurzel bis zum aktuellen Arbeitsverzeichnis, gleich ob diese Regeln CLAUDE.md, AGENTS.md, GEMINI.md, QWEN.md oder copilot-instructions.md heißen. Spezifischere Regeln in Untermodulen überlagern allgemeinere. Wer in einem Monorepo arbeitet, bekommt automatisch das passende Regelwerk. Dieser Konsens gilt in der ganzen Industrie und geht auf keinen einzelnen Anbieter zurück. Eine flache, projektweite Regeldatei wäre für große Codebasen zu grobkörnig.

Dazu kommt die Priorisierung von User-Inhalten vor Tool-Ausgaben. Wenn der Kontext knapp wird, verwerfen alle Werkzeuge zuerst alte Tool-Ergebnisse und behalten die Nachrichten des Nutzers. Was ein Nutzer geschrieben hat, drückt Absicht aus. Eine Tool-Ausgabe lässt sich bei Bedarf reproduzieren, indem das Tool erneut aufgerufen wird, eine User-Nachricht dagegen nicht, weil sie authentischer Bestandteil der Sitzung ist.

Zuletzt die strukturierte Wiederverankerung nach Kompaktierung. Danach hängt das Werkzeug wichtige Zustandsdaten explizit an den neuen Kontext an: Datei-Anhänge, aktive Pläne, eingeschaltete Tools, Verbindungen zu externen Diensten und Hook-Ergebnisse vom Sitzungsstart. Was dabei herauskommt, ist ein rekonstruiertes Arbeitsbild. Bei Claude Code ist das besonders ausgeprägt: Nach jedem Eingriff hängt es Datei-Attachments, den Zustand des Plan-Modus, aktive Skills sowie Tool- und Agenten-Deltas wieder an.

Diese vier Muster bilden zusammen eine informelle Pattern-Sprache des Kontextmanagements. Die Begriffe Trim, Summarize, Persist und Prune fassen ihre Operationen zusammen. Wer sie benennen kann, beurteilt ein neues Werkzeug innerhalb von Minuten. Sie sind für das Kontextmanagement, was Entwurfsmuster für die Objektorientierung waren: ein Vokabular.

Wo sich die sechs Werkzeuge unterscheiden

Trotz der Konvergenz bleiben klare Unterschiede. Fünf Achsen sind besonders folgenreich für die Wahl eines Werkzeugs. Die genannten Werte lassen sich aus der Quelltextlektüre belegen.

Kompaktierungsschwellen: Gemini CLI bei 50, Codex bei 90 Prozent

Diese Achse misst sich am Füllstand des Kontextfensters, ab dem das Werkzeug verdichtet. Die Werte liegen weit auseinander: Gemini CLI fängt früh an, bei einem Füllstand von 50 Prozent, während Qwen Code, das auf einer Abspaltung der Gemini-Codebasis aufsetzt, bis 70 Prozent wartet. Copilot CLI verteilt die Aufgabe auf zwei Schwellen: Bei 80 Prozent läuft eine asynchrone Kompaktierung im Hintergrund. Bei 95 Prozent greift eine blockierende Notbremse, die den Aufruf anhält, bis die Verdichtung abgeschlossen ist. Codex wartet bis 90 Prozent des konfigurierten Kontextfensters. Codex erlaubt zwar, das automatische Token-Limit pro Modell explizit zu konfigurieren, klemmt diesen Wert intern aber stets auf maximal 90 Prozent des Kontextfensters. Claude Code arbeitet ohne festen prozentualen Trigger. Dort laufen mehrere überlappende Ebenen, deren Eingriffstiefe von chirurgisch bis vollständig reicht.

Jede Schwelle ist ein Kompromiss. Früh zu verdichten kostet zusätzliche LLM-Aufrufe, weil die Zusammenfassung selbst ein Modellaufruf ist, während späte Eingriffe länger in der Context-Rot-Zone leben und Qualitätseinbußen kurz davor riskieren. Die Wahl zwischen 50 und 95 Prozent ist eine Wahl zwischen Token-Ökonomie und Antwortstabilität.

Memory: Markdown-Datei bei Claude Code, SQLite bei Copilot CLI

Das Spektrum reicht weit. OpenCode verzichtet vollständig auf persistentes Memory. Was eine Session erarbeitet hat, lebt nur in den Dateien fort, die der Nutzer explizit anlegt. Claude Code, Codex, Gemini und Qwen nutzen je eine flache Markdown-Datei in einem definierten Pfad: bei Claude Code unter ~/.claude/.../memory/, bei Codex in einem Verzeichnis namens memories, bei Gemini und Qwen in einer projekt- oder benutzerweiten GEMINI.md beziehungsweise QWEN.md. Copilot CLI hingegen führt zwei SQLite-Datenbanken im Hintergrund, kombiniert sie mit Vector-Embeddings und Volltextsuche und macht persistentes Memory zu einer eigenen Session-Capability mit strukturierten Berechtigungs-Anfragen. Jede Memory-Speicherung läuft dort durch einen Berechtigungs-Gate, der drei Felder verlangt: Thema, Fakt und Quellennachweise. Memory ist bei Copilot damit ein nach Thema, Fakt und Provenance getrennter Datensatz.

Die Bandbreite reicht von der Abwesenheit eines Memory-Systems bis zu einem ausgewachsenen Retrieval-System mit Provenance-Feldern. Das ist die deutlichste Differenz im Vergleich. Wer Memory nur als Notiz im Repo braucht, hat fünf Werkzeuge zur Wahl, für Memory als abfragbare Datenbank über viele Sessions hinweg bleibt genau eines.

Sub-Agenten: Delegation bei Claude Code, Fleet-Dispatcher bei Copilot CLI

Sub-Agenten dienen der Isolation von Kontext. Der Hauptagent delegiert eine Teilaufgabe an einen Tochteragenten mit eigenem Fenster, das nach Abschluss verfällt. Das schützt den Hauptkontext vor Aufblähung, weil das Detailwissen der Teilaufgabe nicht ins Hauptgespräch zurückfließt. Nur das Ergebnis kommt zurück. Claude Code bietet hier ein einfaches Delegations-Werkzeug. Copilot CLI fährt mit einem Fleet-Dispatcher, der parallele Sub-Agenten orchestriert, sowie mit einem dedizierten, kleineren Subagent-Modell und expliziten Tiefenlimits, die verhindern, dass eine Aufgabe sich rekursiv ins Unendliche schraubt. Codex nutzt Sub-Agenten unter anderem für die Memory-Konsolidierung in einer eigenen Phase nach Sitzungsende. OpenCode und Qwen sind auf dieser Achse sparsam ausgestattet.

Observability: strukturierte Events und OpenTelemetry in Copilot CLI

Auf dieser Achse liegt eine der größten Differenzen. Copilot CLI emittiert strukturierte Events wie session.compaction_start und session.compaction_complete, hat OpenTelemetry-Unterstützung und bietet einen preCompact-Hook für externe Beobachter. Jeder Eingriff lässt sich damit messen und protokollieren. Zur Eventstruktur gehören die Anzahl der Tokens vor und nach der Verdichtung, die Anzahl entfernter Nachrichten, das generierte Summary und der GitHub-Request-Trace. Wer ein Werkzeug in produktive Pipelines integrieren oder Audit-Trails führen muss, ist auf solche Infrastruktur angewiesen. Die übrigen Werkzeuge bieten hier deutlich weniger.

Hooks und Erweiterungspunkte in Claude Code und Copilot CLI

Hook-Punkte wie sessionStart, preToolUse, subagentStart oder preCompact machen aus einem geschlossenen Werkzeug eine Plattform. Sie sind die moderne Form von Erweiterungspunkten und erlauben es Teams, eigene Governance, Validierung und Logik in den Agenten-Loop einzuhängen. Claude Code und Copilot CLI sind hier am reichsten ausgestattet. Codex bietet spezifische, aber weniger orchestrierbare Erweiterungspunkte. Gemini, Qwen und OpenCode bleiben sparsamer. Sie überlassen Erweiterungen weitgehend dem Konfigurationsmechanismus, ein ereignisbasiertes Modell gibt es dort kaum.

Die sechs Werkzeuge im Einzelnen

Mit den vier Mustern und fünf Achsen lässt sich jede einzelne CLI charakterisieren.

Claude Code: Kompaktierung in vier Ebenen

Claude Code behandelt Kompaktierung als Gradient mit vier Ebenen, die sich in der Eingriffstiefe unterscheiden. Auf der untersten Ebene ersetzt ein chirurgischer Eingriff einzelne ältere Tool-Ergebnisse durch einen Platzhaltertext. Er lässt den Gesprächsverlauf unberührt und greift laufend. Darüber schneidet eine Ebene bei Bedarf einzelne ältere Nachrichten-Blöcke ab, bevor die Mikro-Ebene arbeitet. Als weitere Ebene extrahiert die Session-Memory-Kompaktierung nach jeder Modellantwort als nachgelagerter Hook Memory-Einträge aus der Sitzung und legt sie in einer eigenen Datei ab. Am Ende der Staffelung steht der klassische, vollständige Eingriff mit anschließender Rehydration aller Zustandsdaten. Diese Architektur ist die elastischste der sechs, gleichzeitig die mit der höchsten inneren Komplexität. Sie folgt der Idee, dass Kompaktierung eine Familie gestaffelter Eingriffe sein soll.

Codex: 90-Prozent-Schwelle und geschütztes User-Fenster

Codex behandelt die Session als sauber definierten Zustandsraum. Automatisch verdichtet Codex bis 90 Prozent des Kontextfensters. Das User-Fenster mit dem jüngsten Bereich der Konversation bleibt mit 20.000 Tokens erhalten, damit der aktuelle Arbeitskontext geschützt ist. Das Memory-System ist als separates Subsystem konzipiert. Codex gibt Memory-Einträge über einen eigenen Endpunkt zur Trace-Zusammenfassung an einen Subagent, der in einer eigenen Phase nach Sitzungsende daraus dauerhafte Memory-Dateien konsolidiert. Reproduzierbarkeit ist das erkennbare Designziel: Initial-Kontext, Kompaktierungsgrenze und Memory-Operationen sind explizit und nachvollziehbar.

Gemini CLI: eigenes Utility-Modell für die Verdichtung

Gemini CLI verteilt die Aufgabe auf vier spezialisierte Dienste, die zusammenarbeiten, und leistet sich ein eigenes Utility-Modell, das die Zusammenfassungen erstellt. Dieses Modell heißt intern chat-compression-2.5-flash-lite. Es ist eine kleinere, günstigere Variante als das Hauptmodell und übernimmt ausschließlich die Verdichtung. Damit kommt Gemini der in der Forschung empfohlenen Trennung von Memory-Operationen und Hauptmodell am nächsten. Verdichtet wird aggressiv ab 50 Prozent Füllstand, was zusätzliche LLM-Aufrufe erzeugt, aber das Hauptmodell weit unterhalb des Context-Rot-Bereichs hält.

Qwen Code: Gemini-Fork mit höherer Schwelle

Qwen Code ist eine Abspaltung von Gemini CLI durch Alibaba. Die Codebasis übernimmt große Teile der Gemini-Logik. Verdichtet wird allerdings erst ab 70 Prozent, und der Compressor sitzt an einer anderen Stelle der Pipeline. Eine genauere Analyse zeigt, dass die Verdichtung den Memory-Pfad umgeht, den Gemini regulär durchläuft. Das Ergebnis ist eine moderne Architektur mit einem internen Bruch in der Integration: Was Gemini sauber trennt, läuft bei Qwen an einer Stelle wieder zusammen.

OpenCode: Overflow-Management ohne persistentes Memory

OpenCode versteht sich als Hausmeister-Werkzeug. Es betreibt ein starkes Overflow-Management mit einem Puffer von 20.000 Tokens und ohne feste prozentuale Schwelle, denn es greift erst ein, wenn der Kontext tatsächlich überzulaufen droht. Instruktionsdateien werden träge geladen. Der Code ist flach hierarchisch organisiert, die Overflow-Logik transparent und gut nachvollziehbar. Ein persistentes Memory-System fehlt vollständig. Wer Einfachheit und Nachvollziehbarkeit priorisiert, findet hier die geringste Komplexität.

Copilot CLI: SQLite-Memory, Fleet-Dispatcher und Hooks

Copilot CLI ist von allen sechs Werkzeugen am nächsten an dem, was die Forschungspapiere von 2025 und 2026 fordern. Verdichtet wird zweistufig, asynchron bei 80 Prozent und blockierend bei 95 Prozent. Persistentes Memory wird in zwei SQLite-Datenbanken mit Vector-Embeddings und Volltextsuche über mehrere Sessions hinweg verwaltet. Memory-Speicherungen sind permissionspflichtig und tragen ein eigenes Provenance-Feld, das die Quellen des gespeicherten Fakts dokumentiert. Sub-Agenten werden über einen Fleet-Dispatcher parallel orchestriert. Dabei entstehen strukturierte Events mit umfangreichen Metriken. Ein Hook-System erlaubt, externe Logik vor und nach jeder Kompaktierung einzuklinken. Der Preis dieser Reichhaltigkeit: Der Kern ist closed source. Nur das SDK ist öffentlich zugänglich. Die zentralen Algorithmen lassen sich aber aus dem frei einsehbaren SDK-Code und der dokumentierten Telemetrie ableiten, weil dort die Default-Schwellwerte und die Eventstruktur der Kompaktierung als typisierte Schnittstelle veröffentlicht sind.

Memory-Subsysteme: Markdown-Datei oder SQLite-Datenbank

Beim Memory-Subsystem laufen die Architekturen am stärksten auseinander, und gleichzeitig liegt hier der größte Forschungsabstand.

Vier der sechs Werkzeuge speichern Memory als Markdown-Datei. Claude Code, Codex, Gemini und Qwen folgen diesem Pfad. Der Vorteil ist offensichtlich: Markdown ist menschenlesbar, versionierbar und im Repository ablegbar. Ein Entwickler kann Memory-Einträge in einem normalen Texteditor lesen, im Git nachverfolgen und in einem Pull Request reviewen, nur ist eine flache Datei eben kein abfragbares System. Wer wissen will, was vor zwei Wochen über das Authentifizierungsmodul entschieden wurde, muss die Datei selbst lesen oder dem Agenten den ganzen Inhalt in den Kontext werfen.

OpenCode verzichtet auf jedes persistente Memory-System. Das ist eine bewusste Designentscheidung. Wer Memory braucht, legt entsprechende Markdown-Dateien selbst im Repository ab und verweist im Prompt darauf. Jede Sitzung beginnt also mit dem, was im Repo dokumentiert ist, denn intern speichert das Werkzeug nichts. Diese Klarheit hat ihren Preis: Es gibt keine automatisch aufgebaute Lernkurve über Sessions hinweg.

Copilot CLI geht den entgegengesetzten Weg und implementiert ein vollständiges Memory-Subsystem. Zwei SQLite-Datenbanken speichern Inhalte und Embeddings getrennt, eine Volltextsuche erlaubt klassische Stichwortabfragen, und Vector-Embeddings erlauben semantische Ähnlichkeitssuchen. Memory wird über strukturierte Berechtigungs-Anfragen geschrieben oder bewertet. Bei jeder Speicherung müssen Thema, Fakt und Quellennachweise vorliegen. Das ist näher an den Forderungen aus der Forschungsliteratur, insbesondere an Arbeiten wie MemInsight und CDMem, als alle anderen untersuchten Werkzeuge.

Allerdings ist auch dieses System nicht der Stand der Forschung. Cross-Session-Memory ist laut Dokumentation explizit experimentell. Intent-getriebener Abruf fehlt, also die Auswahl von Memory-Einträgen nach der aktuellen Aufgabenabsicht. Der Abruf läuft über Pfade, Namespaces und semantische Ähnlichkeit, ohne Goal States. Kausale und temporale Strukturen zwischen Memory-Einträgen sind auf Zeitstempel beschränkt. Einen expliziten Ereignisgraph gibt es nicht.

Sub-Agenten zur Kontext-Isolation bei Claude Code und Copilot CLI

Sub-Agenten sind neben dem Memory das andere große Feld architektonischer Differenz. Die Grundidee ist einfach: Der Hauptagent übergibt eine Teilaufgabe an einen Tochteragenten, damit sie das Hauptfenster nicht belastet. Der Tochteragent startet mit einem leeren Fenster, erledigt die Aufgabe und gibt ausschließlich das Ergebnis zurück. Zwischendialog, Tool-Calls und Detailrecherche bleiben dem Hauptkontext erspart.

Claude Code stellt dafür ein einfaches Delegations-Werkzeug bereit. Der Hauptagent kann eine Aufgabe an einen Subagenten geben, der im selben Modell mit eigenem Kontext arbeitet. Das ist konzeptuell sauber und in der Praxis nützlich, vor allem für Recherche-Aufgaben in großen Codebasen. Parallele Claude-Sessions können einander außerdem Nachrichten schicken und ihre Arbeit an einer Codebasis so abstimmen.

Copilot CLI hat den weitestgehenden Ausbau. Ein Fleet-Dispatcher kann Sub-Agenten parallel starten, ein dediziertes kleineres Modell übernimmt die Subagent-Arbeit zu geringeren Kosten, und explizite Tiefenlimits verhindern Endlosrekursionen. Damit nähert sich die Architektur den Patterns, die in der Forschung als hierarchische Multi-Agent-Systeme diskutiert werden.

Codex nutzt Sub-Agenten primär für die Memory-Konsolidierung, die nach Sitzungsende in einer eigenen Phase läuft. Diese Trennung zwischen Sitzungs-Sub-Agenten und Konsolidierungs-Sub-Agenten ist architektonisch interessant: Memory-Operationen werden aus dem heißen Pfad herausgenommen und asynchron erledigt. Das senkt die Sitzungs-Latenz, verschiebt aber das Memory-Update zeitlich.

Gemini, Qwen und OpenCode bieten bei Sub-Agenten weniger. Sub-Agenten gibt es, aber sie sind weder das prägende Designprinzip wie bei Copilot noch das tief integrierte Werkzeug wie bei Claude Code.

Forschungsstand und die Frontier-Lücke

So weit die sechs Werkzeuge auch sind, sie liegen sämtlich hinter dem zurück, was die akademische Forschung in den vergangenen achtzehn Monaten an Konzepten vorgelegt hat. Arbeiten wie MemoryOS (Oral bei EMNLP 2025), HiAgent (ACL 2025), LightMem (ICLR 2026) und Mnemis (akzeptiert bei ACL 2026, von Microsoft Research) skizzieren eine nächste Generation von Memory-Architekturen, die sich von den heutigen CLI-Implementierungen in vier Punkten unterscheidet. Die Papers fordern:

• einen intent-sensitiven Abruf: Memory wird nach der Absicht der aktuellen Aufgabe ausgewählt und nicht nach Pfad oder Zeitstempel.
• explizite kausal-temporale Strukturen, also Beziehungen zwischen Fakten, die als gerichteter Graph adressierbar sind, während Prosa sie versteckt.
• lernende Policies für das Einfügen und Löschen von Memory-Einträgen, die aus dem Erfolg späterer Schritte lernen und ohne feste Heuristiken auskommen.
• eine Sicherheitsgovernance für persistente Speicher mit Zugriffskontrolle, Audit-Trail und expliziter PII-Behandlung.

Die heutigen CLIs setzen davon Bruchstücke um. Tool-Ausgaben werden vor User-Prosa geopfert, weil sie reproduzierbar sind. Das ist ein Effizienzmerkmal, das die Forschung lobt. Memory wird selektiv geschrieben. Copilot speichert Provenance-Felder, andere nicht. Eine echte intent-getriebene Abruflogik existiert in keinem der Werkzeuge. Kausale Strukturen fehlen vollständig. Bei der ökonomischen Effizienz des Kontextmanagements sind die CLIs heute weit. Bei seiner Tiefe stehen sie am Anfang.

Die Survey „Memory in the Age of AI Agents“, im Dezember 2025 mit 47 Autoren auf arXiv veröffentlicht, kommt zu einem ähnlichen Ergebnis. Traditionelle Taxonomien wie die Trennung von Lang- und Kurzzeitgedächtnis seien unzureichend für moderne Agent-Memory-Systeme, und Multi-Session-Konsistenz über Stunden und Tage gelte als weitgehend ungelöst. Selektives Vergessen sei das schwierigste der offenen Probleme. Auch Mnemis, eines der derzeit am besten platzierten Systeme, erreicht auf dem LoCoMo-Benchmark mit GPT-4.1-mini einen Wert von 93,9 von 100 möglichen Punkten und 91,6 auf LongMemEval-S. Eine Gesamtlösung beansprucht das Paper damit ausdrücklich nicht und dokumentiert seine Grenzen transparent.

Konsequenz für die Werkzeugwahl

„Welches CLI ist das beste?“ ist die falsche Frage, eine universelle Antwort gibt es nicht, und passend ist ein Werkzeug immer nur für bestimmte Anforderungen. Wer in einer CI/CD-Pipeline arbeitet, wird Copilot wegen seiner Observability oder Codex wegen seiner Reproduzierbarkeit bevorzugen, während bei interaktiver und stark konfigurierter Arbeit Claude Code die größte Flexibilität bietet. Für Memory als abfragbare Datenbank über viele Projekte hinweg gibt es genau eine Wahl. OpenCode ist das Werkzeug für alle, die Einfachheit über alles stellen.

Die Pattern-Sprache nützt über diesen Vergleich hinaus. Wer Trim, Summarize, Persist und Prune verstanden hat, dazu hierarchische Discovery, Sub-Agent-Isolation, Post-Compact-Rehydration und Hook-basierte Extension, liest beim nächsten Werkzeug auf dem Markt die relevanten Codepfade und braucht dafür kein Demo-Video. Das Vokabular überdauert die einzelnen Implementierungen.

Am unangenehmsten für Anbieter wie Anwender: Auch das beste Memory-System ersetzt keine strukturierte Planung der Arbeit selbst. Die Werkzeuge liefern die Mechanik. Was zu bauen ist, in welcher Reihenfolge und mit welchen Kriterien für die Annahme, entscheidet weiterhin der Mensch.

Bleibt die Lücke zwischen Forschung und Implementierung. Sie ist eine Chance. Die nächste Generation von CLIs wird darüber entschieden, welche Anbieter zuerst intent-sensitiven Abruf, kausal-temporale Memory-Strukturen und lernende Policies in produktive Form bringen. Das Hauptmodell gibt dabei nicht den Ausschlag. Wer heute auswählt, sollte einkalkulieren, dass dieses Feld in zwei Jahren anders aussehen wird, ohne dass die hier vorgestellte Pattern-Sprache obsolet würde.