以下是 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 工具｡

• 保持规则专注｡

• 让任务具体且集中｡

• 为每个新任务开启一个新的聊天｡

模型选择:

• 在高级模型中gpt-5的价格相比他们模型便宜50%

• 对于日志检查或代码分析等基本任务，使用更简单的模型 (Auto)｡

• 仅在需要处理复杂编码时使用更强的模型 (例如 Sonnet)｡

• “思考” 型模型比标准模型使用更多的 token｡

• 当强模型不足以满足需求时，尝试重新技术选型规划再执行｡

注意:

在聊天过程中更换 AI 提供商或模型可能会增加 token 使用量，因为新的提供商没有缓存之前的聊天步骤，必须将它们作为新的输入进行处理｡为了获得最佳效果，请在新的聊天中更换模型或提供商｡