Agent 模式重复读取所有内容
每次 Agent 运行时都会将相同的文件重新输入窗口。一个 4,200 token 的模块成本就是 4,200 个 tokens。每一次都是。
问题所在
Cursor浪费了 你的令牌。
长时间会话性能下降
随着上下文窗口被原始文件转储填满，补全功能变得更慢、不准确。Context-rot 研究测量了准确率从 98% 下降到 64%。
终端输出是冗余信息
Cargo 构建、npm 安装和测试运行会用模型从未需要的进度条淹没对话。
Your stack. Your agent. Better context.
集成
LeanCTX如何接入 Cursor.
MCP 服务器，自动配置
lean-ctx setup 将 MCP 条目写入 Cursor 的配置文件。Cursor 的 Agent 然后调用 ctx_read、ctx_search 和 ctx_shell 而不是原始读取。
包含规则文件
设置安装了一个 .cursor/rules 映射，使代理自动偏好压缩工具。无需任何提示词约束。
会话缓存底层
Cursor 已读取的文件作为约 13 个 token 的缓存命中返回。缓存会在修改时失效，因此代理永远不会看到过时的代码。
Setup
一条命令。 自动检测。
terminal
# 安装 LeanCTX
$ curl -fsSL https://leanctx.com/install.sh | sh# 自动检测 Cursor 并配置 MCP + rules
$ lean-ctx setup# 验证连接
$ lean-ctx doctor# 在 Cursor 使用一天后：查看收据
$ lean-ctx gain变化点
三个时刻 你会注意到。
零成本的重读
你的代理重新访问了一个它一小时前探索过的文件。不再是 4,200 个 token：而是 13 个 token 的缓存命中。窗口全天保持精简。
可读性高的构建
cargo build 输出以错误和结果的形式到达：847 个 token 变为 42 个。你的对话始终围绕代码展开。
收益报告
lean-ctx 的收益显示了今天节省的精确量，来自本地签名账本而非估算。
Cursor + LeanCTX，解答一切。
安装 LeanCTX 并运行 lean-ctx setup。Cursor 已自动检测：代理获得 MCP 工具，这些工具返回压缩、AST 感知的上下文（每次读取的 token 减少 60–90%）和约 13 个 token 的缓存重读。无需更改工作流程。
是的。任何使用 MCP 的 Cursor 功能都使用相同的 lean-ctx 服务器：代理模式、后台代理和聊天都受益于相同的缓存和压缩。
通常相反：AST 感知的模式在丢弃噪声的同时保留了签名和结构，而上下文衰减研究表明随着窗口填充，准确性会下降。每当需要完整细节时，原始信息都可以通过 ctx_retrieve 检索到。
工作中使用？
Team 为您的整个组织提供一个共享、审计的上下文平面，账本证明了为财务部门节省的成本。本地使用永久免费，由 CI 强制执行。