Benchmark

Nicht vertrauen.
Verifizieren.

Führe lean-ctx benchmark run in jedem Projekt aus. Echte Token-Zahlen. Echte Genauigkeits-Metriken. Gemessen mit tiktoken (o200k_base).

Wie es ehrlich bleibt

Gemessen. Verifiziert.

Der Benchmark läuft lokal, zählt Tokens mit dem exakten Tokenizer und verwirft Kompressionen, die unter die Qualitäts-Schwelle fallen.

Exakte Token-Zählung

Zählt mit demselben Tokenizer, den moderne LLMs nutzen – keine Schätzungen, kein Raten.

tiktoken o200k_base

Qualitäts-Wächter

Bewertet AST-Erhaltung, Bezeichner und Zeilenstruktur. Fehlschlagende Ausgaben werden automatisch blockiert.

Schwelle: Q ≥ 95% · ρ ≥ 15%

Reproduzierbar

Läuft auf deinem Repo. Gleiche Eingaben → gleiche Zahlen. Ideal für CI und Regressionen.

offline · deterministisch
Sieh den Unterschied

Vorher & Nachher

Dieselbe Datei. Dieselbe Information. Dramatisch weniger Tokens.

Ohne LeanCTX
// src/auth.ts · mode=full
import { jwt, verify, sign } from 'jsonwebtoken';
import { bcrypt } from 'bcryptjs';
3.517 Tokens
Mit LeanCTX (map-Modus)
// src/auth.ts · mode=map
exports: AuthService, validateToken, …
deps: jsonwebtoken, bcryptjs, ioredis
412 Tokens

88% weniger Tokens

Drei Schritte zu verifizierten Einsparungen

Zeigen. Messen. Verifizieren.

01

Auf jede Datei oder jedes Verzeichnis zeigen

Übergib eine einzelne Datei, ein Verzeichnis oder ein Glob-Muster. Die Benchmark-Engine verarbeitet alles, was sie findet.

lean-ctx benchmark run src/
02

Exakte Token-Messung

Nutzt tiktoken mit dem o200k_base-Encoding (wie GPT-4o, Claude und moderne LLMs). Keine Schätzungen – echte Token-Zahlen.

tiktoken o200k_base
03

Einsparungen pro Modus

Erhalte Genauigkeits-Scores und Einsparungsprozente für jeden Kompressionsmodus. Wähl den richtigen Modus für jeden Anwendungsfall.

modes: 10
Echte Ausgabe

Benchmark in Aktion

Führe den Benchmark auf jeder Datei in deinem Projekt aus. Die Ausgabe zeigt exakte Token-Zahlen für jeden Kompressionsmodus, Einsparungsprozente und Qualitäts-Erhaltungs-Scores.

Aufschlüsselung pro Datei – Tokens vor und nach jedem Modus

Qualitäts-Scores – AST, Bezeichner und Codezeilen erhalten

Aggregierte Summen – verzeichnisweite Einsparungen mit Empfehlung des besten Modus

lean-ctx benchmark run

$ lean-ctx benchmark run src/auth.ts

◆ lean-ctx Benchmark

────────────────────────────────────────

src/auth.ts (123 lines, 3,517 tokens)

────────────────────────────────────────

Mode Tokens Saved Rate

full 3,517 0 0%

map 412 3,105 88%

signatures 252 3,265 93%

diff 187 3,330 95%

aggressive 298 3,219 92%

entropy 312 3,205 91%

────────────────────────────────────────

Quality: AST 98% | Idents 97% | Lines 96%

Encoding: tiktoken o200k_base | Time: 12ms

Wähl den richtigen Modus für jede Aufgabe

Read-Modi im Vergleich

full 0%

Dateien, die du editieren wirst

Alles – voller Inhalt gecacht für Re-Reads bei ~13 Tokens

map 70-90%

Nur-Kontext-Dateien

Code: Deps + Exports + Signaturen. Nicht-Code: strukturierte Outlines (Markdown-Überschriften, JSON/YAML/TOML-Keys, Lock-Zusammenfassungen)

