Ihnen gehen nicht die Tokens aus. Sie verschwenden sie. Hier ist der Unterschied.

Je länger ich mit LLMs arbeite, desto mehr befinde ich mich im ewigen Kampf zwischen ausreichendem Kontext, zu viel Kontext, Token-Verschwendung und Komprimierungsstrategien. Wenn wir uns agentische Gedächtnissysteme ansehen, erkennen wir, dass es dort mächtige Werkzeuge gibt, die dabei helfen können.

Die Erkenntnis, die bei den 19 von mir untersuchten Systemen immer wieder auftaucht, ist, dass größere Fenster das Budgetproblem eher verschärfen als lösen. Ein Fenster mit 200.000 Token schenkt nicht allen 200.000 Token die gleiche Aufmerksamkeit. Die Leistung lässt lange nach, bevor das Fenster voll ist. Der Leistungsabfall ist nicht gleichmäßig: Material in der Mitte eines langen Kontexts erhält nachweislich weniger Aufmerksamkeit als Material an den Rändern. Und die eigentliche Aufgabe des Agenten belegt einen festen Teil des Fensters, unabhängig davon, wie groß das Fenster ist – was bedeutet, dass alles andere Overhead ist, der um dasselbe Aufmerksamkeitsbudget konkurriert.

Die Systeme, die das gut handhaben, haben sich auf sechs Mechanismen geeinigt. Keiner davon ist exotisch. Einige sind peinlich einfach. Aber diejenigen, die sie auslassen, zahlen dafür.

Die sechs Mechanismen

Komprimierungsläufe

Der sichtbarste Mechanismus. Man nimmt eine lange Konversation oder ein großes Speichersegment, fasst es zusammen und ersetzt das Original durch die Zusammenfassung. MemoryOS macht das auf Segmentebene: Der Segment-Zusammenfasser feuert, wenn ein Konversationssegment eine Schwelle überschreitet, und verdichtet es zu einer kompakten Darstellung, bevor es den Arbeitskontext verdrängen kann. Die Karpathy-Pattern-Wikis (purpose.md, overview.md) machen eine Version davon auf Wissensebene: Das Wiki ist die komprimierte Form von allem, was der Agent zu einem Thema gelernt hat, und wird über Sitzungen hinweg gepflegt.

Der Nachteil ist Informationsverlust. Komprimierung ist per Definition ein verlustbehafteter Vorgang. Die Zusammenfassung erfasst, was der Zusammenfasser zum Zeitpunkt der Komprimierung als relevant eingestuft hat. Benötigt der Agent später ein Detail, das nicht als relevant eingestuft wurde, ist es weg. Das ist kein Grund, Komprimierung zu vermeiden, aber ein Grund, sie nicht als einzigen Mechanismus zu behandeln.

Es gibt einen zweiten Kostenpunkt, der leicht übersehen wird. Komprimierung ist zur Laufzeit nicht kostenlos. MemoryOS kann in einer einzigen Interaktion 20 oder mehr LLM-Aufrufe zahlen, um seine Segmentzusammenfassungen zu pflegen. Für Systeme mit hoher Interaktionsfrequenz sind das echte Betriebskosten.

Ergebnisvorschau-Kürzung

Anstatt bei jedem Abruf den vollständigen Speicherinhalt zurückzugeben, wird eine kurze Vorschau zurückgegeben und der Agent entscheidet, ob er den vollständigen Datensatz abrufen möchte. Supermemory bietet Steuerelemente für die Snippet-Länge, mit denen Aufrufer einstellen können, wie viel Text pro Ergebnis zurückkommt. Mem9 geht noch weiter: Es dekoriert Quell-Turns mit drei Umgebungsvariablen (MEM9_SOURCE_TURN_MIN_SCORE, MEM9_SOURCE_TURN_PER_MEMORY_LIMIT, MEM9_SOURCE_TURN_TOTAL_LIMIT), die Betreibern präzise Kontrolle darüber geben, wie viele Quell-Turns erscheinen und bei welcher Mindestrelevanzbewertung.

Der Nachteil ist ein zusätzlicher Tool-Aufruf. Wenn der Agent den vollständigen Inhalt benötigt, muss er explizit danach fragen. Für die meisten Suchmuster ist das der richtige Kompromiss: Der Agent bekommt genug Signal, um zu entscheiden, ob der Datensatz relevant ist, bevor er die Token-Kosten für das vollständige Lesen zahlt.

Zweistufiger Abruf

Eine spezifische und wichtige Variante der Vorschau-Kürzung. Die Suche gibt Kennungen und kurze Vorschauen zurück. Ein separater GetByID-Aufruf ruft den vollständigen Datensatz bei Bedarf ab. Mem9s MemoryRepo-Schnittstelle ist um dieses Muster herum aufgebaut: Suche und Abruf sind separate Operationen mit unterschiedlichen Token-Fußabdrücken.

