fast-jev-compaction Analyse: Claude Codes Kompression auf das Schreiben von Zusammenfassungen verzichten lassen

Technische Zerlegung: Analyse von KI-Frameworks – Beschreibung, Analyse, technische Bewertung, Werturteil, praktische Anwendung. Autor: Yongliang

---

Am 19. September 2026 verzeichnet tamaratran/fast-jev-compaction auf GitHub 3.206 Sterne (Stand 19. September), ist in TypeScript geschrieben, unter der MIT-Lizenz lizenziert und das Repository wurde am 17. September 2026 erstellt – also vor zwei Tagen. Die NPM-Paketversion ist 0.2.0, die Claude-Code-Plugin-Liste steht bei 0.3.0. Das gesamte Repository umfasst 25 Dateien; Quellcode, Hooks und Tests zusammen ergeben ca. 1850 Zeilen, der Kern in src beträgt ca. 960 Zeilen, die größte einzelne Datei compact.ts umfasst 309 Zeilen. Die Kontextkompression (Compaction) von Claude Code lässt das Modell standardmäßig eine Zusammenfassung schreiben, um die alte Historie zu ersetzen. Zusammenfassungen sind verlustbehaftet – Dateipfade, präzise Fehlermeldungen und Randbedingungen können verloren gehen. Dieses Plugin schreibt keine Zusammenfassungen, es führt nur Löschungen durch; gelöschte Inhalte verschwinden entweder als ganzes Paar oder werden im Originaltext beibehalten. Dieser Artikel zerlegt das Thema in sechs Punkte: Was ist es, wo liegt der Schmerz, wie funktioniert der Mechanismus, drei lohnenswerte Stellen im Quellcode, Grenzen und Kosten sowie lohnt es sich.

1. Was ist das

fast-jev-compaction ist ein Claude-Code-Plugin: Es übernimmt den Schritt der Kontextkompression und tauscht „Zusammenfassung schreiben“ gegen „paarweise Entscheidung“. In der komprimierten Historie gibt es keine vom Modell paraphrasierten Absätze mehr; das Schicksal jedes Tool-Aufrufs beschränkt sich auf drei Möglichkeiten – vollständig erhalten, nur den Aufruf behalten und das Ergebnis verwerfen, oder sowohl Aufruf als auch Ergebnis verschwinden lassen. Die Entscheidungsgrundlage ist kein Textabsatz, sondern zwei Wahrscheinlichkeiten.

Um es zu verstehen, muss man zunächst das Modell kennen, von dem es abhängt. Jev ist das kommerzielle Modell von TypeSafe, die Produktlinie heißt „system one“: Es generiert keinen Text Wort für Wort, sondern gibt für eine Reihe von gestellten Fragen jeweils eine Wahrscheinlichkeit aus, damit der Agent schnell verzweigen kann. Welcher Satz auf welchen folgen soll, welches Ergebnis im Kontext bleiben soll – an solchen Verzweigungspunkten vom Typ „Ja oder Nein“ liefert es direkt Zahlen. Jev selbst ist eine neuere Erscheinung, die erst drei Tage alt ist – in diesen drei Tagen sind auf GitHub mindestens 5 Jev-Repos aufgetaucht, wobei browser-use/jev-ultrafast mit 5.487 Sternen zu den am schnellsten wachsenden gehört. Ein Modell, das eine Reihe von begleitenden Projekten nach sich zieht, zeigt, dass die Richtung „Wahrscheinlichkeitsmodelle für leichte Agenten-Entscheidungen nutzen“ an Fahrt gewinnt. fast-jev-compaction ist das vollständigste technische Muster in diesem Trend. TypeSafe hat das interne Design von Jev nicht öffentlich gemacht; dieser Artikel behandelt nur, wie dieses Plugin seine Schnittstelle nutzt, und erfindet keine Architektur dafür.

2. Der echte Schmerzpunkt, den es löst

Das Kontextfenster von Agents mit langen Sitzungen ist begrenzt; wenn es fast voll ist, muss komprimiert werden. Der Mainstream-Ansatz ist, dass ein LLM eine Zusammenfassung schreibt: Das Modell liest die alte Historie durch und schreibt eine kondensierte Version, die den Originaltext ersetzt. Das Wesen einer Zusammenfassung ist, dass das Modell für sein zukünftiges Ich Notizen macht – was notiert und was weggelassen wird, wird durch einen Generierungsprozess entschieden, Fehler hinterlassen keine Spuren. Dateipfade können zu ungefähren Pfaden umgeschrieben werden, präzise Fehlermeldungen können zu „es gab einen Fehler“ verallgemeinert werden, und vom Benutzer genannte Randbedingungen („diese Datei nicht ändern“) können bei der Kondensierung verloren gehen. Noch problematischer ist, dass nach der Komprimierung kein Mittel existiert, zu überprüfen, was verloren gegangen ist. Wenn das Modell drei Stunden später basierend auf einer falschen Zusammenfassung die falsche Datei ändert, ist es schwer, die Schuld auf diese Komprimierung zurückzuführen.

