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 gesehen besitzt ein Sprachmodell kein Gedächtnis. Es hat einen Kontext, den seine umgebende Anwendung bei jedem Aufruf vollständig neu übermittelt. Was in einer Sitzung wie Kontinuität erscheint, ist tatsächlich eine bei jedem Schritt wiederholte Übergabe des gesamten Gesprächsverlaufs.

Diese Architektur hat eine Konsequenz, die sich erst im produktiven Einsatz zeigt. Sobald ein Sprachmodell aus dem Editor-Chat in eine Kommandozeile wandert und dort Aufgaben über Stunden bearbeitet, wird das Kontextfenster zur knappsten Ressource des Systems. Die agentischen Kommandozeilen-Werkzeuge der Anbieter, also 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, beantworten dieselbe technische Frage: Wie verwaltet man ein knappes, flüchtiges Arbeitsgedächtnis so, dass eine längere Sitzung produktiv bleibt? Eine systematische Lektüre der sechs Codebasen, die in fünf der sechs Fälle dank Open-Source-Lizenzen offen einsehbar sind, zeigt eine bemerkenswerte Konvergenz in den Lösungsmustern und gleichzeitig fünf klar unterscheidbare Achsen, an denen die Designentscheidungen auseinanderlaufen. Dieser Beitrag legt beide Befunde nebeneinander.

Drei strukturelle Eigenschaften des Kontextfensters

Wer den Vergleich der Werkzeuge verstehen will, muss zuerst die Begrenzungen kennen, denen alle sechs Anbieter unterliegen. Sie folgen aus der Architektur der zugrundeliegenden Transformer-Modelle und sind in der Forschungsliteratur ausführlich dokumentiert.

Erste Eigenschaft: Das Kontextfenster ist 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 und es Claude-Code-Nutzern auf Max-, Team- und Enterprise-Plänen ohne Konfiguration als Standard ausgeliefert; 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, sie heben ihn nicht auf. Ein einziges Token jenseits der harten Grenze, und der API-Aufruf scheitert. Eine Erweiterung zur Laufzeit gibt es nicht.

Zweite Eigenschaft: Das Kontextfenster ist flüchtig und zustandslos. Bei jedem einzelnen Modellaufruf wird die gesamte bisherige Historie erneut übertragen, bestehend aus System-Prompt, allen Nachrichten, allen Tool-Aufrufen und allen Tool-Ergebnissen. 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, was einer Reduktion um neunzig Prozent entspricht; OpenAI gewährt automatisch fünfzig Prozent Nachlass auf wiederverwendete Eingabe-Tokens, neuere Modelle in einzelnen Fällen mehr. An der grundlegenden Mechanik ändert das nichts. Was wie Erinnerung wirkt, ist organisierte Wiederholung.

Dritte Eigenschaft: Das Kontextfenster altert. Lange vor dem harten Limit fällt die Antwortqualität ab. Der Begriff Context Rot wurde 2025 in einem technischen Bericht von Chroma Research für genau dieses Phänomen geprägt; 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 beziffert in den Best Practices für Claude Code den Eintrittsbereich für die hauseigenen Million-Token-Modelle: zwischen 300.000 und 400.000 Tokens, also rund dreißig bis vierzig Prozent Füllstand. Empirische Auswertungen auf dem LoCoMo-Benchmark von Snap Research, der Konversationen mit durchschnittlich 9.000 Tokens und bis zu 35 Sitzungen umfasst, zeigen modellübergreifend, dass selbst Long-Context-LLMs deutlich hinter menschlicher Leistung zurückbleiben, sobald die Sitzung lang wird. Die These des Artikels lautet daher nicht, dass ein größeres Fenster nichts brächte; sie lautet, dass es das Problem zeitlich verschiebt, statt es zu lösen.

Die Aufmerksamkeit des Modells verteilt sich auf mehr Tokens, alter Ballast zieht das Modell vom aktuellen Fokus weg, die Wahrscheinlichkeit steigt, dass relevante Anweisungen ignoriert werden. Die Forschung spricht hier von Instruction Omission, dem stillen 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. Es befolgt sie 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. Wie genau die sechs Werkzeuge das tun, ist der eigentliche Gegenstand des Vergleichs.

Vier konvergente Grundmuster

Eine systematische Lektüre der sechs Codebasen fördert eine überraschende Übereinstimmung zutage. Trotz unterschiedlicher Programmiersprachen, unterschiedlicher Anbieter und unterschiedlicher Designphilosophien teilen die Werkzeuge vier Grundmuster. Diese Konvergenz ist kein Zufall. Sie ist das Ergebnis derselben Constraints, die alle Anbieter zwingen, denselben Lösungsraum zu erkunden.

