信じるな。
検証せよ。
任意のプロジェクトでlean-ctx benchmark runを実行。実際のtoken数。実際の精度指標。tiktoken（o200k_base）で計測。
測定。 検証。
ベンチマークはローカル実行で正確にトークンを数え、品質しきい値を下回る圧縮は採用しません。
正確なトークン数
最新 LLM と同じ tokenizer で計測 - 推測なし。
tiktoken o200k_base 品質ガード
AST、識別子、行構造をスコア化し、基準未満の出力は自動でブロックします。
しきい値: Q ≥ 95% · ρ ≥ 15% 再現性
あなたのリポジトリで実行。入力が同じなら数値も同じ。CI と回帰検知に最適。
オフライン · 決定的 Before & After
The same file. The same information. Dramatically fewer tokens.
88% fewer tokens
仕組み について
任意のファイルまたはディレクトリを指定
単一ファイル、ディレクトリ、またはグロブパターンを指定できます。ベンチマークエンジンが見つけたすべてを処理します。
lean-ctx benchmark run src/ 正確なtoken計測
tiktokenのo200k_baseエンコーディング（GPT-4o、Claude、最新のLLMと同じ）を使用。推定値ではなく、実際のtoken数です。
tiktoken o200k_base モード別の節約量
すべての圧縮モードの精度スコアと節約率を取得。ユースケースに最適なモードを選択できます。
modes: 10 ベンチマーク の実例
プロジェクト内の任意のファイルでベンチマークを実行できます。各圧縮モードの正確なtoken数、節約率、品質保持スコアが出力されます。
ファイル別の内訳 - 各モードの圧縮前後のtoken数
品質スコア - AST、識別子、コード行の保持率
集計結果 - ディレクトリ全体の節約量と最適モードの推奨
$ 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
読み取りモード の比較
full 0% 編集するファイル
すべて - 完全な内容をcacheし、再読み込みは約13 tokenで完了
map 70–88% コンテキスト参照用ファイル
依存関係グラフ、エクスポート、主要なシグネチャ
signatures 55–93% API サーフェスの調査
関数/クラス/型のシグネチャのみ
diff 80–95% 編集後
最小限の周辺コンテキストを含む変更行
aggressive 75–90% 大規模なボイラープレートファイル
構造とロジックを保持、構文を除去
entropy 70–83% ノイズの多いファイル（JSDoc、コメント）
高エントロピー行のみ（Shannon + Jaccard フィルタリング）
task 65–85% タスク重視の読み取り（例：'auth バグを修正'）
タスク関連コード + ナレッジグラフ + IBフィルターによる依存関係コンテキスト
auto 70–99% デフォルト - lean-ctx が最適なモードを自動選択
ファイル単位で適応：種類、サイズバケット、更新度、タスク関連性
reference 80–95% API ドキュメント／リファレンス参照
公開 API、型、シグネチャ、docstring
lines:N-M 90–99% 指定行範囲の読み取り - 外科的な精度
指定された行と最小限の周辺コンテキスト
lean-ctxのctx_smart_readは、ファイルの種類、サイズ、コンテキストに基づくベイズ予測で最適なモードを自動選択します。
Advanced Compression Pipeline
Beyond mode selection, lean-ctx applies a multi-stage optimization pipeline that adapts to file type, session context, and task intent:
Learns optimal compression thresholds per file type using multi-armed bandit exploration (explore vs exploit)
Language-aware pruning via Tree-sitter - removes function bodies, comments, and boilerplate while preserving API signatures
Cross-file deduplication using inverse document frequency - eliminates content already seen in the session
Task-aware filtering using the Information Bottleneck principle - keeps only content relevant to the current task
Collapses repetitive structures (imports, log lines, boilerplate) into counted summaries
These stages are cumulative - applied in sequence, they can reduce a 1000-line file to under 50 tokens while preserving all task-relevant information. The pipeline is fully automatic and requires no configuration.
圧縮 品質
品質しきい値（composite）
圧縮結果は composite 品質スコアが 95% 以上のときだけ採用されます。
最小密度
情報量の少ない出力を、最小シグナル密度 15%（ρ）でブロックします。
重み付け
Composite = AST 50% + 識別子 30% + 行 20% - 構造が最重要です。
少ないtokenが = 高いシグナル密度をもたらす理由
LLMの注意予算は固定されています。コンテキストウィンドウ内のすべてのtokenが注意の重みを競い合います。ウィンドウをボイラープレートで埋めると、重要なコードへの注意が減少します。
モデルに到達する前にノイズを除去することで、lean-ctxはリクエストごとの情報密度を高めます。結果：より高いシグナル対ノイズ比、コンテキスト希薄化の削減、モデルが有効なコンテキスト制限内に留まります。
集中した10K tokenのコンテキストは、200Kのボイラープレートを上回ります。モデルはJSDocコメントやインポートのボイラープレートではなく、ロジックに注意を集中します。
コンテキストノイズはモデルの注意ウィンドウを希薄化します。ノイズを除去することで、モデルは実際のコード構造に集中し、ハルシネーションのリスクが軽減されます。
入力tokenが少なくなれば、APIコストが下がり、レート制限内でより多くのメッセージを送信できます。使用するすべてのAIツールで、同じ割り当てがより長く続きます。
Measured on Real Code
代表的なスナップショットです。数値はファイルやコードベースにより変動します。
450 lines - map mode
12,840 → 1,541 820 lines - signatures mode
18,290 → 1,280 1,200 lines - aggressive mode
31,500 → 2,835 680 lines - entropy mode
15,400 → 2,618 340 lines - diff mode
8,750 → 437 Benchmark
Methodology
Every number on this page is reproducible. Here's exactly how we measure.
Tokenizer
All token counts use tiktoken with the o200k_base encoding — the same
tokenizer used by GPT-4o, Claude, and modern LLMs. No estimates or approximations.
Quality Threshold
Compressed output is only used if the composite quality score stays at or above 95%. Composite = AST preservation (50%) + identifier preservation (30%) + line coverage (20%).
Reproduce Locally
Run lean-ctx benchmark run src/ on your own codebase. The output shows exact token counts
for each compression mode, savings percentage, and quality preservation scores.
Disclaimer
Results vary by file type, size, language, and read mode. The "60-99%" range reflects real-world variance: small structured files compress more, large unstructured files compress less. Cached re-reads (~13 tokens) represent the best case.
あなたの 実際の節約を測定しましょう。
lean-ctxをインストールし、benchmark runをあなたのコードベースで実行してください。実際の数値、あなたのファイル、あなたの節約。
lean-ctx benchmark run src/ Works on any codebase. No config needed. Results in seconds.