Die Zerlegung des Schmerzpunkts durch dieses Plugin ist sehr nüchtern: Der Großteil des Kontexts sind nicht die Chat-Texte, sondern die Tool-Aufrufe und Tool-Ergebnisse – ein Dateilesen sind einige tausend Zeichen, eine Testausgabe über zehntausend Zeichen; nach Dutzenden Runden fressen sie neunzig Prozent des Platzes auf. Was wirklich beurteilt werden muss, ist die Frage: „Ist dieser Aufruf für das, was als Nächstes kommt, noch wichtig?“ Das ist eine Multiple-Choice-Frage, kein Aufsatzthema. Eine Multiple-Choice-Frage kann an ein Modell beantwortet werden, das Wahrscheinlichkeiten ausgibt, und die Antworten können einzeln archiviert werden. Beim Schreiben wird erfunden, bei Multiple Choice ist man zumindest ehrlich.

3. Mechanismus: Von der Paarbildung zum Wiederaufbau

3.1 Paarbildung und Pinned

Der erste Schritt besteht darin, das Gespräch in entscheidungsfähige Einheiten zu zerlegen. Jedes tool_use und das entsprechende tool_result werden basierend auf der tool_use_id zu einem Paar zusammengefasst – beim Löschen gehen Aufruf und Ergebnis gemeinsam, beim Wiederaufbau taucht kein Ergebnis ohne zugehörigen Aufruf auf (keine „dangling results“). Die erste Nachricht und die neuesten preserveRecentMessages-Nachrichten (Standard 6) werden als pinned markiert und niemals verarbeitet, sodass der Anfang und der aktuelle Moment der Sitzung immer vollständig bleiben.

3.2 Aufbau des an Jev gesendeten State

Der an Jev gesendete State ist das vollständige Gespräch, der älteste zuerst. Alle Tool-Ergebnisse werden durch eine kurze Zeile ersetzt (z. B. ok, 4213 chars (omitted)), um Jev mitzuteilen: „Hier gab es ein erfolgreiches Lesen, Originaltext 4213 Zeichen“; die Tool-Inputs werden vollständig in den State serialisiert; die Texte von Benutzer und Assistent werden vollständig beibehalten, ohne Zusammenfassung. Der State selbst hat auch ein Volumenlimit von maxStateTokens (Standard 25000). Bei Überschreitung wird in Phasen herabgestuft: Tool-Inputs werden nacheinander auf 1000, 200, 60 Zeichen gekürzt; bei langen Texten werden die ersten 400 Zeichen und die letzten 150 Zeichen behalten; reicht das immer noch nicht, werden ab der ältesten Nachricht Nachrichten zu [… N chars omitted …] zusammengefaltet, alte Tool-Aufrufe auf eine Zeile reduziert (z. B. t12 Read file_path=src/a.ts → ok 480ch); gepinnte Nachrichten werden erst ganz zum Schluss angefasst. Wenn nach allen Phasen immer noch nichts passt, wird direkt eine Exception geworfen, statt etwas gewaltsam hineinzupressen. Die Token-Anzahl ist eine Zeichenschätzung: ca. 1 Token pro 6 Buchstaben, Zahlen halb, andere Symbole je ca. 1 – kein echter Tokenizer, billig und führt zu keiner Tokenisierungs-Abhängigkeit.

3.3 Zwei noul-Fragen und Batching

Für jeden nicht gepinnten Aufruf stellt das Plugin Jev zwei Fragen. call_X: „Ist es wichtig zu wissen, dass dieser Aufruf initiiert wurde und mit welchem Input, für das, was als Nächstes kommt?“. result_X: „Muss dieser Ergebnis-Originaltext erhalten bleiben, kann ein erneutes Ausführen des Tools ihn nicht ersetzen?“. Beide sind vom Typ noul – Jev antwortet nicht mit Text, sondern gibt für jede Frage eine Wahrscheinlichkeit aus.