Das erste Muster lautet Auswahl statt Vollständigkeit. Keines der untersuchten Werkzeuge kopiert wahllos Dateien in den Kontext. Jedes trifft Entscheidungen darüber, welche Instruktionsdateien geladen werden, welche Tool-Ergebnisse erhalten bleiben, welche Memory-Ebenen aktiv sind. Auswahl ist die erste Verteidigungslinie gegen Context Rot. Gemini CLI klassifiziert eingelesene Dateien beispielsweise 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.

Das zweite Muster ist die hierarchische Discovery von Instruktionsdateien. Alle sechs CLIs suchen ihre Projektregeln, gleich ob diese CLAUDE.md, AGENTS.md, GEMINI.md, QWEN.md oder copilot-instructions.md heißen, auf dem Pfad von der Projektwurzel bis zum aktuellen Arbeitsverzeichnis. Spezifischere Regeln in Untermodulen überlagern allgemeinere. Wer in einem Monorepo arbeitet, bekommt automatisch das passende Regelwerk. Das ist ein Industrie-Konsens, keine Erfindung eines einzelnen Anbieters. Die Begründung liegt auf der Hand: Eine flache, projektweite Regeldatei wäre für große Codebasen zu grobkörnig.

Das dritte Muster ist die Priorisierung von User-Inhalten vor Tool-Ausgaben. Wenn der Kontext knapp wird, verwerfen alle Werkzeuge zuerst alte Tool-Ergebnisse, nicht die Nachrichten des Nutzers. Die Logik dahinter ist klar: Was ein Nutzer geschrieben hat, drückt Absicht aus. Was ein Tool ausgegeben hat, lässt sich bei Bedarf reproduzieren, indem das Tool erneut aufgerufen wird. Eine User-Nachricht hingegen ist nicht reproduzierbar; sie ist authentischer Bestandteil der Sitzung.

Das vierte Muster ist die strukturierte Wiederverankerung nach Kompaktierung. Sobald eine Verdichtung stattgefunden hat, werden wichtige Zustandsdaten explizit an den neuen Kontext angehängt: Datei-Anhänge, aktive Pläne, eingeschaltete Tools, Verbindungen zu externen Diensten, Hook-Ergebnisse vom Sitzungsstart. Der neue Kontext ist also kein loses Summary, sondern ein rekonstruiertes Arbeitsbild. Claude Code ist hier besonders ausgeprägt, hängt nach jeder Kompaktierung 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 neue Werkzeuge in Minuten statt in Wochen. Sie sind das, was Entwurfsmuster für die Objektorientierung waren: kein Algorithmus, sondern ein Vokabular.

Fünf Achsen architektonischer Unterscheidung

So eindeutig die Konvergenz ist, so klar bleiben die Unterschiede. Fünf Achsen sind besonders folgenreich für die Wahl eines Werkzeugs. Sie werden im Folgenden mit den präzisen Werten benannt, die sich aus der Quelltextlektüre belegen lassen.

Achse 1: Aggressivität der Kompaktierung

Diese Achse wird durch den Schwellwert ausgedrückt, ab dem das Werkzeug eine Verdichtung anstößt, bezogen auf den Füllstand des Kontextfensters. Die Spreizung ist beachtlich. Gemini CLI fängt früh an, bei einem Füllstand von 50 Prozent. Qwen Code, das auf einer Abspaltung der Gemini-Codebasis aufsetzt, wartet bis 70 Prozent. Copilot CLI verteilt die Aufgabe auf zwei Schwellen: bei 80 Prozent läuft eine asynchrone Kompaktierung im Hintergrund, bei 95 Prozent eine blockierende Notbremse, die den Aufruf so lange anhält, bis die Verdichtung abgeschlossen ist. Codex wartet bis 90 Prozent des konfigurierten Kontextfensters. Bemerkenswert ist die interne Mechanik: 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; stattdessen laufen mehrere überlappende Ebenen, deren Eingriffstiefe von chirurgisch bis vollständig reicht.

Jede Schwelle ist ein Kompromiss. Frühe Verdichtung kostet zusätzliche LLM-Aufrufe, weil die Zusammenfassung selbst ein Modellaufruf ist. Späte Verdichtung lebt länger im Bereich des Context Rot und riskiert Qualitätseinbußen kurz vor dem Eingriff. Die Wahl zwischen 50 und 95 Prozent ist eine Wahl zwischen Token-Ökonomie und Antwortstabilität.

Achse 2: Tiefe des Memory-Systems

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. Damit ist Memory bei Copilot kein freier Markdown-Klumpen, sondern ein nach Thema, Fakt und Provenance getrennter Datensatz.

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

Achse 3: Sub-Agent-Infrastruktur

Sub-Agenten dienen der Isolation von Kontext. Eine Teilaufgabe wird an einen Tochteragenten delegiert, der ein eigenes Fenster bekommt, 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 in dieser Dimension sparsam ausgestattet.