signatures 55–93%

API-Oberfläche erkunden

Nur Funktions-/Klassen-/Typ-Signaturen

diff 80–95%

Nach Edits

Geänderte Zeilen mit minimalem umgebenden Kontext

aggressive 75–90%

Große Boilerplate-Dateien

Struktur und Logik, Syntax entfernt

entropy 70–83%

Verrauschte Dateien (JSDoc, Kommentare)

Nur Zeilen mit hoher Entropie (Shannon- + Jaccard-Filterung)

task 65–85%

Task-fokussierte Reads (z. B. ‚Auth-Bug fixen‘)

Task-relevanter Code + Dependency-Kontext via Knowledge-Graph + IB-Filter

auto 70–99%

Standard – LeanCTX wählt automatisch den besten Modus

Passt sich pro Datei an: Typ, Größenklasse, Aktualität, Task-Relevanz

reference 80–95%

API-Docs und Referenz-Lookup

Öffentliche API, Typen, Signaturen, Docstrings

lines:N-M 90–99%

Einen bestimmten Zeilenbereich lesen – chirurgische Präzision

Exakt angeforderte Zeilen, plus minimaler umgebender Kontext

LeanCTX’ ctx_smart_read wählt automatisch den optimalen Modus mittels Bayes’scher Vorhersage anhand von Dateityp, Größe und Kontext.

Stufe

Erweiterte Kompressions-Pipeline

Über die Modus-Auswahl hinaus wendet LeanCTX eine mehrstufige Optimierungs-Pipeline an, die sich an Dateityp, Session-Kontext und Task-Intent anpasst:

Thompson Sampling 5–15%

Lernt optimale Kompressions-Schwellen pro Dateityp via Multi-Armed-Bandit-Exploration (explore vs. exploit)

AST Pruning 40–70%

Sprachbewusstes Pruning via Tree-sitter – entfernt Funktionsrümpfe, Kommentare und Boilerplate, erhält dabei API-Signaturen

IDF Dedup 10–30%

Dateiübergreifende Deduplizierung mittels inverser Dokumentfrequenz – eliminiert Inhalte, die in der Session bereits gesehen wurden

IB Filter 15–25%

Task-bewusste Filterung nach dem Information-Bottleneck-Prinzip – behält nur Inhalte, die für die aktuelle Aufgabe relevant sind

Verbatim Compaction 5–20%

Klappt repetitive Strukturen (Imports, Log-Zeilen, Boilerplate) in gezählte Zusammenfassungen zusammen

Diese Stufen sind kumulativ – nacheinander angewandt können sie eine 1000-Zeilen-Datei auf unter 50 Tokens reduzieren und dabei alle task-relevanten Informationen erhalten. Die Pipeline ist vollautomatisch und erfordert keine Konfiguration.

Verifizierte Erhaltung

Kompressions- Qualität

Qualitäts-Schwelle (zusammengesetzt)

95%

Komprimierte Ausgabe wird nur verwendet, wenn der zusammengesetzte Qualitäts-Score bei mindestens 95% bleibt.

Mindest-Dichte

15%

Blockiert informationsarme Ausgabe mit einer Mindest-Signaldichte von 15% (ρ).

Gewichtung

50/30/20

Zusammengesetzt = AST 50% + Bezeichner 30% + Zeilen 20% – Struktur zählt also am meisten.

Prinzip der Informationsdichte

Warum weniger Tokens = höhere Signaldichte

LLMs haben ein festes Attention-Budget. Jeder Token im Kontextfenster konkurriert um Attention-Gewichte. Das Fenster mit Boilerplate zu füllen bedeutet weniger Aufmerksamkeit für den Code, der zählt.

Indem LeanCTX Rauschen entfernt, bevor es das Modell erreicht, erhöht es die Informationsdichte jeder Anfrage. Das Ergebnis: höheres Signal-Rausch-Verhältnis, weniger Kontext-Verwässerung, und das Modell bleibt innerhalb nützlicher Kontextgrenzen.

