100K Kontext reichen: Erinnerung komprimieren statt ein größeres Fenster kaufen

Das Fenster ist nicht das Problem

Alle paar Monate bringt ein Labor ein Modell mit größerem Kontextfenster heraus, und das Gespräch beginnt von vorn: zweihunderttausend Token, dann eine Million, dann zwei Millionen. Das implizite Versprechen: Erinnerung ist ein Hardwareproblem, und irgendwer wird es schon größer machen.

billion-context, ein TypeScript-Projekt von ranxianglei, das seit Ende September steigt, setzt im Slogan genau dagegen: 100K Kontext reichen. Nicht "reichen erstmal". Sie reichen, wenn man das Gespräch nicht mehr als reines Anhänge-Log behandelt.

Es ist ein Proxy zwischen deinem Coding-Agenten und der Modell-API. Anfragen laufen hindurch, werden komprimiert und weitergeleitet. Antworten werden auf dem Rückweg umgeschrieben. Am Modell ändert sich nichts. Das Argument: Teuer war nie die Größe des Fensters, sondern das, was wir immer hineingestopft haben.

Wie die Kompression funktioniert

Der Proxy parst jede Anfrage im Anthropic- oder OpenAI-Format, lässt seinen Kompressionskern über das Gespräch laufen und schiebt vier Tools ein, die das Modell selbst aufrufen kann: einen Nachrichtenbereich zu einer Zusammenfassung komprimieren, einen Bereich wieder dekomprimieren, wenn exakte Details gebraucht werden, die komprimierten Zusammenfassungen plus sichtbare Nachrichten per Stichwort durchsuchen, und die Kontextauslastung prüfen.

Die wichtige Designentscheidung: Das Modell entscheidet, wann komprimiert wird, nicht ein fester Schwellwert. Der eingebaute Summarizer eines Hosts feuert meist, wenn das Fenster voll ist, und ersetzt alles vor einem Schnittpunkt durch eine Zusammenfassung, die sich nicht rückgängig machen lässt. billion-context komprimiert in kleinen Bereichen, hält sie umkehrbar und lässt den Prefix-Cache heil.

Der letzte Punkt ist das Engineering-Detail, auf das es ankommt. Prefix-Caching ist der Grund, warum lange Agent-Sessions überhaupt bezahlbar sind; wenn jede Kompression den Anfang des Gesprächs umschreibt, verfehlt der Cache und du zahlst den vollen Preis für die gesamte Historie noch einmal. Das Projekt behauptet eine Prefix-Cache-Trefferquote von 95-97% in einer gesunden Session und höchstens 2% Overhead durch die Kompression selbst. Das sind eigene Zahlen, und es liefert Befehle mit, um einen Einbruch der Trefferquote einer Ursache zuzuordnen, meist abgelaufener TTL im Upstream-Cache oder ein Modellwechsel.

Die Zahl, die die Behauptung glaubwürdig macht

Anbieter behaupten ständig Token-Ersparnisse. Ungewöhnlich ist hier eine Längsschnittstudie, die mit dem Code ausgeliefert wird: viereinhalb Monate, drei Hosts, 174,327 Modellaufrufe, 18.76 Milliarden kumulierte Input-Token auf einem Host und rund 24.7 Milliarden über alle. Der Bericht sagt, die längsten Sessions liefen 8,584 bis 12,049 Aufrufe, mit null Kontextfenster-Verstößen auf Modellen mit 204,800 Token.

Null Fensterverstöße ist der Satz, auf den es ankommt. Keine Session ist gestorben, weil das Gespräch größer wurde als das Modell. Alles andere in der Studie hängt daran.

Das verschiebt auch, was "lange Session" heißt. Die meisten erleben Kontextgrenzen als langsamen Verfall: Der Agent wird vager, vergisst eine Vorgabe von vor zwei Stunden, fängt an, bereits gelesene Dateien erneut zu lesen. Wenn das Fenster wirklich voll ist, ist die Session meist schon eine Weile schlecht. Kompression, die durchgehend läuft, adressiert den Verfall, nicht nur den harten Stopp.

Ob es auf deiner Workload so funktioniert wie beworben, ist eine andere Frage. Die Zahlen sind selbst berichtet, der Benchmark ist die eigene Nutzung des Autors, und "5× weniger Token" hängt komplett davon ab, wie repetitiv deine Sessions sind. Eine Session, die vierzig Dateien liest und drei ändert, lässt sich wunderbar komprimieren. Eine Session, die eine einzige riesige Datei liest und Zeile für Zeile darüber nachdenkt, hat deutlich weniger Redundanz zum Falten.

Was sich im Alltag ändert