Achse 4: Observability

Hier 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. Jede Kompaktierung lässt sich damit messen, protokollieren und auditieren. Anzahl der Tokens vor und nach der Verdichtung, Anzahl entfernter Nachrichten, generiertes Summary, GitHub-Request-Trace, das alles ist Bestandteil der Eventstruktur. Wer ein Werkzeug in produktive Pipelines integrieren oder Audit-Trails führen muss, ist auf solche Infrastruktur angewiesen. Die übrigen Werkzeuge sind in dieser Dimension deutlich weniger ausgestattet.

Achse 5: Extension-System

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, eigene Validierung, eigene 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 statt einem ereignisbasierten Modell.

Sechs Architekturen im Einzelnen

Auf der Grundlage der vier Muster und fünf Achsen lässt sich nun jede einzelne CLI charakterisieren.

Claude Code behandelt Kompaktierung als Gradient mit vier Ebenen, die sich in der Eingriffstiefe unterscheiden. Auf der untersten Ebene arbeitet eine Mikro-Kompaktierung, die einzelne ältere Tool-Ergebnisse durch einen Platzhaltertext ersetzt. Sie ist chirurgisch, lässt den Gesprächsverlauf unberührt und greift kontinuierlich während der Sitzung. Eine zweite Ebene schneidet bei Bedarf einzelne ältere Nachrichten-Blöcke ab, bevor die Mikro-Kompaktierung läuft. Eine dritte Ebene ist die Session-Memory-Kompaktierung, die als nachgelagerter Hook nach jeder Modellantwort Memory-Einträge aus der Sitzung extrahiert und in einer eigenen Datei ablegt. Die vierte Ebene ist die klassische, vollständige Kompaktierung 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 kein einzelner Schnitt sein soll, sondern eine Familie gestaffelter Eingriffe.

Codex behandelt die Session als sauber definierten Zustandsraum. Die automatische Kompaktierung fährt bis 90 Prozent des Kontextfensters; das User-Fenster, also der jüngste Bereich der Konversation, bleibt mit 20.000 Tokens am Ende erhalten, damit der aktuelle Arbeitskontext geschützt ist. Das Memory-System ist als separates Subsystem konzipiert. Memory-Einträge werden über einen eigenen Endpunkt zur Trace-Zusammenfassung an einen Subagent gegeben, 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 verteilt die Aufgabe auf vier spezialisierte Dienste, die zusammenarbeiten, und leistet sich ein eigenes Utility-Modell für die Erstellung der Zusammenfassungen. Dieses Modell trägt intern den Namen chat-compression-2.5-flash-lite. Es ist eine kleinere, kostengü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. Die Kompaktierung startet aggressiv bei 50 Prozent Füllstand, was zusätzliche LLM-Aufrufe erzeugt, aber das Hauptmodell weit unterhalb des Context-Rot-Bereichs hält.

Qwen Code ist eine Abspaltung von Gemini CLI durch Alibaba. Die Codebasis übernimmt große Teile der Gemini-Logik. Die Kompaktierungsschwelle liegt allerdings höher, bei 70 Prozent, und der Compressor sitzt an einer anderen Stelle der Pipeline. Eine genauere Analyse zeigt, dass die Verdichtung den Memory-Pfad umgeht, der bei Gemini regulär durchlaufen wird. 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 versteht sich als Hausmeister-Werkzeug. Es führt ein starkes Overflow-Management mit einem Puffer von 20.000 Tokens, das die Kompaktierung dann auslöst, wenn der Kontext tatsächlich überzulaufen droht, statt sich an einer festen prozentualen Schwelle zu orientieren. Instruktionsdateien werden träge geladen, der Code ist flach hierarchisch organisiert, die Overflow-Logik ist transparent und gut nachvollziehbar. Ein persistentes Memory-System fehlt vollständig. Wer Einfachheit und Nachvollziehbarkeit priorisiert, findet hier die geringste Komplexität.

Copilot CLI ist von allen sechs Werkzeugen am nächsten an dem, was die Forschungspapiere von 2025 und 2026 fordern. Die Kompaktierung läuft 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. Die Kompaktierung emittiert strukturierte Events mit umfangreichen Metriken. Ein Hook-System gestattet das Einklinken von externer Logik vor und nach jeder Kompaktierung. 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 sowohl die Default-Schwellwerte als auch die Eventstruktur der Kompaktierung als typisierte Schnittstelle veröffentlicht sind.

Memory-Subsysteme: vom Markdown zur Datenbank

