Benchmark

Ne faites pas confiance.
Vérifiez.

Exécutez lean-ctx benchmark run dans n'importe quel projet. Comptes de tokens réels. Métriques de précision réelles. Mesuré avec tiktoken (o200k_base).

Comment il reste honnête

Mesuré. Vérifié.

Les benchmarks s'exécutent localement, comptent les tokens avec le tokenizer exact et rejettent les compressions qui tombent sous le seuil de qualité.

Nombre exact de tokens

Compte avec le même tokenizer utilisé par les LLM modernes - pas d'estimations, pas de suppositions.

tiktoken o200k_base

Garantie de qualité

Évalue la préservation de l'AST, les identifiants et la structure des lignes. Les sorties échouées sont bloquées automatiquement.

seuil : Q ≥ 95 % · ρ ≥ 15 %

Reproductible

S'exécute sur votre dépôt. Mêmes entrées → mêmes chiffres. Idéal pour l'intégration continue et les régressions.

hors ligne · déterministe
Voir la différence

Avant et Après

Le même fichier. La même information. Beaucoup moins de tokens.

Sans LeanCTX
// src/auth.ts · mode=full
import { jwt, verify, sign } from 'jsonwebtoken';
import { bcrypt } from 'bcryptjs';
3 517 tokens
Avec LeanCTX (mode map)
// src/auth.ts · mode=map
exports: AuthService, validateToken, …
deps: jsonwebtoken, bcryptjs, ioredis
412 tokens

88 % de tokens en moins

Trois étapes pour des économies vérifiées

Désignez. Mesurez. Vérifiez.

01

Désignez n'importe quel fichier ou répertoire

Passez un seul fichier, un répertoire ou un modèle glob. Le moteur de benchmark traite tout ce qu'il trouve.

lean-ctx benchmark run src/
02

Mesure exacte des tokens

Utilise tiktoken avec l'encodage o200k_base (identique à GPT-4o, Claude et les LLM modernes). Pas d'estimations - des comptes de tokens réels.

tiktoken o200k_base
03

Économies par mode

Obtenez les scores de précision et les pourcentages d'économies pour chaque mode de compression. Choisissez le bon mode pour chaque cas d'utilisation.

modes: 10
Sortie réelle

Benchmark en Action

Exécutez le benchmark sur n'importe quel fichier de votre projet. La sortie affiche les décomptes exacts de tokens pour chaque mode de compression, le pourcentage d'économies et les scores de préservation de la qualité.

Répartition par fichier - tokens avant et après chaque mode

Scores de qualité - AST, identifiants et lignes de code préservés

Totaux agrégés - économies à l'échelle du répertoire avec recommandation du meilleur mode

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

Choisissez le bon mode pour chaque tâche

Modes de lecture Comparés

full 0%

Fichiers que vous allez modifier

Tout - contenu complet mis en cache pour les relectures à ~13 tokens

map 70-90%

Fichiers de contexte uniquement

Code : dépendances + exports + signatures. Non-code : plans structurés (titres Markdown, clés JSON/YAML/TOML, résumés de verrouillage)

signatures 55–93%

Exploration de la surface d'API

Signatures de fonctions/classes/types uniquement

diff 80–95%

Après modifications

Lignes modifiées avec un contexte minimal environnant

aggressive 75–90%

Grands fichiers boilerplate

Structure et logique, syntaxe dépouillée

entropy 70–83%

Fichiers bruyants (JSDoc, commentaires)

Lignes à haute entropie uniquement (filtrage Shannon + Jaccard)

task 65–85%

