用于Cursor的LeanCTX

Cursor 读取您的仓库
就像零成本一样。

通过 MCP 提供压缩的、AST 感知的上下文,LeanCTX 将 Cursor 的 Token 用量减少了 60–90%:ctx_read 返回映射和签名而不是完整文件,缓存重读成本约为 ~13 个 token,shell 输出缩小了 88–99%。运行 lean-ctx setup 一次,Cursor 会自动检测并配置。

问题所在

Cursor浪费了 你的令牌。

Agent 模式重复读取所有内容

每次 Agent 运行时都会将相同的文件重新输入窗口。一个 4,200 token 的模块成本就是 4,200 个 tokens。每一次都是。

长时间会话性能下降

随着上下文窗口被原始文件转储填满,补全功能变得更慢、不准确。Context-rot 研究测量了准确率从 98% 下降到 64%。

终端输出是冗余信息

Cargo 构建、npm 安装和测试运行会用模型从未需要的进度条淹没对话。

集成

LeanCTX如何接入 Cursor.

01

MCP 服务器,自动配置

lean-ctx setup 将 MCP 条目写入 Cursor 的配置文件。Cursor 的 Agent 然后调用 ctx_read、ctx_search 和 ctx_shell 而不是原始读取。

02

包含规则文件

设置安装了一个 .cursor/rules 映射,使代理自动偏好压缩工具。无需任何提示词约束。

03

会话缓存底层

Cursor 已读取的文件作为约 13 个 token 的缓存命中返回。缓存会在修改时失效,因此代理永远不会看到过时的代码。

Setup

一条命令。 自动检测。

# 安装 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 的收益显示了今天节省的精确量,来自本地签名账本而非估算。

FAQ

Cursor + LeanCTX,解答一切。

如何减少 Cursor 的 token 使用量?

安装 LeanCTX 并运行 lean-ctx setup。Cursor 已自动检测:代理获得 MCP 工具,这些工具返回压缩、AST 感知的上下文(每次读取的 token 减少 60–90%)和约 13 个 token 的缓存重读。无需更改工作流程。

LeanCTX 是否适用于 Cursor 的代理模式和后台代理?

是的。任何使用 MCP 的 Cursor 功能都使用相同的 lean-ctx 服务器:代理模式、后台代理和聊天都受益于相同的缓存和压缩。

压缩的上下文会使 Cursor 的回答变差吗?

通常相反:AST 感知的模式在丢弃噪声的同时保留了签名和结构,而上下文衰减研究表明随着窗口填充,准确性会下降。每当需要完整细节时,原始信息都可以通过 ctx_retrieve 检索到。

工作中使用?

Team 为您的整个组织提供一个共享、审计的上下文平面,账本证明了为财务部门节省的成本。本地使用永久免费,由 CI 强制执行。