Eine eigene Betrachtung verdient das Memory-Subsystem, weil hier die Architekturen am stärksten auseinanderlaufen und gleichzeitig der größte Forschungsabstand liegt.

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, in einem Pull Request reviewen. Der Nachteil ist ebenso offensichtlich: Eine flache Datei ist 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, kein Versäumnis. Wer Memory braucht, legt entsprechende Markdown-Dateien selbst im Repository ab und verweist im Prompt darauf. Die Konsequenz ist, dass jede Sitzung mit dem fängt, was im Repo dokumentiert ist, nicht mit dem, was das Werkzeug intern gespeichert hat. 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, 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, also die Auswahl von Memory-Einträgen auf der Grundlage der aktuellen Aufgabenabsicht, fehlt; der Abruf läuft über Pfade, Namespaces und semantische Ähnlichkeit, nicht über Goal States. Kausale und temporale Strukturen zwischen Memory-Einträgen sind auf Zeitstempel beschränkt; einen expliziten Ereignisgraph gibt es nicht.

Sub-Agenten als Kontext-Isolation

Sub-Agenten sind das zweite große Feld architektonischer Differenz. Die Grundidee ist einfach: Statt eine Teilaufgabe im selben Kontext zu erledigen und dadurch das Hauptfenster zu belasten, übergibt der Hauptagent die Aufgabe an einen Tochteragenten, der mit einem leeren Fenster startet, die Aufgabe erledigt und ausschließlich das Ergebnis zurückgibt. Der Zwischendialog, die Tool-Calls, die 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.

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, 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 in einer eigenen Phase nach Sitzungsende. 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 in dieser Achse weniger. Sub-Agenten gibt es, aber sie sind nicht das tragende Designprinzip wie bei Copilot oder 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.

Erstens fordern die Papers einen intent-sensitiven Abruf: Memory wird nach der Absicht der aktuellen Aufgabe ausgewählt, nicht nach Pfad oder Zeitstempel. Zweitens verlangen sie explizite kausal-temporale Strukturen, also Beziehungen zwischen Fakten, die nicht in Prosa versteckt bleiben, sondern als gerichteter Graph adressierbar sind. Drittens beschreiben sie lernende Policies für das Einfügen und Löschen von Memory-Einträgen, die aus dem Erfolg späterer Schritte lernen, statt feste Heuristiken zu verwenden. Viertens fordern sie 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. Was die CLIs heute beherrschen, ist die ökonomische Effizienz des Kontextmanagements. Was sie noch nicht beherrschen, ist seine Tiefe.

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. Multi-Session-Konsistenz über Stunden und Tage gelte als weitgehend ungelöst. Selektives Vergessen sei die schwierigste der offenen Herausforderungen. 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, beansprucht damit aber ausdrücklich keine Gesamtlösung, sondern dokumentiert seine Grenzen transparent.

Konsequenz für die Werkzeugwahl

Aus der Analyse folgen vier Schlüsse, die für die Praxis tragen.

Erstens ist die Frage „Welches CLI ist das beste?" die falsche Frage. Es gibt keine universelle Antwort, sondern passende Werkzeuge für passende Anforderungen. Wer in einer CI/CD-Pipeline arbeitet, wird Copilot wegen seiner Observability oder Codex wegen seiner Reproduzierbarkeit bevorzugen. Wer interaktiv und stark konfiguriert entwickelt, findet bei Claude Code die größte Flexibilität. Wer Memory als abfragbare Datenbank über viele Projekte hinweg braucht, hat genau eine Wahl. Wer Einfachheit über alles stellt, ist bei OpenCode richtig.

Zweitens trägt die Pattern-Sprache. Wer Trim, Summarize, Persist, Prune verstanden hat, dazu hierarchische Discovery, Sub-Agent-Isolation, Post-Compact-Rehydration und Hook-basierte Extension, der beurteilt das nächste auf den Markt kommende Werkzeug nicht mehr über Demo-Videos, sondern über das Lesen der relevanten Codepfade. Das ist der eigentliche Ertrag eines architektonischen Vergleichs: ein Vokabular, das die Halbwertszeit der einzelnen Implementierungen überdauert.

Drittens, und das ist die unangenehmste Erkenntnis für Anbieter wie Anwender, ersetzt auch das beste Memory-System keine strukturierte Planung der Arbeit selbst. Die Werkzeuge liefern Mechanik. Den Plan, was zu bauen ist, in welcher Reihenfolge und mit welchen Kriterien für die Annahme, liefert weiterhin der Mensch. Das Kontextfenster ist eine Ressource. Was darin steht, bleibt eine Frage der Methode.

Viertens schließlich ist die Lücke zwischen Forschung und Implementierung eine Chance. Die nächste Generation von CLIs wird nicht über das Hauptmodell entschieden, sondern darüber, welche Anbieter zuerst intent-sensitiven Abruf, kausal-temporale Memory-Strukturen und lernende Policies in produktive Form bringen. 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.