Die Fragen werden nach Volumen in Batches unterteilt. maxRequestTokens ist standardmäßig 30000 (Jev-Single-Request-Limit 32000), abzüglich des Kontingents des State und abzüglich 20 Token Overhead für den Request-Envelope; das verbleibende Budget ist die Anzahl der Fragen, die ein Batch fassen kann. Der State wird bei jedem Batch vollständig neu gesendet, alle Fragen eines Batches werden in einer Anfrage zusammengefasst, die Batches werden parallel gesendet und die Antworten zusammengeführt. Je größer der State, desto weniger Fragen passen in einen Batch; im Extremfall ist für alle paar Fragen eine neue Anfrage nötig – das ist ein im Design inhärenter Kostenfaktor, mehr dazu im Abschnitt Grenzen.

3.4 Entscheidung und Wiederaufbau

Die Entscheidungsregeln passen in eine Zeile. decideCall entscheidet der Reihe nach: pinned wird direkt behalten; keepResult größer oder gleich dem Schwellenwert (Standard 0,5) -> Paar vollständig behalten; andernfalls, wenn keepCall größer oder gleich dem Schwellenwert, wird der Aufruf selbst behalten, das Ergebnis auf die ersten truncateHeadChars (Standard 300) Zeichen gekürzt und eine Zeile Erklärung angehängt – in der Erklärung steht, wie viele Zeichen gekürzt wurden, ob es ein Fehler war und dass das Tool bei Bedarf neu ausgeführt werden kann; liegen beide Wahrscheinlichkeiten unter dem Wert, werden Aufruf und Ergebnis als Paar gelöscht.

Der Wiederaufbau wird von applyDecisions erledigt: Nachrichten, deren Inhalt komplett wegfiel, werden ganz entfernt; unveränderte Nachrichten werden unverändert zurückgegeben (dasselbe Objekt, Zero-Copy); teilweise geänderte Nachrichten werden an Ort und Stelle ersetzt. Input und Output sind durchgehend strukturierte Entscheidungen plus überprüfbare Statistiken (Zähler für jede Art von Entscheidung, Zeichenanzahl vor und nach der Komprimierung, geschätzte Token-Anzahl des State, welche Stufe der Herabstufung genutzt wurde, wie viele Anfragen gesendet wurden), kein Prosatext.

4. Drei Stellen im Quellcode, die sich lohnen

4.1 Die Batching- und Entscheidungsfunktionen in compact.ts

compact.ts hat 309 Zeilen und ist die größte Datei im Repository; der Hauptzweig besteht aus vier Funktionen. questionsFor (compact.ts:56) generiert für jeden Aufruf zwei noul-Fragen; der Fragentext arbeitet Tool-Name, Aufruf-ID und Zeichenanzahl des Ergebnisses ein, damit Jev bei der Entscheidung eine Grundlage hat. batchCalls (compact.ts:73) übernimmt das Batching, der Budget-Algorithmus ist transparent: maxRequestTokens minus State minus 20, was passt, wird reingepackt; wenn die Fragen eines einzelnen Aufrufs das Budget selbst sprengen, ist der State zu groß, und es wird direkt eine Exception geworfen, in der steht, dass der State ungefähr so viel von den 30000 belegt. decideCall (compact.ts:101) ist der kürzeste Absatz im ganzen Buch – pinned, keepResult-Schwellenwert, keepCall-Schwellenwert, else löschen, vier Zeilen. applyDecisions (ab compact.ts:149) ist für den Wiederaufbau zuständig; die Kommentare schreiben die Invarianten sehr klar heraus: gelöschte Aufrufe verschwinden mitsamt dem Ergebnis; bei gelöschten Ergebnissen wird ein begrenzter Kopf und eine Erklärung behalten; Nachrichten, deren Inhalt komplett weg ist, werden entfernt; unveränderte Nachrichten werden als das ursprüngliche Objekt zurückgegeben.

4.2 Der Endpunkt und das noul-Parsing in request.ts

request.ts hat nur 80 Zeilen und ist die gesamte Schnittstellenvereinbarung. SYSTEM_ONE_URL zeigt auf https://api.typesafe.ai/v1/systemone, der Standardmodellname ist jev-latest. buildJevRequest packt model, state und questions in einen POST. parseJevResponse nimmt eine harte Validierung des Antwortkörpers vor: HTTP nicht ok -> Fehler, JSON-Parsing fehlgeschlagen -> Fehler, Feld answers fehlt -> Fehler. noulAnswer holt das noul-Feld einer einzelnen Antwort; fehlt das Feld, ist es keine Zahl oder keine endliche Zahl, wird in jedem Fall geworfen. In der gesamten Datei gibt es kein einziges stilles Fehler swallowing – alle Misserfolge werden zu Exceptions nach oben gereicht, vom Aufrufer wird entschieden, wie abgefangen wird.

