Claude Pro 限额是怎么被消耗的？

Claude Pro 限额由哪些因素消耗

Anthropic 没有公布 Claude Pro 的 token 配额，因此没人能告诉您具体的 token 限额。哪些因素会消耗限额是可以确定的，而且更有参考价值：首先是对话长度，其次是附件和图片，然后是思考强度，最后是工具和代理任务。

token 是一段文本，大致相当于一个短单词或较长单词的一部分。您发送的每个请求都会按 token 计量，系统会在后台为您的套餐统计这些 token。Anthropic 的使用限额最佳实践页面列出了会影响统计量的因素：消息长度、文件附件大小、当前对话长度、Research 和网页搜索等工具的使用情况、模型选择、工作量级别，以及 artifact 创建。列表中的每项因素都会产生同样的影响。每项因素都会改变单个请求包含的 token 数量。

两个相邻的问题各有对应页面。Pro 套餐包含多少使用量介绍配额大小，以及为什么配额按会话而不是 token 描述。达到限额后该怎么办介绍恢复使用的方法。本页介绍限额消耗到了哪里。

每条消息都会重新发送完整对话

这是几乎所有人都会感到意外的机制。模型在不同轮次之间没有记忆。为了回答您的下一条消息，它会从第一个词开始重新读取整个对话。Anthropic 的文档明确说明：每次请求都会重新发送完整的对话历史。

因此，后续消息即使只有 5 个词，也不是一个 5 词的请求，而是整个对话线程加上这 5 个词。

有必要计算一次。假设每轮对话增加约 500 个 token，包括您的消息和 Claude 的回复。第 2 轮会发送约 1,000 个 token。第 10 轮会发送约 5,000 个。第 20 轮会发送约 10,000 个，是第 2 轮成本的 10 倍，而您输入的文字量相同。20 轮对话累计携带约 105,000 个 token；如果将同样的 20 个问题分别放在 20 个新对话中，则累计约 10,000 个 token。这些数字是根据算术推导的，并非实测值，但总体趋势是正确的。

这就是相同的可见工作可能产生完全不同成本的原因。无论采用哪种方式，您输入的文字都相同。差异在于这些文字上方包含了多少历史记录。

长对话还有第二项成本。当对话接近上下文窗口时（截至 2026 年 9 月，Pro 的上下文窗口为 200,000 个 token），Claude 会总结较早的消息，以便继续对话。Anthropic 指出，触发自动上下文管理的对话会消耗更多使用限额。生成摘要本身需要计算资源，消耗的也是同一项额度。

您可以观察这一过程。打开 Settings，然后打开 Usage。Pro 会显示 5 小时会话窗口和每周窗口的进度条。在长对话中发送第 20 条消息，然后在新对话中发送第 1 条消息，比较进度条移动了多少。会话窗口和每周窗口的重置方式介绍了每个窗口何时重置。

文件或 PDF 的成本是多少？

[
  {
    "label": "Text question only",
    "input_tokens": 14
  },
  {
    "label": "One tool definition plus a question",
    "input_tokens": 403
  },
  {
    "label": "One JPEG photo plus a question",
    "input_tokens": 1028
  },
  {
    "label": "One small PDF plus a question",
    "input_tokens": 2188
  }
]

这些是 Anthropic 令牌计数文档中打印的示例输出，均以 claude-opus-5 为基准测量。4 个提示词略有不同，因此应关注差距的大小，而不是精确数值。一个包含简短文本问题的请求计为 14 个输入令牌。附带一张照片并包含简短问题的请求计为 1028。附带一个小型 PDF（可移植文档格式文件）并包含简短问题的请求计为 2188，约为纯文本问题的 150 倍。

再结合上文所述的重复发送。附件会先转换为令牌，然后随该对话的每个后续轮次一起发送。在第 1 条消息中附加一份 40 页的报告后，第 2 条消息、第 3 条消息以及第 20 条消息都会再次为这 40 页付费。

公开的每页用量很高。在 API（应用程序编程接口）中，文档会列出这些数字。一页 PDF 通常会使用 1,500 到 3,000 个文本令牌，具体取决于内容密度；此外还要计算页面图像的成本，因为每一页也会转换为图像。40 页在提问之前就会消耗超过 60,000 个令牌。对于 200,000 个令牌的上下文窗口来说，这会占用很大一部分容量，而这些页面可能并不是你需要的内容。

