Cursor浪费了 你的令牌。
Agent 模式重复读取所有内容
每次 Agent 运行时都会将相同的文件重新输入窗口。一个 4,200 token 的模块成本就是 4,200 个 tokens。每一次都是。
长时间会话性能下降
随着上下文窗口被原始文件转储填满,补全功能变得更慢、不准确。Context-rot 研究测量了准确率从 98% 下降到 64%。
终端输出是冗余信息
Cargo 构建、npm 安装和测试运行会用模型从未需要的进度条淹没对话。
LeanCTX如何接入 Cursor.
MCP 服务器,自动配置
lean-ctx setup 将 MCP 条目写入 Cursor 的配置文件。Cursor 的 Agent 然后调用 ctx_read、ctx_search 和 ctx_shell 而不是原始读取。
包含规则文件
设置安装了一个 .cursor/rules 映射,使代理自动偏好压缩工具。无需任何提示词约束。
会话缓存底层
Cursor 已读取的文件作为约 13 个 token 的缓存命中返回。缓存会在修改时失效,因此代理永远不会看到过时的代码。
一条命令。 自动检测。
三个时刻 你会注意到。
零成本的重读
你的代理重新访问了一个它一小时前探索过的文件。不再是 4,200 个 token:而是 13 个 token 的缓存命中。窗口全天保持精简。
可读性高的构建
cargo build 输出以错误和结果的形式到达:847 个 token 变为 42 个。你的对话始终围绕代码展开。
收益报告
lean-ctx 的收益显示了今天节省的精确量,来自本地签名账本而非估算。
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 检索到。