4.3 Die Auslösebedingungen des Hooks

hooks/fast-jev.ts ist eine dünne Adapterschicht, die Claude Code empfängt. function hooks ist eine frühe Funktion von Claude Code 2.1.274+ und muss zuerst in der settings.json per opt-in aktiviert werden; nach der Aktivierung wird das Plugin bei turn.complete zurückgerufen, prüft die aktuelle Kontextauslastung und löst die Komprimierung erst aus, wenn compactAtPercent (Standard 60 %) erreicht ist. Nach der Auslösung wird zuerst eine Runde geschätzt; wenn die Kompressionsrate unter minReductionRatio (Standard 25 %) liegt, wird die Historie nicht ersetzt – einen nutzlosen Durchlauf „zum Nulltarif“ macht das Plugin nicht. Jede Exception – Jev-Service down, Antworten deformiert, TYPESAFE_API_KEY fehlt, State passt nicht – wird nicht durchgezogen, sondern fällt auf die eingebaute Zusammenfassungskomprimierung von Claude Code zurück. Die Konfiguration kann komplett über userConfig des Plugins laufen: Schwellenwerte, Anzahl der zu behaltenden Nachrichten, Kürzungslänge, Modellname – alles einzeln änderbar.

5. Grenzen und Kosten

Die offiziellen Limitationen sind vier, ich zitiere sie wörtlich. Erstens: Es werden nur Tool-Aufrufe verarbeitet, Textnachrichten werden auf der Ausgabeseite nie gekürzt (sie werden nur im State, den Jev sieht, abgekürzt) – wenn dein Kontext durch Chat-Text aufgebläht ist, hilft dieses Plugin nicht. Zweitens: Die Token-Anzahl ist eine Zeichenschätzung, kein echter Tokenizer, die Budgetbeurteilung weicht ab. Drittens, ein Satz, den man sich ganz merken sollte: „Eine Wahrscheinlichkeit ist kein Beweis für sicheres Löschen, der Assistent kann das Tool immer neu ausführen“ – der Schwellenwert 0,5 ist keine Sicherheitslinie, sondern eine empirische Linie. Viertens: Der State wird bei jeder Anfrage vollständig neu gesendet; wenn die Historie sich dem Limit nähert, braucht man für alle paar Fragen eine Anfrage, die Token-Kosten steigen linear mit der Länge der Historie, wer es intensiv nutzt, muss diese Rechnung können.

Drei Punkte des Zweifels, ich schreibe nur Zweifel, nichts Festes. Die Entscheidungsqualität setzt vollständig auf die Kalibrierung der Wahrscheinlichkeiten des einen kommerziellen Modells Jev; das Repository hat keine Benchmark-Zahlen aus Integrationstests, das README hat keine Benchmark-Tabelle, ob gut komprimiert wird, gibt es kein von Dritten überprüfbares Maß. Das Plugin-Ökosystem ist eng an die Claude-Code-Version gekoppelt, function hooks selbst sind eine frühe Funktion von 2.1.274+, bewegt sich die Schnittstelle, muss das Plugin mitziehen. Das Repository hat nur eine zweitägige Historie, das Verhalten bei langen Sitzungen in der Produktion hat niemand verifiziert, die 3206 Sterne in zwei Tagen sind Konzept-Hype, keine Stabilitätsgarantie.

6. Lohnt es sich und für wen ist es geeignet

Das ist eine neue Lösung für das alte Problem „Kontextkomprimierung“ – aus der Zusammenfassungs-Aufgabe eine Multiple-Choice-Aufgabe machen, der Preis ist, dass die Entscheidungsmacht an ein kommerzielles Wahrscheinlichkeitsmodell ausgelagert wird. Für wen es sich eignet, ist klar: Leute, die jeden Tag Claude Code für lange Sitzungen nutzen und schon einmal durch verlorene Zusammenfassungen Ärger hatten, die Installationskosten sind niedrig (NPM-Paket plus Umgebungsvariable); Leute, die Agent-Engineering machen und Kontext-Management erforschen, dieses Repository mit 1850 Zeilen kann man in einem Abend durchlesen, es ist ein sauberes Beispiel, wie man ein Wahrscheinlichkeitsmodell in die Entscheidungsschleife eines Agents einbaut. Für wen es sich nicht eignet, ist ebenso klar: Leute, die keine Gesprächsdaten an Drittanbieter-APIs senden wollen – der State ist das vollständige Gespräch, inklusive deines Codes und deiner Fehlermeldungen; Leute, deren Sitzungen selbst nicht lang sind und die eingebaute Zusammenfassung reicht; Teams, die verifizierbare Garantien zur Kompressionsqualität brauchen, das README hat keine Benchmarks, dieses Versprechen kann aktuell nicht gegeben werden.

