╭──────────────────────────────────────────╮ ╭──────────────────────────────────────────╮ │ >>>>>>>>>>>>>>> ctx_read >>>>>>>>>>>> │ │ >>>>>>>>>>>>>>> ctx_read >>>>>>>>>>>> │ ┌─────────────┐ │ >>>>>>>>>>>>>>> compress >>>>>>>>>>>> │ ┌──────────┐ ┌─────────────┐ │ >>>>>>>>>>>>>>> compress >>>>>>>>>>>> │ ┌──────────┐ │ 100K tokens │ =========>│ >>> AST >>> cache >>> signal >>> │ =========> │ ~5K tok │ │ 100K tokens │ =========>│ >>> AST >>> cache >>> signal >>> │ =========> │ ~5K tok │ └─────────────┘ │ >>>>>>>>>>>>>>> filter >>>>>>>>>>>> │ └──────────┘ └─────────────┘ │ >>>>>>>>>>>>>>> filter >>>>>>>>>>>> │ └──────────┘ │ >>>>>>>>>>>>>>> dedupe >>>>>>>>>>>> │ │ >>>>>>>>>>>>>>> dedupe >>>>>>>>>>>> │ ╔══════════════╗ ╰──────────────────────────────────────────╯ ╔══════════╗ ╔══════════════╗ ╰──────────────────────────────────────────╯ ╔══════════╗ ║ raw input ║ ─ ─ ─ ─ ─ ─ ─ ─ LeanCTX ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ║ output ║ ║ raw input ║ ─ ─ ─ ─ ─ ─ ─ ─ LeanCTX ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ║ output ║ ╚══════════════╝ ╚══════════╝ ╚══════════════╝ ╚══════════╝ ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ │░░│ │░░│ │░░│ │░░│ │▓▓│ │▓▓│ │▓▓│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │▓▓│ │▓▓│ │▓▓│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ ───> │▓▓│ │▓▓│ │▓▓│ ───> │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ ───> │▓▓│ │▓▓│ │▓▓│ ───> │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ file file file file read cache send tok tok tok tok tok tok file file file file read cache send tok tok tok tok tok tok ╭──────────────────────────────────────────╮ ╭──────────────────────────────────────────╮ │ >>>>>>>>>>>>>>> ctx_read >>>>>>>>>>>> │ │ >>>>>>>>>>>>>>> ctx_read >>>>>>>>>>>> │ ┌─────────────┐ │ >>>>>>>>>>>>>>> compress >>>>>>>>>>>> │ ┌──────────┐ ┌─────────────┐ │ >>>>>>>>>>>>>>> compress >>>>>>>>>>>> │ ┌──────────┐ │ 100K tokens │ =========>│ >>> AST >>> cache >>> signal >>> │ =========> │ ~5K tok │ │ 100K tokens │ =========>│ >>> AST >>> cache >>> signal >>> │ =========> │ ~5K tok │ └─────────────┘ │ >>>>>>>>>>>>>>> filter >>>>>>>>>>>> │ └──────────┘ └─────────────┘ │ >>>>>>>>>>>>>>> filter >>>>>>>>>>>> │ └──────────┘ │ >>>>>>>>>>>>>>> dedupe >>>>>>>>>>>> │ │ >>>>>>>>>>>>>>> dedupe >>>>>>>>>>>> │ ╔══════════════╗ ╰──────────────────────────────────────────╯ ╔══════════╗ ╔══════════════╗ ╰──────────────────────────────────────────╯ ╔══════════╗ ║ raw input ║ ─ ─ ─ ─ ─ ─ ─ ─ LeanCTX ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ║ output ║ ║ raw input ║ ─ ─ ─ ─ ─ ─ ─ ─ LeanCTX ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ║ output ║ ╚══════════════╝ ╚══════════╝ ╚══════════════╝ ╚══════════╝ ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ │░░│ │░░│ │░░│ │░░│ │▓▓│ │▓▓│ │▓▓│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │▓▓│ │▓▓│ │▓▓│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ ───> │▓▓│ │▓▓│ │▓▓│ ───> │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ ───> │▓▓│ │▓▓│ │▓▓│ ───> │░░│ │░░│ │░░│ │░░│ │░░│ │░░│ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ └──┘ file file file file read cache send tok tok tok tok tok tok file file file file read cache send tok tok tok tok tok tok