因此，做法很简单。只附加所需的部分，不要附加整个文件。让 Claude 阅读一份报告并查找付款条款，会导致后续每一轮都发送整份报告。直接粘贴付款条款部分，只需一次性消耗几百个令牌。

截图的成本高于表面看起来的程度

[
  {
    "label": "200 x 200 crop",
    "standard_tokens": 64,
    "high_res_tokens": 64
  },
  {
    "label": "1000 x 1000 screenshot",
    "standard_tokens": 1296,
    "high_res_tokens": 1296
  },
  {
    "label": "1920 x 1080 screenshot",
    "standard_tokens": 1560,
    "high_res_tokens": 2691
  },
  {
    "label": "3840 x 2160 screenshot",
    "standard_tokens": 1560,
    "high_res_tokens": 4784
  }
]

Claude 会将图像读取为由图块组成的网格。每个图块为 28 × 28 像素，并计为 1 个视觉 token。因此，图像的成本为宽度除以 28 后向上取整，再乘以高度除以 28 后向上取整。1000 × 1000 像素的截图需要 1296 个视觉 token，超过大多数人整段问题所需的 token 数。

模型选择也会影响成本。Claude 4.7 及更高版本的模型会以更高的分辨率层级读取图像。因此，在这些模型中，一张完整的 4K 截图需要 4784 个视觉 token；而在会先缩小图像的旧版模型中，只需要 1560 个。文件相同、画面相同，但 token 数约为 3 倍。

Claude 应用单条消息最多接受 20 张图像。在尚未输入任何文字前，20 张完整截图就会构成非常大的请求，而且该聊天中的每个后续轮次都会再次携带这些图像。请改为裁剪图像。实际错误消息的 200 × 200 像素裁剪图需要 64 个视觉 token，通常也比整张桌面截图更能有效回答问题。

思考级别和努力程度的成本是多少？

努力程度控制 Claude 在回答前进行多少思考。在 Claude 应用中，该设置位于发送按钮旁边的模型菜单中，级别包括低、中、高、超高和最高。Anthropic 直接说明了这种取舍：更高的努力程度会使用更多 token，因此会更快达到使用上限。同一页面建议日常任务使用低或中等程度，因为较低的努力程度可以延长可用额度。

思考过程还会产生后续影响。在保留早期对话轮次的模型中，先前回答的思考内容会在该对话的每个后续轮次中计为输入 token。较长的推理过程在产生时计费一次，之后的每条消息还会再次计入一部分。

模型选择还会产生第二个容易被忽略的影响。分词器负责将文本拆分为 token，Claude 4.7 对分词器进行了更改。同一段输入文本在 Claude 4.7 及更高版本的模型中产生的 token 数量，比早期模型大约多 30 percent。Anthropic 没有公布这些数量如何换算为 Pro 限额中的占比，因此应将其视为日常工作使用较低设置的理由，而不是换算比例。在按需付费模式下，计费方式是公开的，而且 输入和输出 token 的价格不同。

代理和 Claude Code 最快耗尽限额的原因

Claude Code 和 Claude 应用共用同一使用额度。

Pro 和 Max 方案都为 Claude 和 Claude Code 提供共用的使用限额，这意味着两个工具中的所有活动都会计入同一组使用限额。

代理执行任务时，读取的内容远多于写入的内容。一次修复错误的请求可能会打开 10 个文件、执行搜索、读取结果，最后只用 4 行文字进行说明。您看到的是 4 行文字，但限额计算的是为得到这些结果而读取的所有文件。这是会话表面内容与实际消耗之间最大的差距。

在您提出任何问题之前，工具也会消耗令牌，因为每个工具的描述都会随请求一起发送。在上面的示例中，不使用工具的简短问题计为 14 个输入令牌，而携带一个工具定义的简短问题计为 403 个输入令牌。实际的代理配置通常会携带远多于一个工具。

在 Claude Code 中，/status 会显示当前会话的剩余额度。尽量缩小工作上下文是您能采取的最有效措施，管理较长 Claude Code 会话中的上下文介绍了具体方法。代理框架在您输入第一条指令前携带的额外开销解释了其余差距。

为什么同样的工作在某些语言中成本更高

