Claude Code 的速率限制令开发者困惑，因为该系统远比表面看起来复杂。与 Claude 聊天界面简单的消息数限制不同，Claude Code 运行在三个独立的速率限制层之下，每一层都可以独立阻止你的请求。理解这些层如何交互——以及为什么仪表盘显示 6% 的每日用量并不能保护你免受每分钟级别的限流——是一个高效编码会话和持续中断之间的分水岭。本指南涵盖完整的速率限制架构，解释为什么 Claude Code 消耗 Token 的速度是普通聊天的 10 到 100 倍，并提供七种具体策略，可在不牺牲输出质量的情况下将有效 Token 消耗降低 30% 到 60%。
要点速览
- Claude Code 拥有三个独立的速率限制层：RPM（每分钟请求数）、TPM（每分钟 Token 数）和每日/每周配额。触发其中一个不影响其他，这就是为什么你可能在每日用量仅 6% 时就被限流。
- 一个 Claude Code 命令会产生 8-12 次 API 调用（通过工具调用），一次看似简单的请求就会消耗 50,000-150,000 个 Token。这是同等 Claude 聊天交互的 10-100 倍。
- Pro($20/月) 大约提供每周 40-80 小时的 Sonnet 使用时间。Max 5x($100/月) 提供 140-280 小时。Max 20x($200/月) 提供 240-480 小时。API 计费按 Token 收费，无硬性上限。
- 预防胜于应对：配置
.claudeignore、使用--include聚焦上下文、将简单任务路由到 Haiku、以及策略性管理会话，可以将 Token 用量减少 30-60%。 - 存在已知 Bug：部分用户报告在较低报告用量时被限流，这是平台端的问题而非个人配额耗尽。如果你的仪表盘显示低于 50% 但仍被限制，请查看我们的详细修复指南。
理解 Claude Code 的三层速率限制系统
围绕 Claude Code 速率限制最常见的困惑来源在于，三个完全独立的系统都可以各自阻止你的请求，而且无论哪一个触发，错误信息看起来都一样。理解这一架构不仅仅是理论层面的——它直接决定了哪种修复方案对你的具体情况有效，以及哪些优化措施真正能帮到你。
第一层是 每分钟请求数(RPM)，限制你在任意 60 秒窗口内调用 API 的频率。这以原始请求计数来衡量，与每个请求携带多少数据无关。对于 Tier 1 API 访问的开发者（购买 $5 积分后），限制为 50 RPM。这听起来很充裕，直到你意识到一个 Claude Code 命令可以通过其工具调用架构产生 8 到 12 次内部 API 调用——这意味着快速连续执行五个命令可能在几秒内耗尽你整个 RPM 预算。RPM 计数器每 60 秒重置一次，因此短暂等待可以快速解决 RPM 问题，但令人沮丧的是每个可见命令背后都在进行不可见的调用倍增。
第二层是 每分钟 Token 数(TPM)，限制在任意 60 秒窗口内通过 API 传输的总数据量。Anthropic 分别跟踪输入和输出 Token，对于 Claude Code 用户来说，输入 Token 几乎总是约束性瓶颈。这是因为每次 API 调用都携带完整的对话上下文——系统提示、对话历史、文件内容和工具定义——而这个上下文会随着会话中每次交互而增长。一个已经在同一 Claude Code 会话中工作了 30 分钟的开发者可能会发现，一个请求就发送了 200,000+ 个输入 Token，仅仅因为累积的上下文包含在每次调用中。Tier 1 为 Sonnet 模型提供 30,000 ITPM，而 Tier 4（累计购买 $400 积分后）提供 2,000,000 ITPM（Anthropic 官方文档，2026 年 3 月）。这里的关键优化细节是，Anthropic 的 TPM 限制是缓存感知的：对于大多数当前模型，缓存的输入 Token 不计入你的 ITPM 限制，这使得提示缓存成为目前可用的最强大吞吐量倍增器之一。
第三层是 每日或每周配额，设定了你在较长时间段内的总使用预算。对于订阅用户（Pro、Max），这体现为仪表盘上显示的使用百分比，并根据滚动窗口衡量——一个 5 小时的突发活动滚动窗口和一个于 2025 年 8 月 28 日引入的 7 天每周上限（TechCrunch，2025 年 7 月）。仪表盘上显示的 "6%" 仅反映相对于这一每日上限的消耗。一个每日配额为 6% 的开发者可能同时处于当前分钟 TPM 分配的 100%。这就是困扰几乎每个 Claude Code 用户的"预算内突发"问题：每日配额足够支撑数小时的工作，但每分钟限制决定了这些工作可以多快进行。
这三层不共享计数器，也不相互影响。充裕的每日预算在每分钟吞吐量对你的工作负载来说太窄时无济于事。反过来，拥有充足的 RPM 和 TPM 余量在你已耗尽每周配额时也毫无意义。当你遇到速率限制错误时，诊断出是哪一层触发的，是解决问题的关键第一步——因为每一层的修复方案完全不同。RPM 问题通过短暂暂停或间隔命令来解决。TPM 问题需要减少上下文大小或切换到更小的模型。配额问题需要等待重置窗口或升级套餐。使用错误的修复方案是浪费时间，而正确的方案可以让你在几分钟内恢复编码。
对于 API 用户，还有一个值得理解的额外细节：速率限制头信息伴随每个 API 响应出现，而不仅仅是错误响应。anthropic-ratelimit-requests-remaining 和 anthropic-ratelimit-tokens-remaining 头信息会准确告诉你在任何限制触发之前还剩多少容量。主动监控这些头信息——在你遇到 429 之前——可以让你实现智能限流，从而完全避免中断。
为什么 Claude Code 消耗 Token 如此之快
每个使用 Claude Code 超过几天的开发者都经历过同样的惊讶：感觉只用了二十分钟的轻度使用，却不知怎么消耗了大部分每日配额。原因在于 Claude Code 和 Claude 聊天界面之间的根本架构差异，理解这一差异对于做出明智的套餐选择和使用优化决策至关重要。
当你在 Claude 网页聊天中输入消息时，Token 交换相对简单——你的消息传入，响应返回，总 Token 数大致与两段文本的综合长度成正比。Claude Code 的运作方式根本不同，因为它是一个广泛使用工具的智能体系统。每次交互涉及一个多轮对话，包括系统提示（通常来自你的 CLAUDE.md 和内置指令，超过 2,000 个 Token）、累积的对话历史、被拉入上下文的文件内容，以及文件读取、代码库搜索和 bash 命令执行等操作产生的工具调用 Token。
考虑一下当你要求 Claude Code "修复登录模块中的认证 Bug"时会发生什么。系统读取你的 CLAUDE.md 文件获取项目上下文。它使用 ripgrep 搜索相关文件，这是一次工具调用。它读取每个匹配文件的内容——更多工具调用，更多输入 Token。它分析代码并提出修改方案，产生输出 Token。它通过另一次工具调用将修改写入磁盘。它可能运行测试来验证修复，又增加了一次工具调用。这些步骤中的每一步都是单独的 API 交互，每一步都携带完整的对话上下文。一个看似简单的请求很容易在 8 到 12 次内部 API 调用中产生 35,000 个或更多的 Token（SitePoint，2026 年 3 月）。
Token 倍增效应在整个会话过程中变得更加剧烈。同一对话中的每个后续提示都携带不断增长的上下文，这意味着每个请求的 Token 消耗随时间递增——不是线性增长，而是与总累积历史成比例。一个开始会话并发出 15 个迭代命令的开发者可能会发现，最后一个命令发送了超过 200,000 个输入 Token，仅仅因为整个对话历史被包含在每次调用中。
这种消耗模式意味着某些工作流消耗 Token 的速度明显快于其他工作流。多文件重构会话——Claude Code 需要跨多个文件读取、分析、修改和验证更改——消耗 Token 的速度是单文件编辑的 3 到 5 倍。每次修改后运行测试会增加另一个倍增因子，因为测试输出、错误信息和重试逻辑都会贡献到对话上下文中，而上下文随着每次迭代而增长。下表根据常见开发任务提供了粗略估算：
| 任务类型 | 典型 Token 消耗 | API 调用次数 | 会话时长影响 |
|---|---|---|---|
| 单文件编辑 | 30,000-60,000 | 4-6 | 低 |
| 代码审查（1 个文件） | 40,000-80,000 | 6-8 | 低-中 |
| 多文件重构 | 100,000-300,000 | 10-15 | 高 |
| "检查、修复、测试、再修复"循环 | 150,000-400,000 | 12-20 | 非常高 |
| 全项目分析 | 200,000-500,000+ | 15-25 | 极高 |
理解这些消耗模式直接决定了哪些优化策略对你的具体工作流影响最大。如果你主要进行单文件编辑，瓶颈可能是 RPM 而非 TPM。如果你进行大量多文件工作，上下文管理和会话重置就变得至关重要。
你需要知道的所有速率限制数字
Anthropic 刻意将一些速率限制数字保持近似值，特别是对于订阅套餐，限制被描述为"活动限制"而非精确的 Token 数量。以下数字代表截至 2026 年 3 月从官方文档和多个第三方分析中获得的最佳可用数据。
订阅套餐限制
| 套餐 | 月费 | 每周 Sonnet 时长 | 每周 Opus 时长 | 5 小时窗口 | 最适合 |
|---|---|---|---|---|---|
| 免费 | $0 | 非常有限 | 不可用 | 2-5 次提示 | 快速实验 |
| Pro | $20/月（年付 $17） | 40-80 小时 | 不可用 | 10-40 次提示 | 每天编码 2-3 小时 |
| Max 5x | $100/月 | 140-280 小时 | 15-35 小时 | 50-200 次提示 | 每天编码 4-6 小时 |
| Max 20x | $200/月 | 240-480 小时 | 24-40 小时 | 200-800 次提示 | 全职开发 |
所有订阅套餐在 Claude 聊天界面和 Claude Code 之间共享一个通用的使用额度池。Max 套餐相对于 Pro 倍增了额度，但每分钟限制（RPM/TPM）的精确倍数未公开记录（claude.com/pricing，2026 年 3 月）。每周上限于 2025 年 8 月 28 日引入，Anthropic 报告称根据使用模式，受影响的订阅者不到 5%。
API 各层级速率限制
对于使用自己 API 密钥的 Claude Code 开发者，限制是明确的，并随累计积分购买量而扩展：
| 层级 | 积分要求 | RPM | 输入 TPM（Sonnet） | 输出 TPM | 每日预算 |
|---|---|---|---|---|---|
| Tier 1 | $5 | 50 | 30,000 | 8,000 | ~1000 万 Token |
| Tier 2 | $40 | 1,000 | 450,000 | 90,000 | ~3300 万 Token |
| Tier 3 | $200 | 2,000 | 800,000 | 160,000 | ~8300 万 Token |
| Tier 4 | $400 | 4,000 | 2,000,000 | 400,000 | ~1.66 亿 Token |
Anthropic API 使用令牌桶算法，这意味着你的容量会持续补充到最大值，而不是在固定间隔重置（platform.claude.com/docs/en/api/rate-limits，2026 年 3 月）。这一点很重要，因为短暂的超速率突发有时是被允许的，只要整体的每分钟预算没有超出。
当前促销活动
截至 2026 年 3 月，Anthropic 正在进行一项持续到 2026 年 3 月 27 日的促销活动，在非高峰时段——具体为东部时间上午 8:00 到下午 2:00 之外——将你的 5 小时使用额度翻倍（support.claude.com，2026 年 3 月 13 日）。这些促销活动并不总是广泛宣传的，因此定期查看 Claude 帮助中心是值得的。
Pro vs Max vs API 计费：选择合适的套餐
选择合适的套餐从根本上说是将你的实际使用模式与能最大限度降低成本或减少中断的定价结构相匹配。错误的选择要么浪费钱在未使用的容量上，要么造成持续的速率限制中断，而这些中断带来的生产力损失比订阅费的节省更大。
如果你每天专注编码 2-3 小时，$20/月的 Pro 通常就足够了。每日重置意味着你每天以全新的配额开始，这对于一致的、适度的使用模式非常适合。早上的代码审查、下午的调试会话和偶尔的架构问题都可以舒适地在 Pro 限制内完成。当你有密集的会话超出每日分配时，该套餐就会不够用——如果你每周超过两次在完成工作前达到 Pro 限制，升级的数学计算就偏向 Max。
如果你每天编码 4-6 小时并将 Claude Code 作为主要开发工具，$100/月的 Max 5x 是最佳选择。相对于 Pro 的 5 倍乘数为延长的编码会话提供了大量额外空间，Max 套餐还包括在高流量期间的优先访问，这意味着更少的由平台范围容量限制而非个人配额耗尽导致的速率限制。Pro 和 Max 5x 之间的盈亏平衡点大约在每天 4 到 5 小时的 Claude Code 使用——如果你持续在完成工作前耗尽 Pro 限制，每月 $80 的溢价通常在第一周内就能通过恢复的生产力收回成本。
如果你每天编码 8 小时以上或运行并发会话，$200/月的 Max 20x 提供了订阅层级中最高的吞吐量。此层级专为进行大规模自动化重构、运行多个 Claude Code 实例、或在上下文大小经常超过每请求 100,000 Token 的大型代码库上工作的高级用户设计。
API 按用量计费完全移除了订阅限制，按 Token 收费：Sonnet 4.6 每百万输入 Token $3，每百万输出 Token $15（claude.com/pricing，2026 年 3 月）。对于每天平均消耗 100,000 个综合 Token 的开发者，月费约为 $25 到 $40，与 Pro 相当但没有硬性限制。优势在于完全的灵活性——你只会遇到每分钟 API 层级限制，而这可以通过存入更多积分来提升。缺点是成本不可预测：一次密集会话可能在一天内花费 $20 到 $50。对于评估基于 API 访问的团队，laozhang.ai 等服务提供具有竞争力的按 Token 定价的 API 中转访问，且无速度限制，提供了一种比直接 Anthropic 计费更经济的替代方案，同时完全避免了订阅速率限制。
Batch API 值得为非紧急任务考虑。它以标准定价的 50% 异步处理请求，并在与实时使用分开的速率限制下运行（claude.com/pricing，2026 年 3 月）。将批处理兼容的工作——文档生成、多模块代码质量分析、审查摘要和测试生成——卸载到 Batch API，可以为交互式开发释放实时配额。这对于某些任务对时间敏感（主动调试、实时代码审查）而其他任务可以容忍数分钟或数小时延迟（生成全面文档、运行代码库安全审计）的团队来说特别强大。成本节省会快速累积：一个每月通过 Batch API 生成 1,000 页文档的团队，与实时定价相比可节省约 50%，同时为无法等待的交互式工作保留了实时容量。
为了使决策具体化，考虑在承诺更改套餐之前跟踪一周的实际使用情况。监控你触发速率限制的次数、限制发生的时间，以及触发限制时你正在进行的工作类型。这些数据将套餐决策从猜测转变为计算。如果你主要在下午密集编码会话期间触发限制，但很少在上午触发，仅 2026 年 3 月的非高峰促销就可能在不升级套餐的情况下解决你的问题。如果你全天持续触发限制，升级层级或切换到 API 计费才是合适的解决方案。
七种预防速率限制的策略
避免速率限制最有效的方法是在保持输出质量的同时减少每次交互的 Token 消耗。这些策略可以在三十分钟内实施，通常可将有效 Token 用量减少 30% 到 60%。
策略 1：配置 .claudeignore 排除无关文件。 当 Claude Code 索引你的项目时，每个进入上下文窗口的文件都会消耗 Token。在项目根目录创建 .claudeignore 文件——其语法与 .gitignore 相同——排除 node_modules/、dist/、.git/、build/、大数据文件、生成的代码和二进制资源等目录。一个典型的 JavaScript 项目通过良好配置的 .claudeignore 文件可以将每次请求的上下文减少 40% 到 70%。这是影响最大的单一优化，因为它在不改变工作流程的情况下减少了后续每次交互的 Token 消耗。作为实践起点，大多数 Web 项目受益于忽略测试夹具、模拟数据、编译输出和第三方依赖。关键洞察是 Claude Code 不需要看到你永远不会要求它修改的文件——在大多数代码库中，70% 到 90% 的文件属于这一类别。定期检查你的 .claudeignore，因为新的构建产物或生成的文件会随着时间悄然膨胀上下文大小。
策略 2：使用 --include 标志聚焦上下文。 不要让 Claude Code 在整个项目中搜索相关文件，而是使用 --include 标志精确指定要加载的文件。运行 claude "review the auth logic" --include src/auth/** 将上下文限制在认证模块，避免加载不相关代码的 Token 成本。对于修复特定模块中的 Bug 等目标明确的任务，这一个改变就可以将输入 Token 减少 50% 到 80%。
策略 3：将任务路由到合适的模型。 并非每个任务都需要最强大的模型。将 Opus 4.6 保留给复杂的多文件重构、安全敏感的代码审查和需要深度推理的架构决策。使用 Sonnet 4.6 进行标准代码审查、文档生成和直接的实现——它以 Opus Token 成本的一小部分处理大多数专业开发任务。切换到 Haiku 4.5 处理快速问题、简单编辑、语法检查和格式化任务。你可以在会话中使用 /model sonnet 或 /model haiku 切换模型，此更改对下一个提示立即生效。许多开发者发现 Haiku 可以充分处理 60% 到 70% 的日常编码任务，同时只消耗极少的 Token 预算。一个实用的路由启发式方法：如果任务涉及理解多个文件之间的关系或需要创造性解决问题，使用 Sonnet 或 Opus；如果任务涉及将已知模式应用于单个文件，Haiku 就够了。这个思维模型帮助你快速做出路由决策而不过度思考每次交互，在一周的过程中可以将总体 Token 消耗减少 25% 到 40%。
策略 4：管理会话以控制上下文增长。 Claude Code 对话随时间累积上下文，一个以 5,000 Token 历史开始的会话在三十分钟的主动开发后可能达到 50,000 Token。每个后续提示都携带这个不断增长的上下文，意味着会话中第十五个命令的 Token 成本远高于第一个——不是因为命令更复杂，而是因为累积的历史已经膨胀。最有效的缓解措施是将长会话分解为更短、更聚焦的对话。当你完成一个逻辑任务——修复一个 Bug、实现一个功能、审查一个模块——为下一个任务启动新的 Claude Code 会话，而不是继续在同一对话中。这会重置上下文窗口，防止每次交互的成本失控。/compact 命令在完全会话重置和让上下文无限制增长之间提供了折中方案。它将当前对话总结为精简形式，保留关键决策和上下文同时丢弃冗余的中间交互。每 10 到 15 次交互使用一次 /compact，或者当你注意到响应时间变慢时使用——较慢的响应通常是上下文窗口已经增长到足以影响性能和 Token 消耗的信号。
策略 5：将相关请求批量合并为单个提示。 每个新提示都携带完整的对话上下文，因此五个小问题的 Token 成本远高于一个综合请求。不要分开问"函数 X 做什么？"然后"函数 Y 做什么？"然后"X 和 Y 如何交互？"，而是合并为单个提示："解释函数 X 和 Y 以及它们如何交互，包括共享状态和依赖关系。"这将 API 调用从三次减少到一次，并消除了冗余的上下文传输。
策略 6：将复杂解释保存到本地。 当 Claude Code 提供了关于你的代码库架构、数据库模式或 API 设计的详细解释时，保存到本地文件：claude "explain the database schema" > docs/schema-explanation.md。以后引用这个保存的文件比要求 Claude Code 从头重新分析和重新解释相同的代码所消耗的 Token 要少得多。这种方法还使有价值的文档在你离线或被限流时随时可用。
策略 7：策略性安排密集工作。 每分钟计数器每 60 秒重置一次，每日配额根据套餐类型在不同的时间表上重置。将你最消耗 Token 的工作分散在一天中，而不是集中在两小时的突发中，可以防止反复碰到 TPM 上限。如果你能将繁重的编码工作转移到非高峰时段，像当前 2026 年 3 月的双倍用量促销期（东部时间上午 8 点至下午 2 点之外，持续到 3 月 27 日）这样的活动，可以在不增加任何成本的情况下有效给你两倍的配额。
触发限制时该怎么办
尽管采取了最好的预防策略，速率限制偶尔仍会触发——特别是在密集的编码会话期间或平台范围需求较高时。关键是快速解决问题，在几分钟而非几小时内恢复工作。
最快的修复方法是切换到更轻量的模型。在你的 Claude Code 会话中输入 /model haiku 切换到 Haiku 4.5，当你的 Sonnet 或 Opus 配额耗尽时它可能仍有可用额度。Haiku 可以有效处理格式化、简单编辑和语法问题等直接任务，让你在主要模型配额恢复期间继续高效工作。
如果切换模型没有帮助，检查你的精确用量和重置时间。在终端运行 claude --account 查看你的订阅层级和大致用量。访问 claude.ai，导航到设置，查看你的使用百分比和下次重置的倒计时。Pro 套餐使用每日滚动重置，而 Max 套餐使用每周滚动窗口。
对于无法承受停机时间的开发者，切换到 API 计费可以提供即时缓解。通过 console.anthropic.com 的 API 计费按 Token 收费，没有硬性订阅上限。通过运行 claude config set apiKey YOUR_API_KEY 使用你的 API 密钥配置 Claude Code。这种方法以成本可预测性换取了保证的可用性。
如果在低报告用量下错误仍然持续，你可能遇到了已知 Bug 而非合法的速率限制。GitHub issue #29579 记录了 Max 订阅者在仅 16% 报告用量时收到速率限制错误的案例，issue #33120 描述了无论实际活动如何，每个命令都返回速率限制错误的场景。尝试使用 claude logout 登出然后用 claude login 重新登录，使用 ps aux | grep claude 检查孤立的后台进程，如果问题在不同机器上持续存在，请联系 Anthropic 支持。如需每个诊断步骤的全面指导，我们的"速率限制已达到"错误完整修复指南涵盖了完整的诊断流程图，包括订阅 vs API vs Bug 识别。
在被限流期间，考虑使用替代工具来保持生产力，而不是完全停止工作。Gemini CLI 提供慷慨的免费层级，通过 Google OAuth 认证提供 60 RPM 和每天 1,000 次请求以及高达 100 万 Token 的上下文窗口——将其作为备用方案安装在 Claude Code 旁边，只需不到两分钟即可设置。GitHub Copilot CLI 包含在 Copilot 订阅中，通过大多数开发者熟悉的界面有效处理补全和聊天。如需 Claude Code 与可完全消除速率限制顾虑的自托管替代方案的详细对比，请参阅我们的 Claude Code vs OpenClaw 分析。
在速率限制期间最高效的做法是专注于真正不需要 AI 辅助的任务：手动编写测试、审查团队成员的 Pull Request、更新文档、处理管理性任务，或解决依赖你对代码库现有知识的直接 Bug 修复。许多开发者报告说，被迫暂停 AI 辅助编码实际上提高了他们对自己项目的理解，因为他们花了更多时间阅读和思考代码，而不是将这些认知工作委托给 AI 工具。速率限制虽然在当下令人沮丧，但可以作为一个自然的检查点，防止过度依赖 AI 辅助处理那些人类判断既更快又更可靠的任务。
常见问题
Claude Code 速率限制需要多长时间重置？
重置时间取决于你触发了哪一层速率限制。RPM 和 TPM 计数器每 60 秒重置一次，因此每分钟限制可以快速解决。订阅每日配额在滚动基础上重置——Pro 套餐全天持续重置，而 Max 套餐使用每周滚动窗口。精确的重置时间显示在你的 claude.ai 设置面板中。API 层级限制使用令牌桶算法持续补充，因此在任何使用间隙后几秒钟内就会恢复部分容量。
为什么 Claude Code 使用的 Token 比 Claude 聊天多得多？
Claude Code 是一个执行工具调用的智能体系统——文件读取、搜索、命令执行和文件写入——作为满足你请求的一部分。每次工具调用都是一次携带完整对话上下文的单独 API 交互。一个用户命令可以产生 8 到 12 次内部 API 调用，每次都传输累积的系统提示、对话历史和文件内容。相比之下，Claude 聊天界面涉及简单的请求-响应交互，不使用工具，因此每次交互的 Token 消耗大大降低。
仅为了 Claude Code 从 Pro 升级到 Max 值得吗？
如果你持续在完成工作前达到 Pro 限制，升级就是值得的。盈亏平衡计算很简单：如果速率限制导致的停机时间每月成本超过 $80（Pro 和 Max 5x 之间的价格差），升级就能收回成本。对于时薪 $100+ 的专业开发者，即使每周一小时的停机时间也超过了成本差异。如果你每周触发 Pro 限制少于两次，优化策略（模型路由、上下文管理）可能比升级更具成本效益。
我可以免费使用 Claude Code 吗？
Claude 免费套餐提供有限的每日消息数但不包含完整的 Claude Code 功能。$20/月的 Pro（年付 $17）是包含 Claude Code 和 Cowork 访问的最低层级（claude.com/pricing，2026 年 3 月）。对于免费的 AI 编码替代方案，Gemini CLI 通过 Google OAuth 提供 60 RPM 和每天 1,000 次请求，GitHub Copilot CLI 包含在现有的 Copilot 订阅中。
429 错误和 529 错误有什么区别？
429 HTTP 状态码意味着你超过了速率限制——你的请求有效但需要等待后再发送更多。529 状态码意味着 API 服务器过载，与你个人的配额无关。两者都需要重试逻辑，但策略不同：对于 429 错误，遵守 retry-after 头信息并实现指数退避；对于 529 错误，使用 1 到 5 秒的起始延迟进行指数增长，不要将等待时间计入速率限制退避计时器。Claude Code 对两者都有内置重试逻辑，因此当你看到错误时，内部重试已经被尝试过了。
如何实时监控我的速率限制使用情况？
Anthropic 的每个 API 响应都包含速率限制头信息：anthropic-ratelimit-requests-remaining 显示当前分钟窗口中剩余的请求数量，anthropic-ratelimit-tokens-remaining 显示剩余的 Token 预算，anthropic-ratelimit-tokens-reset 提供限制补充的时间戳。对于订阅用户，claude.ai 设置页面显示使用百分比和重置倒计时，尽管实际消耗和仪表盘更新之间存在已报告的延迟。要获得实时准确性，基于头信息的监控是唯一可靠的方法。如果你正在基于 Claude API 构建工具，主动监控这些头信息可以让你实现智能限流——在接近限制时减慢请求速度而不是触发 429 错误。
提示缓存对速率限制有帮助吗？
是的，这是目前最未被充分利用的优化之一。Anthropic 的 ITPM（每分钟输入 Token 数）限制是缓存感知的：对于大多数当前模型，缓存的输入 Token 不计入你的 ITPM 限制。当你有跨交互重复的一致内容——你的 CLAUDE.md 系统提示、项目文档、频繁引用的文件——提示缓存让你可以有效绕过输入 Token 瓶颈。在 80% 的缓存命中率下，你可以处理名义 ITPM 限制的五倍，这意味着一个拥有 30,000 ITPM 限制的 Tier 1 开发者可以有效处理每分钟 150,000 个输入 Token 的缓存内容。为了最大化缓存命中率，保持你的 CLAUDE.md 内容在会话间稳定，并组织你的提示使不变的上下文出现在最前面。