Benchmark

Nie ufaj.
Zweryfikuj.

Uruchom lean-ctx benchmark run w dowolnym projekcie. Rzeczywiste liczniki tokenów. Rzeczywiste metryki dokładności. Mierzone za pomocą tiktoken (o200k_base).

Rozpocznij Dodaj gwiazdkę na GitHubie

Jak to działa

Zmierzony. Zweryfikowany.

Benchmark działa lokalnie, liczy tokeny za pomocą dokładnego tokenizera i odrzuca kompresje, które spadają poniżej wymaganego poziomu jakości.

Dokładny licznik tokenów

Liczenie przy użyciu tego samego tokenizera co nowoczesne LLM - bez szacunków, bez zgadywania.

tiktoken o200k_base

Strażnik jakości

Ocenia zachowanie AST, identyfikatory i strukturę linii. Nieudane wyjścia są automatycznie blokowane.

próg: Q ≥ 95% · ρ ≥ 15%

Powtarzalne

Działa na Twoim repozytorium. Te same dane wejściowe → te same liczby. Idealne do CI i regresji.

offline · deterministyczne

Zobacz różnicę

Przed & Po

Ten sam plik. Te same informacje. Dramatycznie mniej tokenów.

Bez LeanCTX

// src/auth.ts · mode=full

import { jwt, verify, sign } from 'jsonwebtoken';

import { bcrypt } from 'bcryptjs';

…

3,517 tokenów

Z LeanCTX (tryb mapowania)

// src/auth.ts · mode=map

exports: AuthService, validateToken, …

deps: jsonwebtoken, bcryptjs, ioredis

…

412 tokenów

O 88% mniej tokenów

Trzy kroki do zweryfikowanych oszczędności

Wskaż. Pomiaruj. Zweryfikuj.

Wskaż dowolny plik lub katalog

Przekaż pojedynczy plik, katalog lub wzorzec glob. Silnik benchmarkowy przetworzy wszystko, co znajdzie.

lean-ctx benchmark run src/

Dokładny pomiar tokenów

Wykorzystuje tiktoken z kodowaniem o200k_base (takim samym jak GPT-4o, Claude i nowoczesne LLM). Bez oszacowań - rzeczywiste liczniki tokenów.

tiktoken o200k_base

Oszczędność na tryb

Uzyskaj wyniki dokładności i procenty oszczędności dla każdego trybu kompresji. Wybierz odpowiedni tryb dla każdego przypadku użycia.

modes: 10

Rzeczywisty wynik

Benchmark w akcji

Uruchom benchmark na dowolnym pliku w swoim projekcie. Wynik pokazuje dokładne liczniki tokenów dla każdego trybu kompresji, procent oszczędności oraz wyniki zachowania jakości.

Podział według plików - tokeny przed i po każdym trybie

Wyniki jakości - Zachowane AST, identyfikatory i linie kodu

Zsumowane sumy - Oszczędności dla całego katalogu z rekomendacją najlepszego trybu

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

Wybierz odpowiedni tryb dla każdego zadania

Tryby czytania W porównaniu do

full 0%

Pliki, które edytujesz

Wszystko - pełna zawartość jest buforowana do ponownego odczytu przy ~13 tokenach

map 70-90%

Tylko pliki kontekstowe

Kod: deps + exports + sygnatury. Nie-kod: ustrukturyzowane zarysy (nagłówki Markdown, klucze JSON/YAML/TOML, podsumowania blokad)

signatures 55–93%

Eksploracja powierzchni API

Tylko sygnatury funkcji/klasy/typu

diff 80–95%

Po edycjach

Zmienione linie z minimalnym otaczającym kontekstem

aggressive 75–90%

Duże pliki boilerplate'owe

Struktura i logika, usunięty składnia

entropy 70–83%

Pliki z szumem (JSDoc, komentarze)

