Cursor官方的Token计费原理明细，也适用于其他按量付费的AI编程工具，分享给大家
最有用的技巧我帮你标黄了，赶时间可以直接看高亮内容
话说，现在的Cursor用起来就像开电车，一天天精打细算把格局开小了，整个人都变得抠搜了。
以下是 Cursor 中 LLM（AI）Token 使用的详细说明：
每次在 Cursor 中与 AI 模型交互时都会使用 Token。为了透明化，Token 数量会显示为 AI 提供者处理和报告的数量。
您可以在 Dashboard > Usage 中查看您的使用情况，如果您有基于使用的定价，也可以在 Dashboard > Billing 中查看。
仪表板正在改进中，以便在一条线上显示单个请求的所有 AI 使用情况，即使多个工具调用被组合在一起。
token被分为四组：
• 输入token： 原始用户请求，包括附加的规则、文件和 MCPs……输入token进一步分为：
带缓存写入的输入： 需要缓存以高效处理后续步骤的信息。
无缓存写入的输入： 仅用于单个步骤且未缓存的信息。
• 输出 token： AI 的响应，例如代码、聊天回复和工具调用结果。
• 缓存写入 token： 保存到 AI 提供者的临时缓存中的消息和工具调用结果，以提高未来请求的效率。
• 缓存读取 token： 在后续步骤中用于生成新的 AI 输出的缓存 token（聊天历史和上下文）。这些 token 更便宜，通常成本约为输入 token 的 10-25%。
每个token组根据提供者 API 成本 * 1.2 进行计数和计价，并显示总token数。
请求的流程：
1. 您的初始请求连同上下文被作为输入token发送。
2. AI 处理输入并生成输出（输出token）。
3. 工具调用可能会被触发，例如读取文件或搜索代码。这些调用会使用当前上下文，并向上下文中添加更多token。
4. 每个工具调用的响应都会被缓存，增加缓存的大小。
5. 如果需要更多步骤，则重复该过程：发送新的输入，生成更多输出，并可能发生额外的工具调用。
6. 聊天中的后续请求工作原理相同。每一步都会增加缓存，随着上下文的增长，缓存读取的 token 会累积。
示例：
• 一个请求开始时有 5,000 个输入 token，这些 token 被处理并缓存。
• 一个工具调用使用了缓存的上下文，并增加了另外 5,000 个 token，这些 token 也会被缓存。
• 经过两步操作，缓存中有 10,000 个 token。当这些 token 在下一轮 API 调用中用于 AI 提供者时，它们会被计为缓存读取 token，并享受较低的成本（10-25%的输入 token 价格，具体取决于提供者）。
如果你看到高 token 计数：
• 输入 token： 附加了过多的上下文（规则、文件等）。通过删除不必要的部分来减少。
• 输出 token： AI 的响应很大。如果可能，请限制输出。
• 缓存写入 token： 很多上下文正在被处理和缓存。简化您的指令和附件。
• 缓存读取 token： 这些随着长或复杂的聊天而增加，因为上下文随着每一步而增长。对于包含多个工具调用和后续请求的聊天来说，这是正常的，但可以通过为新的任务开始新的聊天来减少。
减少 token 使用的技巧：
• 仅附加必要内容；现代人工智能能高效获取相关代码。
• 仅启用您需要的 MCP 工具。
• 保持规则简短且专注。
• 让任务具体且集中。
• 为每个新任务开启一个新的聊天。
模型选择：
• 对于日志检查或代码分析等基本任务，使用更简单的模型（Auto）。
• 仅在需要处理复杂编码时使用更强的模型（例如 Sonnet）。
• “思考”型模型比标准模型使用更多的 token。
• 当强模型不足以满足需求时，使用最强的模型（例如 Opus）。
注意： 在聊天过程中更换 AI 提供商或模型可能会增加 token 使用量，因为新的提供商没有缓存之前的聊天步骤，必须将它们作为新的输入进行处理。为了获得最佳效果，请在新的聊天中更换模型或提供商。
