Claude 速率限制原理解析及实时监控方案

我在调试 Claude 时，遇到过这样一件事：整整两小时的对话，它突然就断了。

没有警告，没有倒计时，也没有任何提示告诉我即将达到上限。就一条消息，告诉我已经用完了额度。

两小时的上下文——全没了。只能从头再来。

从那以后，我开始认真研究 Claude 的 rate limit 机制到底是怎么运作的。结果出乎意料，而且我还没见过有人把这个机制解释清楚。

Claude 有两套完全独立的 rate limit

大多数开发者以为只有一个限制。实际上有两套，而且它们相互独立运作：

5 小时会话限制追踪任意滚动 5 小时窗口内的消息量。这个限制最容易让开发者措手不及，因为它是以滚动方式重置的，而不是固定时间点。

7 天周限制追踪滚动 7 天周期内的累计用量。这个限制是在首次消息发送后的第 7 天重置——不是周日，不是午夜，而是因人而异。

你可能周限制显示 0%，但会话限制已经到 90%。如果集中高强度使用，同一天内两个限制都可以打满。

为什么"滚动"比你想象的更重要

滚动重置是最让人栽跟斗的部分。

如果你在周二上午 9:14 发送了第一条消息，你的 5 小时窗口会在下午 2:14 重置——不是 10 点，不是中午，不是午夜。如果你在周一晚上 11 点发送了第一条消息，7 天限制会在下周一晚上 11 点重置。

这意味着"周日晚上重置"或"每天早上重置"这种心智模型对大多数用户来说是错的。重置时间是跟着你的使用习惯走的。

实际后果是：你无法按固定重置计划来规划。你需要知道实际的倒计时。

Claude 通过内部 API 暴露了什么

这是大多数开发者不知道的部分。

当你通过浏览器使用 claude.ai 上的 Claude 时，界面会向一个内部的用量端点发起请求，返回你真实的利用率数据——不是估算，不是近似，而是 Claude 用来决定何时切断你的精确数字：

{
  "five_hour": {
    "utilization": 0.82,
    "reset_at": "2026-07-15T14:14:00Z"
  },
  "seven_day": {
    "utilization": 0.34,
    "reset_at": "2026-07-21T21:00:00Z"
  }
}

utilization 字段是一个百分比——0.82 表示你已达到 5 小时限制的 82%。reset_at 字段是该窗口重置的确切 UTC 时间戳。

这个数据对任何通过浏览器使用 Claude 的人都可获取。你不需要 API key，不需要特殊权限。你现有的浏览器会话已经有读取它的权限——因为 Claude 本身就用它来显示 rate limit 警告。

为什么 Claude 的 rate limit 按 token 计而不是按消息计

限制不是按消息计算——是按 token 计算的。短消息消耗的 token 远少于包含大段代码粘贴的长消息。

一个 500 行的文件大约是 25,000-30,000 个 token。一次典型的详细回复可能是 1,000-2,000 个 token。在调试会话中粘贴大段代码，可能不到一小时就会烧光你的 5 小时窗口。

模型也有影响。Claude Opus 每个 token 的费用显著高于 Claude Sonnet 或 Haiku，这会影响你消耗配额的快慢。

降级问题——达到限制前质量就已经下降了

这里有一点在任何文档里都找不到：Claude 在达到硬限制之前，回复质量就已经开始下降了。

机制是注意力。大语言模型对近期 token 的权重高于远期 token。在一个很长的对话中，Claude 从技术上可以"看到"你写的所有内容，但随着更多内容的加入，它对对话早期内容的有效注意力会减弱。

实际上，这意味着你会注意到 Claude 开始忽略约束或忘记之前对话中建立的决定——通常发生在上下文窗口的 60%-70% 左右。到了 80% 时，你得到的答案往往比在一个有良好摘要的新对话中要差得多。

正确的重启时机是上下文窗口的 60%——而不是 Claude 告诉你对话太长的时候。

我如何实时追踪这些数据

被切断足够多次之后，我写了一个 Chrome 扩展，直接从 Claude 的内部 API 读取这些数据，并在浏览器中展示。

TokenPulse 在 Claude 输入框上方注入一个细条，显示：

1. 上下文窗口百分比的实时数据
2. 5 小时会话利用率（来自 Claude API 的精确百分比）
3. 7 天周利用率（同上）
4. 每次重置的倒计时
5. 每个对话、每天、每周的预估费用

它也可以在 ChatGPT、Gemini、DeepSeek 和 Grok 上工作——不过这些平台不像 Claude 那样暴露 rate limit 数据，所以那些用的是客户端估算。

无需 API key。无需账号。它读取你现有的浏览器会话——就是 Claude 已经在用来为自己的界面获取这些数据的那个会话。

基于这些理解的实际策略

在开始重度会话前检查两个限制。如果你已经达到 5 小时窗口的 70%，要么快点干，要么等重置。在 70% 时开始一个 2 小时的调试会话，几乎注定会被切断。

每个独立问题开启新对话。每条消息都会累积上下文。如果你在调试三个独立函数，三个对话比一个长对话效率更高。

在 60% 上下文时重启，而不是等 Claude 告诉你。到 Claude 警告你时，质量已经下降了。在 60% 时做摘要，开启新的，把摘要粘贴过去。

迭代用 Haiku 和 Sonnet，最终决策用 Opus。所有模型消耗相同的 rate limit 配额。让模型能力与任务复杂度匹配，可以延长你在达到限制前的工作时间。

围绕你实际的重置时间安排重度会话。在开始密集型会话前检查你的重置倒计时。如果你的 5 小时窗口还有 20 分钟就重置，等待往往是值得的。

这个扩展是免费开源的，如果你想了解它是如何读取 Claude 用量数据的：

Chrome Web Store: token-pulse.in GitHub: github.com/anu-ship-it/TokenPulse

关于 rate limit 检测的工作原理，欢迎在评论区提问。