Die Zahlen sprechen für sich. Zehn Treffer zu je 1.500 Token ergeben 15.000 Token, die in den Kontext eingefügt werden, unabhängig davon, ob der Agent sie nutzt oder nicht. Zweistufiger Abruf gibt 10 Kennungen und kurze Vorschauen mit insgesamt etwa 450 Token zurück und ruft dann nur die Datensätze ab, die der Agent tatsächlich benötigt. Über 20 Abrufschritte in einer Sitzung summiert sich der Unterschied auf etwa 200.000 eingesparte Token.

Das ist die billigste Disziplin, die man übernehmen kann. Sie erfordert keine architektonische Änderung des Speichers, keine zusätzlichen LLM-Aufrufe und keinen Informationsverlust. Es ist eine Entscheidung über die Abrufschnittstelle.

Zerlegen und dann abrufen

Anstatt die vollständige Benutzerabfrage an die Abrufschicht zu senden, wird sie zuerst in Unterabfragen zerlegt. SimpleMems intent-bewusster Abrufplaner zerlegt eingehende Abfragen in atomare Abrufabsichten, bevor er den Speicher trifft. GitNexus macht etwas Ähnliches mit seiner Query-Tool-Zerlegung: Komplexe Abfragen werden in gezielte Unterabfragen aufgeteilt, die jeweils einen fokussierten Teil des Speichergraphen abrufen.

Der Vorteil ist Präzision. Eine zerlegte Abfrage ruft weniger irrelevantes Material ab, was weniger Rauschen im Kontext bedeutet. Der Nachteil ist Latenz: Die Zerlegung fügt einen Planungsschritt hinzu, bevor der Abruf beginnt. Für interaktive Agenten ist das wichtig. Für Batch- oder Hintergrundagenten meist nicht.

Gestaffelter Speicher als Budgetfilter

Wenn man bereits eine gestaffelte Speicherarchitektur aufgebaut hat (Thema des Artikels letzte Woche), erhält man Budgetfilterung als Nebeneffekt. Supertmemorys Drei-Ebenen-Modell bedeutet, dass heißes, häufig abgerufenes Material in einer Ebene lebt, die kompakte, signalsstarke Ergebnisse zurückgibt. Kaltes Material befindet sich in einer Ebene, die standardmäßig nicht abgefragt wird. Hindsights Beobachtungsebene funktioniert ähnlich: Rohbeobachtungen werden nicht direkt in den Kontext eingefügt; sie werden in höhere Ebenen befördert, bevor sie zu Abrufkandidaten werden.

Der Nachteil ist die Vollständigkeit des Abrufs. Material, das nicht befördert wurde, kann relevant sein, taucht aber in einem Standard-Abrufdurchlauf nicht auf. Das ist der gleiche Kompromiss wie bei der Komprimierung, aber die Fehlerart ist anders: Anstatt Informationen durch Zusammenfassung zu verlieren, verliert man sie durch Herabstufung.

Selbstlenkende Tool-Antworten

Der am wenigsten diskutierte Mechanismus, und einer der interessanteren. Anstatt den Agenten entscheiden zu lassen, was nach einem Tool-Aufruf zu tun ist, enthält die Tool-Antwort selbst einen Hinweis darauf, was als Nächstes zu tun ist. GitNexus fügt einen ---
**Next:**-Block an Tool-Antworten an, der Folgeaktionen vorschlägt. Mem9 dekoriert Quell-Turns mit strukturierten Metadaten, die den nächsten Abrufschritt des Agenten leiten.

Der Effekt ist, dass der Agent weniger Token für die Planung zwischen Tool-Aufrufen ausgibt. Die Tool-Antwort trägt genug Struktur, um den nächsten Schritt offensichtlich zu machen. Der Nachteil ist Prompt-Engineering-Aufwand: Das Schreiben guter selbstlenkender Antworten erfordert, im Voraus zu wissen, was der Agent als Nächstes wahrscheinlich benötigt, was nicht immer möglich ist.

Der Tolaria-Grenzfall

Tolaria ist gesondert betrachtenswert, weil es den logischen Endpunkt von Budgetdisziplin in ihrer extremsten Form darstellt. ADR-0009 dokumentiert die Entscheidung, Embeddings vollständig aus dem System zu entfernen. Tolaria verwendet nur Substring-Suche. Kein Vektorindex, keine semantische Abfrage, keine Embedding-Aufrufe.

Die Begründung ist direkt: Der billigste Token ist der, den man gar nicht erst abruft. Embedding-basierte Abfrage liefert semantisch ähnliche Ergebnisse, was bedeutet, dass sie Ergebnisse liefert, die der Agent nicht explizit angefordert hat. Einige dieser Ergebnisse sind nützlich. Viele nicht. Alle kosten Tokens.

Tolarias Position ist, dass die Kosten irrelevanter, aber ähnlicher Ergebnisse, die sich über eine Sitzung anhäufen, den Nutzen des semantischen Abrufs für seinen Anwendungsfall übersteigen. Ob dieser Kompromiss für Ihr System gilt, hängt davon ab, wofür Ihr System gedacht ist. Für Systeme, in denen Abfragen präzise und strukturiert sind (Codenavigation, Dokumentsuche nach Kennung), ist Tolaria's Position vertretbar. Für Systeme, in denen Abfragen vage und explorativ sind, bricht das Entfernen von Embeddings den Abruf auf eine Weise, von der man sich nur schwer erholt.