Tylko linie o wysokiej entropii (filtracja Shannon + Jaccard)

task 65–85%

Odczyty skoncentrowane na zadaniu (np. 'napraw błąd uwierzytelniania')

Kod istotny dla zadania + kontekst zależności za pomocą Knowledge Graph + filtr IB

auto 70–99%

Domyślny - LeanCTX automatycznie wybiera najlepszy tryb

Adaptuje się do pliku: typ, przedział rozmiaru, aktualność, istotność zadania

reference 80–95%

Dokumentacja API i wyszukiwanie referencyjne

Publiczny API, typy, sygnatury, docstrings

lines:N-M 90–99%

Odczyt określonego zakresu linii - chirurgiczna precyzja

Dokładnie żądane linie, plus minimalny otaczający kontekst

LeanCTX's ctx_smart_read od LeanCTX automatycznie wybiera optymalny tryb, używając predykcji Bayesa na podstawie typu pliku, rozmiaru i kontekstu.

Etap

Zaawansowany potok kompresji

Poza wyborem trybu, LeanCTX stosuje wieloetapowy potok optymalizacji, który adaptuje się do typu pliku, kontekstu sesji i intencji zadania:

Thompson Sampling 5–15%

Uczy się optymalnych progów kompresji dla każdego typu pliku za pomocą eksploracji wieloramiennego bandyta (eksploracja vs wykorzystanie)

AST Pruning 40–70%

Pruning świadomy języka za pomocą Tree-sitter - usuwa ciała funkcji, komentarze i kod powtarzalny, zachowując jednocześnie sygnatury API

IDF Dedup 10–30%

Deduplikacja między plikami za pomocą odwrotnej częstotliwości dokumentu - eliminuje zawartość już widoczną w sesji

IB Filter 15–25%

Filtrowanie świadome zadania przy użyciu zasady wąskiego gardła informacji (Information Bottleneck) - zachowuje tylko treść istotną dla bieżącego zadania

Verbatim Compaction 5–20%

Kolapsuje powtarzające się struktury (importy, linie logów, kod powtarzalny) do zliczanych podsumowań

Te etapy są kumulatywne - stosowane sekwencyjnie, mogą zmniejszyć plik o 1000 linii do mniej niż 50 tokenów, zachowując jednocześnie wszystkie informacje istotne dla zadania. Potok jest w pełni automatyczny i nie wymaga konfiguracji.

Zweryfikowana konserwacja

Kompresja Jakość

Próg jakości (ogólny)

95%

Kompresowany wynik jest używany tylko wtedy, gdy ogólny wynik jakości pozostaje na poziomie 95% lub wyższym.

Minimalna gęstość

15%

Blokuje niskoinformatywny wynik przy minimalnej gęstości sygnału wynoszącej 15% (ρ).

Ważenie

50/30/20

Składnik = AST 50% + identyfikatory 30% + linie 20% - więc struktura jest najważniejsza.

Zasada gęstości informacji

Dlaczego mniej tokenów = Wyższa gęstość sygnału

LLM mają stały budżet uwagi. Każdy token w oknie kontekstowym konkuruje o wagi uwagi. Wypełnianie okna boilerplate'em oznacza mniejszą uwagę na kod, który ma znaczenie.

Usuwając szum przed dotarciem do modelu, LeanCTX zwiększa gęstość informacji każdego żądania. Wynik: wyższy stosunek sygnału do szumu, mniejsze rozcieńczenie kontekstu i model pozostaje w użytecznych granicach kontekstu.

Wyższy stosunek sygnału do szumu

10K tokenów skoncentrowanego kontekstu przewyższa 200K kodu powtórzeniowego. Model skupia swoją uwagę na logice, a nie na komentarzach JSDoc i kodzie importowym.

Zredukowany szum kontekstu

Szum kontekstowy rozwadnia okno uwagi modelu. Usunięcie go pomaga modelowi pozostać osadzonym w rzeczywistej strukturze kodu i zmniejsza szansę na halucynacje.

Niższy koszt odpowiedzi