分词器主要使用英语文本进行训练，因此常见的英语单词通常各占一个 token。同样的含义用俄语、阿拉伯语、印地语或日语表达时，通常会被拆分为更多 token，这意味着相同的问题会消耗更多额度。本页介绍的机制在所有语言中都相同，但每句话的成本并不相同。

请测量您自己的实际情况，不要只相信估算值。Anthropic 的 token 计数端点可以免费调用，并会返回任意消息的输入 token 数量：

curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "messages": [{"role": "user", "content": "Paste your paragraph here"}]
  }'

返回结果只有一行：

{"input_tokens": 14}

运行两次：一次使用英文段落，另一次使用您自己的语言写成的相同段落，然后比较两个数字。调用本身不收费，但需要在 platform.claude.com 的 Claude Console 中获取 API key；该账户与您的 Pro 订阅账户是分开的。改用英语通常并不划算，因为您使用自己的语言思考和写作的速度通常更快。相反，请缩短对话线程，并减小附件大小。这两种做法对您的帮助通常比对英语使用者更大。

让 Pro 计划使用更久的习惯

• 主题变化时开始新的对话。这是列表中最重要的习惯，因为线程越长，后续每条消息的成本都会成倍增加。
• 只附加相关部分，不要附加整个文件。提供 3 页，而不是 40 页。
• 将屏幕截图裁剪到只保留错误消息。
• 将长期适用的上下文放入项目中，而不是粘贴到每个新聊天中。Anthropic 表示，项目中的内容会被缓存，重复使用时不会计入您的限制，因此样式指南或架构应放在项目知识中。
• 对常规问题使用低或中等 effort，将高 effort 留给值得投入的任务。
• 在一条消息中完整提出问题。多轮澄清的成本高于一条详细消息，因为每一轮都会重新发送其上方的全部内容。

限制已经取消时

截至 2026 年 9 月，Pro 按月计费时每月收费 $20，按年计费时每月收费 $17。Anthropic 表示，Pro 在每个五小时会话中的用量至少是免费套餐的五倍。Pro 的费用和用量上限介绍了该套餐本身。上面的使用习惯确实能增加实际用量，但仍然有上限。如果您每月只遇到一次用量耗尽，这些方法就能解决问题。如果您在有偿工作中每隔几天就用尽用量，那么花时间判断 Max 是否适合您会更值得。

FAQ

为什么我今天的 Claude Pro 限额这么快就用完了？

几乎总是因为对话很长、包含附件，或两者同时存在。每条消息都会重新发送整个线程，因此第 20 条消息的成本可能是第 2 条的许多倍，即使你输入的字数相同。附件也会随每条消息重新发送。打开 Settings，然后选择 Usage，查看 5 小时会话和每周时间窗口分别已使用多少，然后为无关问题创建单独的聊天。

创建新对话能节省用量吗？

可以，这是最省用量的习惯。新聊天不包含历史记录，因此第一条消息只按你输入的内容计费。代价是 Claude 不再知道之前说过什么，因此只需粘贴有用部分的简短摘要，不要粘贴整个旧线程。把完整的旧对话粘贴到新聊天中，会重新构建你原本想摆脱的整个问题。

第 1 条消息之后，附件还会继续消耗用量吗？

会，在同一个对话中会继续消耗。文件会先转换为 tokens，这些 tokens 随后成为对话历史的一部分，并由之后的每一轮请求携带。40 页的 PDF 会一直保留在请求中，直到聊天结束。放入项目的文件是例外，因为 Anthropic 表示，项目内容会被缓存，重复使用时不会计入限额。

使用英语以外的语言会消耗更多限额吗？

通常会。对于相同的含义，tokenizer 会将非英语文本拆分为更多 tokens，因此同一个问题使用俄语或日语时的成本高于英语。你可以使用免费的 token counting endpoint，分别统计两种语言中同一段文字的 tokens，自行测量差异。与其切换语言，不如缩短线程并减少附件大小。这些做法比切换语言更能节省用量。

Claude Code 使用的限额与 Claude 应用相同吗？

相同。Anthropic 表示，Pro 和 Max 的用量限额在 Claude 和 Claude Code 之间共享，因此两者的活动都会计入同一组限额。Agent 会话会快速消耗限额，因为单个请求在返回结果前可能读取许多文件并运行多个工具。在 Claude Code 中运行 /status，查看当前会话还剩多少限额。