我在 Cursor 里用了 10.51 亿 Token
2026-05-19T12:00:00+08:00
Cursor 按次计费要结束的时候，我把自己 2026 年 3 月 1 日到 5 月 19 日的 Usage Events 拉出来算了一遍。
结果比我预期夸张：只算 Cursor 这一条工作流，80 天里总吞吐是 1,051,066,111 Token。
这个数字不是我全部 AI 使用量。同期我还在用其他工具，但没有放进这次统计。这里讨论的只是 Cursor 里能从 Usage Events 看到的会话、请求、缓存读取、缓存写入和输出。
我想看的问题更具体：一个开发者长期用大上下文写代码，真实 token 结构会长什么样？按量计费之后，哪些习惯会变贵，哪些习惯反而应该保留？
统计口径
这次合并了 3 张 Cursor Usage Events 表，时间范围是 2026 年 3 月 1 日到 2026 年 5 月 19 日。
核心数据如下：
| 指标 | 数值 |
|---|---|
| 会话事件 | 627 组 |
| 子请求调用 | 1,225 次 |
| 总吞吐 Token | 1,051,066,111 |
| 缓存写入相关输入 | 52,728,641 Token |
| 非缓存写入输入 | 16,064,432 Token |
| 缓存读取 | 975,319,449 Token |
| 输出 Token | 6,953,589 Token |
这组数据里，9.75 亿 Token 来自缓存读取，比 10.51 亿这个总数更影响成本。大上下文不一定等于每次都重新付一遍成本，关键看你有没有复用同一段上下文。
单次上下文为什么这么大
这 627 组会话事件里，单次平均上下文是 2,043,513 Token，中位数也有 1,137,630 Token。
这和我的用法有关。我很少只问“帮我写个函数”这种单点问题。更多时候，我会让 Cursor 带着 Codebase 索引和相关文件，直接处理跨模块修改、复杂 bug、重构和联调。
这种方式第一次载入会很重，但好处也明显：模型能看到更多上下文，少猜文件关系，少来回追问。对大型项目来说，这比手工把一段段代码贴给 AI 更接近真实开发。
代价是，如果没有缓存，账单会很难看。
模型选择的变化
3 月我还在控制模型成本，Sonnet 和 Opus 混着用：
| 月份 | 模型调用分布 |
|---|---|
| 2026 年 3 月 | Sonnet Medium-Thinking：118 次（61.1%） Opus High-Thinking：75 次（38.9%） |
| 2026 年 4 月 | Claude 4.6 Opus High-Thinking：262 次（100%） |
| 2026 年 5 月（截至 19 日） | Claude 4.6 Opus High-Thinking：171 次（100%） |
到了 4 月，我基本把 Cursor 里的主力开发都切到了 Opus。原因很简单：复杂项目里，强模型少犯一次错，可能就省下一两个小时的人工排查。
这不代表所有任务都该用最贵模型。小改动、局部脚本、明确 bug 修复，便宜模型完全够用。但在跨文件重构、业务链路梳理、历史包袱很多的项目里，模型质量会直接影响返工量。
缓存命中率才是重点
这次统计里，整体缓存命中率是 93.31%。
| 时间范围 | 缓存命中率 |
|---|---|
| 整体 | 93.31% |
| 2026 年 3 月 | 90.85% |
| 2026 年 4 月 | 93.94% |
| 2026 年 5 月 | 94.38% |
这组数据解释了为什么我敢用这么大的上下文。
我的习惯是：处理一个核心功能时，不频繁开新 Chat，不轻易清空上下文。先把相关代码、约束和目标放进去，后面围绕同一个会话持续迭代。第一次写入很重，后面的追问、修正、补测试，大部分都能吃到缓存。
按量计费之后，这个习惯反而更重要。不是说永远不要开新会话，而是不要因为一点小分支就重建完整上下文。能在同一个目标下连续推进，就不要反复让模型重新认识项目。
最大的一次调用
这段时间里，最大的一次事件发生在 2026 年 5 月 7 日 14:46：
- 单次总上下文：20,381,233 Token
- 缓存读取：19,516,684 Token
- 缓存率：95.76%
- 输出：83,968 Token
那次任务是一次跨模块重构。要求是不破坏原有微服务通信协议，同时调整几个核心模块的数据流。Cursor 在后台检索和修改了几十个文件，最后一次性输出了接近 8.4 万 Token 的代码。
这类任务如果完全手工做，也能做，但会非常慢。AI 的价值不只是“写得快”，而是它能在同一轮里同时对齐接口、依赖、历史逻辑和修改范围。前提是你给它足够清楚的目标和上下文。
从日志看工作节奏
这份日志还顺手暴露了我的工作节奏。
从星期分布看，调用主要集中在周一到周四，周六很少，周日为 0。
| 星期 | 调用次数 | 节奏 |
|---|---|---|
| 周一 | 288 次 | 启动和推进 |
| 周二 | 355 次 | 最密集 |
| 周三 | 254 次 | 联调和落地 |
| 周四 | 219 次 | 继续迭代 |
| 周五 | 98 次 | 收尾和检查 |
| 周六 | 11 次 | 很少 |
| 周日 | 0 次 | 没有调用 |
按小时看，主要集中在两个时间段：
- 10:00 - 12:00：316 次调用，通常是理顺问题和开始动手。
- 14:00 - 19:00：741 次调用，占全天调用的 60.49%，大部分重构和联调都在这个时段。
这对我有个提醒：AI 并没有把工作变成 24 小时在线。它更像是把高强度开发压缩到白天几个集中的时间段里。晚上不碰，周末不碰，反而更容易保持节奏。
按量计费后怎么用
如果 Cursor 进入按量计费，最应该调整的不是“少用 AI”，而是少浪费上下文。
我会保留这几个习惯：
- 少开无意义新会话。 同一个目标下连续推进，尽量复用缓存。
- 开始前写清任务范围。 相关文件、不能动的边界、验收标准先说清楚。
- 大任务先让 AI 给方案。 方案确认后再改代码，避免一次改偏二十个文件。
- 小任务用便宜模型。 明确、局部、低风险的活，不需要一直上最强模型。
- 长会话也要定期收束。 目标变了就开新会话，不要把不同任务硬塞到一起。
这 10.51 亿 Token 对我最大的意义，不是证明“用得多”，而是让我看清了一件事：大上下文开发真正贵的地方，不是上下文本身，而是反复重建上下文、目标不清、让模型在错误方向上跑很久。
缓存命中率高的时候，大上下文是优势。目标不清的时候，大上下文只是把浪费放大。