Der praktische Unterschied zeigt sich in der langweiligen Mitte einer langen Aufgabe. Ein Agent, der ein Refactoring durchzieht, hat drei Arten von Gedächtnis: was er entschieden hat, was er gelesen hat und was er versucht und verworfen hat. Ein rohes Transkript hält alle drei auf derselben Auflösung, und deshalb füllt ein Refactoring über vierzig Dateien ein Fenster mit Stacktraces, die längst egal sind.

Mit Kompression behält der Agent Entscheidungen in voller Auflösung, faltet die Belege in Zusammenfassungen und holt die exakten Zeilen nur zurück, wenn er sie braucht. So arbeitet ungefähr ein Mensch: Du erinnerst dich, dass du die Validierung in die Middleware verschoben hast, nicht an die sechs Versuche davor.

Das Fehlerbild ist genauso menschlich. Wenn eine Zusammenfassung die eine Vorgabe fallen lässt, auf die es ankam, "dieser Endpoint muss abwärtskompatibel bleiben", bricht der Agent sie vierzig Minuten später munter. Die Kompressionsschicht hat dir Geld gespart und dich einen Bug gekostet. Umkehrbarkeit macht das überlebbar: Du kannst dekomprimieren und nachsehen, was die Zusammenfassung wirklich gesagt hat.

Warum das jetzt eine Kategorie ist

Mindestens drei Ansätze streiten um dasselbe Problem. Der eine ist die Antwort des Labors: ein größeres Fenster bauen. Der zweite die Antwort des Harness: abrufen statt erinnern und nur ein Arbeitsset im Kontext halten. Der dritte, für den billion-context steht: das Gespräch behalten und es an Ort und Stelle komprimieren, umkehrbar.

Die Kompromisse sind echt. Ein größeres Fenster ist am einfachsten und am wenigsten kontrollierbar; du zahlst es bei jedem Aufruf, ob die Historie relevant ist oder nicht. Abrufen ist am billigsten, verliert aber Kontinuität, weil der Agent nicht weiß, was er vergessen hat. In-Place-Kompression versucht Kontinuität und Kosten gleichzeitig zu halten, zum Preis, im Pfad deiner Anfragen zu sitzen.

Über diesen letzten Preis sollte man nachdenken. Ein Proxy in der Mitte sieht jeden Prompt und jede Completion. Für einen Solo-Entwickler ist das in Ordnung. Für ein Unternehmen mit Datenregeln ist es ein Compliance-Gespräch, und "wir haben den Quellcode gelesen, passt" ist nicht dasselbe wie ein Audit.

Dazu kommt die Kleinigkeit mit der Lizenz. Das technische Paper ist MIT und liegt im Repo. Die Lizenz des Repos selbst wird als "Other" geführt, nicht als Standard-OSI-Lizenz. Wenn du das im Unternehmen ausrollst, wird dir dieser Unterschied begegnen.

Die unbequeme Konsequenz

Wenn Kompression gut genug funktioniert, dass 100K reichen, dann zielt ein Großteil des Marketings für Kontextfenster auf ein Problem, das sich in Software billiger lösen lässt. Das macht größere Fenster nicht nutzlos, ein einzelnes 400-Seiten-Dokument muss irgendwo hineinpassen, aber "wir haben eine Million Token" ist damit ein schwächeres Verkaufsargument, als es klingt. Es ist wie mit einem größeren Tank zu werben statt mit besserem Verbrauch.

Es ändert auch, wie du einen Agenten schreiben solltest. Wenn Erinnerung komprimierbar ist, sollte man den Agenten dazu bringen, Gelerntes strukturiert aufzuschreiben, weil strukturierte Notizen sich viel besser komprimieren lassen als rohe Logs. Ein Satz wie "die Auth-Middleware liest den Tenant aus dem Header, nicht aus dem Cookie" ist tausend Zeilen Stacktrace wert. Die Kompressionsschicht belohnt gute Buchführung, und das ist eine schöne Eigenschaft für ein Werkzeug.

Das Projekt liegt irgendwo über tausend Sternen und bei rund 400,000 npm-Downloads im Monat, mit Badges für mehr als zwanzig Clients. Das ist keine Hobby-Installationsbasis. Es deutet darauf hin, dass der Schmerz real und weit verbreitet ist, und dass die Antwort, nach der die Leute greifen, keine weitere Null bei der Fenstergröße ist.

Das ist die brauchbare Erkenntnis, egal welches Werkzeug du am Ende nimmst. Kontext ist ein Budget, kein Behälter. Teams, die ihn so behandeln, schaffen pro Dollar mehr, und die anderen zahlen weiter dafür, nicht entscheiden zu müssen, was wichtig ist.