Lectures axées sur la tâche (par ex. 'corriger un bug d'authentification')

Code pertinent pour la tâche + contexte de dépendance via Knowledge Graph + filtre IB

auto 70–99%

Défaut - LeanCTX choisit automatiquement le meilleur mode

S'adapte par fichier : type, catégorie de taille, fraîcheur, pertinence de la tâche

reference 80–95%

Documentation d'API et recherche de référence

API publique, types, signatures, docstrings

lines:N-M 90–99%

Lire une plage de lignes spécifique - précision chirurgicale

Lignes exactes demandées, plus un contexte minimal environnant

LeanCTX's ctx_smart_read de LeanCTX sélectionne automatiquement le mode optimal en utilisant la prédiction bayésienne basée sur le type de fichier, la taille et le contexte.

Étape

Pipeline de Compression Avancé

Au-delà de la sélection du mode, LeanCTX applique un pipeline d'optimisation multi-étapes qui s'adapte au type de fichier, au contexte de session et à l'intention de la tâche :

Thompson Sampling 5–15%

Apprend les seuils de compression optimaux par type de fichier en utilisant l'exploration multi-armed bandit (exploration vs exploitation)

AST Pruning 40–70%

Élagage conscient du langage via Tree-sitter - supprime les corps de fonctions, les commentaires et le boilerplate tout en préservant les signatures d'API

IDF Dedup 10–30%

Dédoublonnage inter-fichiers utilisant la fréquence inverse de document - élimine le contenu déjà vu dans la session

IB Filter 15–25%

Filtrage conscient de la tâche utilisant le principe de la goulot d'étranglement informationnel - ne conserve que le contenu pertinent pour la tâche actuelle

Verbatim Compaction 5–20%

Réduit les structures répétitives (imports, lignes de log, boilerplate) en résumés comptés

Ces étapes sont cumulatives - appliquées séquentiellement, elles peuvent réduire un fichier de 1000 lignes à moins de 50 tokens tout en préservant toutes les informations pertinentes pour la tâche. Le pipeline est entièrement automatique et ne nécessite aucune configuration.

Préservation vérifiée

Compression Qualité

Seuil de qualité (composite)

95%

La sortie compressée n'est utilisée que si le score de qualité composite reste égal ou supérieur à 95 %.

Densité minimale

15%

Bloque la sortie à faible information avec une densité de signal minimale de 15 % (ρ).

Pondération

50/30/20

Composite = AST 50% + identifiants 30% + lignes 20% - la structure est donc primordiale.

Principe de densité d'information

Pourquoi Moins de Tokens = Densité de Signal Plus Élevée

Les LLM ont un budget d'attention fixe. Chaque token dans la fenêtre de contexte est en compétition pour les poids d'attention. Remplir la fenêtre avec du code passe-partout signifie moins d'attention sur le code qui compte.

En supprimant le bruit avant qu'il n'atteigne le modèle, LeanCTX augmente la densité d'information de chaque requête. Le résultat : un rapport signal/bruit plus élevé, moins de dilution de contexte, et le modèle reste dans des limites de contexte utiles.

Rapport signal/bruit plus élevé

10K tokens de contexte ciblé surpassent 200K de code passe-partout. Le modèle concentre son attention sur la logique plutôt que sur les commentaires JSDoc et le code d'importation passe-partout.

Bruit de contexte réduit

Le bruit de contexte dilue la fenêtre d'attention du modèle. Le supprimer aide le modèle à rester ancré dans la structure réelle du code et réduit les risques d'hallucination.

Coût par réponse réduit

Moins de tokens d'entrée signifient des coûts d'API réduits et plus de messages dans votre limite de taux. Le même quota va plus loin - pour chaque outil d'IA que vous utilisez.

Exemples concrets

Mesuré sur Du Code Réel

Instantanés représentatifs - vos chiffres varieront selon le fichier et la base de code.

Composant React 88%

450 lignes - mode map

12 840 → 1 541
Module Rust 93%

820 lignes - mode signatures

18 290 → 1 280
API Express 91%

1 200 lignes - mode agressif

31 500 → 2 835
Pipeline ML Python 83%

680 lignes - mode entropy

15 400 → 2 618
Configuration TypeScript 95%

340 lignes - mode diff

8 750 → 437
Transparence

Méthodologie
de Benchmark

Chaque chiffre de cette page est reproductible. Voici exactement comment nous mesurons.

Tokenizer

Tous les décomptes de tokens utilisent tiktoken avec l'encodage o200k_base, le même tokenizer utilisé par GPT-4o, Claude et les LLM modernes. Pas d'estimations ou d'approximations.

Seuil de Qualité

La sortie compressée n'est utilisée que si le score de qualité composite reste égal ou supérieur à 95%. Composite = préservation de l'AST (50%) + préservation des identifiants (30%) + couverture des lignes (20%).

Reproduire Localement

Exécutez lean-ctx benchmark run src/ sur votre propre base de code. La sortie affiche les décomptes exacts de tokens pour chaque mode de compression, le pourcentage d'économies et les scores de préservation de la qualité.

Avertissement

Les résultats varient selon le type de fichier, la taille, la langue et le mode de lecture. La plage "60-99%" reflète la variance du monde réel : les petits fichiers structurés se compressent davantage, les grands fichiers non structurés se compressent moins. Les relectures mises en cache (~13 tokens) représentent le meilleur cas.

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.

Mesurez vos économies réelles.

Installez LeanCTX et exécutez benchmark run sur votre base de code. Chiffres réels, vos fichiers, vos économies.

lean-ctx benchmark run src/

Fonctionne sur n'importe quelle base de code. Aucune configuration requise. Résultats en quelques secondes.