Mniej tokenów wejściowych oznacza niższe koszty API i więcej wiadomości w ramach limitu żądań. Ten sam limit idzie dalej – za każdy użyty przez Ciebie narzędzie AI.

Przykłady z prawdziwego świata

Zmierzono na Prawdziwy kod

Reprezentatywne migawki - Twoje liczby będą się różnić w zależności od pliku i bazy kodu.

Komponent Reacta 88%

450 linii - tryb mapowania

12,840 → 1,541

Moduł Rust 93%

820 linii - tryb sygnatur

18,290 → 1,280

API Express 91%

1,200 linii - agresywny tryb

31,500 → 2,835

Pipeline ML w Pythonie 83%

680 linii - tryb entropii

15,400 → 2,618

Konfiguracja TypeScript 95%

340 linii - tryb różnicowania

8 750 → 437

Przejrzystość

Benchmark
Metodologia

Każda liczba na tej stronie jest powtarzalna. Oto dokładnie, jak mierzymy.

Tokenizer

Wszystkie liczniki tokenów używają tiktoken z kodowaniem o200k_base, ten sam tokenizer co GPT-4o, Claude i nowoczesne LLM. Bez szacunków ani przybliżeń.

Próg Jakości

Kompresowany wynik jest używany tylko wtedy, gdy złożony wynik jakości pozostaje na poziomie 95% lub wyższym. Złożone = zachowanie AST (50%) + zachowanie identyfikatorów (30%) + pokrycie linii (20%).

Powtórz Lokalnie

Uruchom lean-ctx benchmark run src/ na własnej bazie kodu. Wynik pokazuje dokładne liczniki tokenów dla każdego trybu kompresji, procent oszczędności i wyniki zachowania jakości.

Zastrzeżenie

Wyniki różnią się w zależności od typu pliku, rozmiaru, języka i trybu czytania. Zakres "60-99%" odzwierciedla zmienność w świecie rzeczywistym: małe strukturalne pliki kompresują się bardziej, duże nieustrukturyzowane pliki kompresują się mniej. Buforowane ponowne odczyty (~13 tokenów) reprezentują najlepszy przypadek.

Our Own Overhead, Measured

Savings claims must be net of what LeanCTX itself injects. The fixed per-session footprint (advertised tool schemas + MCP instructions) is ~2.1K tokens, measured in an isolated environment with lean-ctx doctor overhead and enforced in CI via --gate — it can only shrink. lean-ctx gain reports savings net of this overhead.

Deterministic Self-Verify

lean-ctx benchmark dual-arm --json replays a pinned 15-turn agent session through a stateless arm and the long-lived proxy rail, prices both with real tokenizer counts and published per-model rates, and fingerprints the run with a BLAKE3 digest — anyone can reproduce the exact figures, no live model needed.

Zmierz swoje rzeczywiste oszczędności.

Zainstaluj LeanCTX i uruchom benchmark run na swojej bazie kodu. Rzeczywiste liczby, Twoje pliki, Twoje oszczędności.

lean-ctx benchmark run src/

Działa na dowolnej bazie kodu. Nie wymaga konfiguracji. Wyniki w sekundach.

Rozpocznij Dodaj gwiazdkę na GitHubie

Nie ufaj.Zweryfikuj.

Zmierzony. Zweryfikowany.

Dokładny licznik tokenów

Strażnik jakości

Powtarzalne

Przed & Po

Wskaż. Pomiaruj. Zweryfikuj.

Wskaż dowolny plik lub katalog

Dokładny pomiar tokenów

Oszczędność na tryb

Benchmark w akcji

Tryby czytania W porównaniu do

Zaawansowany potok kompresji

Kompresja Jakość

Dlaczego mniej tokenów = Wyższa gęstość sygnału

Zmierzono na Prawdziwy kod

BenchmarkMetodologia

Tokenizer

Próg Jakości

Powtórz Lokalnie

Zastrzeżenie

Our Own Overhead, Measured

Deterministic Self-Verify

Zmierz swoje rzeczywiste oszczędności.

Nie ufaj.
Zweryfikuj.

Benchmark
Metodologia