Höheres Signal-Rausch-Verhältnis

10K Tokens fokussierter Kontext schlagen 200K Boilerplate. Das Modell verwendet seine Aufmerksamkeit auf Logik statt auf JSDoc-Kommentare und Import-Boilerplate.

Reduziertes Kontext-Rauschen

Kontext-Rauschen verwässert das Attention-Fenster des Modells. Es zu entfernen hilft dem Modell, in der tatsächlichen Code-Struktur verankert zu bleiben, und senkt die Halluzinations-Wahrscheinlichkeit.

Niedrigere Kosten pro Antwort

Weniger Input-Tokens bedeuten niedrigere API-Kosten und mehr Nachrichten innerhalb deines Rate-Limits. Dasselbe Kontingent reicht weiter – für jedes KI-Tool, das du nutzt.

Beispiele aus der Praxis

Gemessen an echtem Code

Repräsentative Momentaufnahmen – deine Zahlen variieren je nach Datei und Codebasis.

React-Komponente 88%

450 Zeilen – map-Modus

12.840 → 1.541
Rust-Modul 93%

820 Zeilen – signatures-Modus

18.290 → 1.280
Express-API 91%

1.200 Zeilen – aggressive-Modus

31.500 → 2.835
Python-ML-Pipeline 83%

680 Zeilen – entropy-Modus

15.400 → 2.618
TypeScript-Konfiguration 95%

340 Zeilen – diff-Modus

8.750 → 437
Transparenz

Benchmark-
Methodik

Jede Zahl auf dieser Seite ist reproduzierbar. So messen wir genau.

Tokenizer

Alle Token-Zahlen nutzen tiktoken mit dem o200k_base-Encoding – denselben Tokenizer wie GPT-4o, Claude und moderne LLMs. Keine Schätzungen oder Näherungen.

Qualitäts-Schwelle

Komprimierte Ausgabe wird nur verwendet, wenn der zusammengesetzte Qualitäts-Score bei mindestens 95% bleibt. Zusammengesetzt = AST-Erhaltung (50%) + Bezeichner-Erhaltung (30%) + Zeilenabdeckung (20%).

Lokal reproduzieren

Führe lean-ctx benchmark run src/ auf deiner eigenen Codebasis aus. Die Ausgabe zeigt exakte Token-Zahlen für jeden Kompressionsmodus, Einsparungsprozente und Qualitäts-Erhaltungs-Scores.

Haftungsausschluss

Die Ergebnisse variieren je nach Dateityp, Größe, Sprache und Read-Modus. Der Bereich „60-99%“ spiegelt reale Varianz wider: kleine strukturierte Dateien komprimieren stärker, große unstrukturierte Dateien weniger. Gecachte Re-Reads (~13 Tokens) stellen den Best Case dar.

Unser eigener Overhead, gemessen

Einsparungsangaben müssen netto dessen sein, was LeanCTX selbst injiziert. Der fixe Fußabdruck pro Session (beworbene Tool-Schemas + MCP-Instruktionen) beträgt ~2,1K Tokens, gemessen in isolierter Umgebung mit lean-ctx doctor overhead und in der CI per --gate erzwungen — er kann nur schrumpfen. lean-ctx gain weist Einsparungen netto dieses Overheads aus.

Deterministische Selbstverifikation

lean-ctx benchmark dual-arm --json spielt eine fixierte 15-Turn-Agent-Session durch einen zustandslosen Arm und die langlebige Proxy-Schiene, bepreist beide mit echten Tokenizer-Zählungen und veröffentlichten Modellpreisen und fingerprintet den Lauf mit einem BLAKE3-Digest — jeder kann die exakten Zahlen reproduzieren, ganz ohne Live-Modell.

Miss deine tatsächlichen Einsparungen.

Installiere LeanCTX und führe benchmark run auf deiner Codebasis aus. Echte Zahlen, deine Dateien, deine Einsparungen.

lean-ctx benchmark run src/

Funktioniert auf jeder Codebasis. Keine Konfiguration nötig. Ergebnisse in Sekunden.