基准测试

别轻信。
去验证。

在任意项目中运行 lean-ctx benchmark run。真实 token 计数。真实精度指标。使用 tiktoken (o200k_base) 测量。

为什么可信

实测。 验证。

基准测试在本地运行,用精确 tokenizer 计数,并拒绝低于质量门槛的压缩结果。

精确 token 计数

使用现代 LLM 相同 tokenizer 计数 - 不靠估算。

tiktoken o200k_base

质量护栏

对 AST、标识符与行结构评分,不合格输出会被自动阻止。

阈值: Q ≥ 95% · ρ ≥ 15%

可复现

在你的仓库上运行。相同输入 → 相同数字。适合 CI 与回归检测。

离线 · 确定性
See the difference

Before & After

The same file. The same information. Dramatically fewer tokens.

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

88% fewer tokens

三步验证节省效果

运作 原理

01

指向任意文件或目录

传入单个文件、目录或 glob 模式。基准测试引擎会处理找到的所有内容。

lean-ctx benchmark run src/
02

精确 token 测量

使用 tiktoken 的 o200k_base 编码(与 GPT-4o、Claude 及现代 LLM 相同)。非估算--真实 token 计数。

tiktoken o200k_base
03

各模式节省量

获取每种压缩模式的精度分数和节省百分比。为每个使用场景选择合适的模式。

modes: 10
真实输出

基准测试 实战演示

对项目中的任意文件运行基准测试。输出显示每种压缩模式的精确 token 数量、节省百分比和质量保留分数。

逐文件分解 --每种模式压缩前后的 token 数

质量分数 --AST、标识符和代码行的保留率

汇总统计 --目录级别的节省量及最佳模式推荐

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

为每个任务选择合适的模式

读取模式 对比

full 0%

您将要编辑的文件

完整保留--全部内容已缓存,重读仅需约 13 个 token

map 70–88%

仅需了解上下文的文件

依赖图、导出项和关键签名

signatures 55–93%

API 接口探索

仅保留函数/类/类型签名

diff 80–95%

编辑之后

仅保留变更行及最少的上下文

aggressive 75–90%

大型模板化文件

保留结构和逻辑,去除语法修饰

entropy 70–83%

噪声较多的文件(JSDoc、注释)

仅保留高熵行(Shannon + Jaccard 过滤)

task 65–85%

Task-focused reads (e.g. 'fix auth bug')

Task-relevant code + dependency context via Knowledge Graph + IB filter

auto 70–99%

默认 - lean-ctx 自动选择最佳模式

按文件自适应:类型、大小区间、最近性、任务相关性

reference 80–95%

API 文档与参考查询

公开 API、类型、签名、文档字符串

lines:N-M 90–99%

读取指定行范围 - 外科手术级精确

精确请求的行 + 最少周边上下文

lean-ctx 的 ctx_smart_read 会基于文件类型、大小和上下文,使用贝叶斯预测自动选择最优模式。

Stage

Advanced Compression Pipeline

Beyond mode selection, lean-ctx applies a multi-stage optimization pipeline that adapts to file type, session context, and task intent:

Thompson Sampling 5–15%

Learns optimal compression thresholds per file type using multi-armed bandit exploration (explore vs exploit)

AST Pruning 40–70%

Language-aware pruning via Tree-sitter - removes function bodies, comments, and boilerplate while preserving API signatures

IDF Dedup 10–30%

Cross-file deduplication using inverse document frequency - eliminates content already seen in the session

IB Filter 15–25%

Task-aware filtering using the Information Bottleneck principle - keeps only content relevant to the current task

Verbatim Compaction 5–20%

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.

经验证的保留度

压缩 质量

质量阈值(综合)

95%

只有当综合质量分数保持在 ≥ 95% 时,才会使用压缩输出。

最小密度

15%

以最小信号密度 15%(ρ)阻止低信息量输出。

权重

50/30/20

综合 = AST 50% + 标识符 30% + 行结构 20% -- 结构最重要。

信息密度原理

为什么更少的 Token = 更高的信号密度

LLM 的注意力预算是固定的。上下文窗口中的每个 token 都在争夺注意力权重。用模板代码填满窗口意味着真正重要的代码获得的注意力更少。

通过在到达模型之前去除噪声,lean-ctx 提高了每次请求的信息密度。结果是:更高的信噪比、更少的上下文稀释,模型始终处于有效的上下文范围内。

更高的信噪比

1 万个聚焦的 token 胜过 20 万个模板代码。模型将注意力集中在逻辑上,而非 JSDoc 注释和导入模板。

减少上下文噪声

上下文噪声会稀释模型的注意力窗口。去除噪声有助于模型专注于实际的代码结构,并降低产生幻觉的风险。

更低的单次回答成本

更少的输入 token 意味着更低的 API 成本,以及在速率限制内可发送更多消息。同样的配额能走得更远--适用于您使用的每一个 AI 工具。

Real-world examples

Measured on Real Code

代表性快照 - 你的数字会因文件与代码库而异。

React Component 88%

450 lines - map mode

12,840 → 1,541
Rust Module 93%

820 lines - signatures mode

18,290 → 1,280
Express API 91%

1,200 lines - aggressive mode

31,500 → 2,835
Python ML Pipeline 83%

680 lines - entropy mode

15,400 → 2,618
TypeScript Config 95%

340 lines - diff mode

8,750 → 437
Transparency

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.