Der Wert des Tolaria-Falls liegt nicht darin, dass man es kopieren sollte. Er liegt darin, dass er die Kosten des semantischen Abrufs auf eine Weise sichtbar macht, die die meisten Systeme nicht tun.

Der Fall gegen reine Komprimierungssysteme

Mehrere der 19 Systeme verlassen sich auf Komprimierung als ihren primären oder einzigen Budgetmechanismus. Die Fehlermodi sind erwähnenswert.

Der erste ist, dass die Zusammenfassung Details verloren gehen, die zum Zeitpunkt der Komprimierung nicht als relevant eingestuft wurden, später aber relevant werden. Das ist keine Hypothese: Es ist der Standardfehlermodus jedes verlustbehafteten Komprimierungsschemas, das auf Informationen angewendet wird, deren zukünftige Relevanz unbekannt ist.

Der zweite ist, dass Komprimierung ein Kostenfaktor auf dem heißen Pfad ist. Dass MemoryOS 20+ LLM-Aufrufe pro Interaktion zahlt, ist für komprimierungslastige Systeme nicht ungewöhnlich. Im Maßstab sind diese Kosten nicht vernachlässigbar.

Der dritte und subtilste ist, dass Komprimierung ohne eine Hintertür langsames Vergessen ist. Wenn der einzige Weg, die Kontextgröße zu reduzieren, das Zusammenfassen ist, und Zusammenfassungen verlustbehaftet sind, dann verwirft das System kontinuierlich Informationen, ohne sie wiederherstellen zu können. Zweistufiger Abruf, gestaffelter Speicher und Ergebnisvorschau-Kürzung bewahren alle den ursprünglichen Datensatz. Komprimierung tut das nicht.

Nichts davon bedeutet, dass Komprimierung falsch ist. Es bedeutet, dass Komprimierung allein nicht ausreicht.

Aktualitätsgewichtung und die persistente Warteschlange

Zwei Mechanismen, die nicht genau in die sechs obigen Kategorien passen, sind erwähnenswert.

Graymatter verwendet RRF-Fusion mit Aktualität mit halbem Gewicht. Das ist kein Budgetmechanismus im engeren Sinne, funktioniert aber als solcher: Indem älteres Material in den Abrufrankings herabgewichtet wird, reduziert es die Wahrscheinlichkeit, dass veraltete, signalschwache Datensätze aktuelle, signalsstarke verdrängen. Der Effekt ist eine weiche Staffelung durch Ranking-Gewichte anstelle einer expliziten Ebenenbeförderung.

Llm-wikis 540-zeilige Ingest-Warteschlangen-Zustandsmaschine verfolgt einen anderen Ansatz. Die Warteschlange serialisiert Ingest-Operationen und wendet einen Vier-Signal-Relevanz-Ranker an, bevor etwas in den Speicher gelangt. Die Budgetkontrolle erfolgt zum Zeitpunkt des Schreibens und nicht zum Zeitpunkt des Lesens. Material, das die Relevanzschwelle nicht überschreitet, wird nicht gespeichert, was bedeutet, dass es nicht abgerufen werden kann und keinen Kontext verbraucht. Das ist indirekte Budgetkontrolle, aber sie ist langlebig: Die Einsparungen summieren sich über jede zukünftige Sitzung.

Was die gut gestalteten Systeme gemeinsam haben

Über die 19 Systeme hinweg haben diejenigen, die Kontextbudgets gut handhaben, einige gemeinsame Eigenschaften.

Sie behandeln Abruf als zweistufige Operation anstelle einer einstufigen Injektion. Sie geben Vorschauen vor vollständigen Datensätzen zurück. Sie bewahren ursprüngliche Datensätze, anstatt sie durch Zusammenfassungen zu ersetzen. Sie geben Betreibern Kontrolle über das Abrufvolumen durch explizite Parameter anstelle von hartcodierten Standardwerten. Und sie denken über das Budget sowohl zum Zeitpunkt des Schreibens als auch zum Zeitpunkt des Lesens nach.

Diejenigen, die es schlecht handhaben, verlassen sich tendenziell auf einen einzigen Mechanismus, meist Komprimierung, und behandeln das Kontextfenster als einen zu füllenden Puffer und nicht als eine zu verwaltende Ressource.

Die abschließende Position aus der Forschung ist einfach. Größere Fenster erfordern mehr Disziplin, nicht weniger. Nicht, weil es grundsätzlich falsch ist, sie zu füllen, sondern weil das Füllen mit dem falschen Material mehr kostet, als den Raum leer zu lassen.

Für meinen nächsten Artikel plane ich, von Gedächtnis-als-Injektion zu Gedächtnis-als-Werkzeuge überzugehen und zu behandeln, wie die 19 Systeme die Grenze zwischen dem handhaben, was automatisch in den Kontext gedrückt wird, und dem, was der Agent explizit anfordern muss.*

Wie immer: Wenn Sie dies interessant, nützlich fanden oder einfach helfen möchten, das Wissen zu verbreiten:

Bitte teilen