Ansicht des Autors: Wenn man Jev nicht nutzt, lässt sich dieser Gedanke portieren? Wahrscheinlich ja. Das Wesen der noul-Fragen ist, eine Gruppe von Optionen zu bewerten, jedes kleine Modell, das Logits ausgeben kann, kann das – lokal ein kleines Modell auf 3B-Niveau laufen lassen, für die beiden Fragen call_X und result_X die Wahrscheinlichkeit von „Ja“ ausgeben, den Remote-Call von Jev ersetzen, Daten verlassen den Rechner nicht, die Aufrufkosten gehen auf Null, der Preis ist, dass niemand die Kalibrierungsqualität garantiert, den Schwellenwert muss man selbst anpassen. Was dieses Projekt wirklich wert ist, mitzunehmen, ist nicht unbedingt das Plugin selbst, sondern diese Art zu fragen: Kontext zu komprimieren muss nicht heißen, dass das Modell einen Aufsatz schreibt, lass es Multiple Choice lösen, und führe dann basierend auf dem Wahrscheinlichkeitsschwellenwert aus.

Fazit

fast-jev-compaction beantwortet mit ca. 1850 Zeilen Code eine Frage: Muss Kontextkomprimierung unbedingt Zusammenfassungen schreiben? Seine Antwort ist nein. Tool-Aufrufe machen den Großteil des Kontexts langer Sitzungen aus, „Behalten oder Löschen“ ist eine Multiple-Choice-Frage, die ein Modell wie Jev, das Wahrscheinlichkeiten für Optionen ausgibt, beantworten kann. Im Quellcode wird diese Beurteilung sehr konkret: Aufrufe werden nach tool_use_id gepaart, die erste und die neuesten 6 sind pinned und werden niemals verarbeitet, der State wird vollständig aufgebaut, Tool-Ergebnisse durch kurze Hinweise ersetzt, bei Überschreitung in vier Stufen herabgestuft, für jeden Aufruf werden zwei noul-Fragen gestellt, nach einem Budget von 30000 Token in Batches parallel abgearbeitet, mit einem Schwellenwert von 0,5 über die drei Stufen keep / drop_result / drop_call entschieden, beim Wiederaufbau wird garantiert, dass keine verwaisten Ergebnisse entstehen; auf der Hook-Seite wird bei turn.complete die Auslastung von 60 % geprüft, um die Komprimierung auszulösen, liegt die Kompressionsrate unter 25 %, wird der Ersatz abgebrochen, bei Fehlern wird auf die eingebaute Zusammenfassung zurückgefallen. Die Kosten sind auch klar: Token sind geschätzt, Wahrscheinlichkeit ist kein Beweis für sicheres Löschen, der State wird vollständig neu gesendet, die Qualität hat keine Benchmark-Zahlen. 3206 Sterne in zwei Tagen, das ist Konzept-Hype, es ist auf demselben Boot wie Jev, diese dreitägige neue Sache – für Leute, die Agent-Kontext-Management machen, ist das ein Quellcode, den es zu lesen lohnt; für normale Nutzer, warte besser, bis es ein paar Versionen durchlaufen hat.

Referenzen

• tamaratran/fast-jev-compaction README (Positionierung, Konfigurationstabelle, Limitations, Claude-Code-Plugin-Beschreibung, Anforderung an die Version von function hooks)
• Quellcode (lokales Klonen): src/compact.ts (DEFAULT_OPTIONS, questionsFor, batchCalls, decideCall, applyDecisions), src/state.ts (collectToolCalls, estimateTokens, fitState, INPUT_CHARS=[1000,200,60], TEXT_HEAD=400/TEXT_TAIL=150), src/request.ts (SYSTEM_ONE_URL, DEFAULT_MODEL, buildJevRequest, parseJevResponse, noulAnswer), hooks/fast-jev.ts (compactAtPercent, minReductionRatio, Exception-Fallback)
• Repository-Daten: 3.206★, MIT, erstellt am 2026-09-17, npm 0.2.0, Plugin-Liste 0.3.0, 25 Dateien ca. 1850 Zeilen (Stand 2026-09-19)