【Bug已解决】Rate Limit Exceeded on /compact — Claude Code 压缩上下文也限流解决方案
【Bug已解决】Rate Limit Exceeded on /compact — Claude Code 压缩上下文也限流解决方案1. 问题描述在 Claude Code 长会话中执行/compact压缩上下文时突然弹出以下报错信息Rate limit exceeded while compressing context Please wait and try again later.或者Error: /compact failed - rate_limit_error {type:error,error:{type:rate_limit_error,message:Request rejected (429)}}有时报错为Context compression failed due to rate limiting Your 5-hour usage limit has been reached这个问题在以下场景中特别常见长时间高强度使用 Claude Code 后执行 /compact使用 Opus 模型时 /compact 消耗大量 Token同时在多个窗口使用 Claude CodePro 订阅用户 5 小时配额接近上限时上下文非常大时 /compact 需要处理大量 Token# 典型复现过程 $ claude # 编码 2 小时后... /compact Rate limit exceeded while compressing context Please wait and try again later. # /compact 也消耗 API 配额如果配额已耗尽就无法压缩2. 原因分析核心原理拆解执行 /compact → Claude Code 发送压缩请求到 API ↓ 压缩请求需要处理整个对话历史大量 Token ↓ 当前账户已达到速率限制或配额上限 ↓ 压缩请求被拒绝 (429) ↓ 报错 Rate limit exceeded while compressing原因分类表原因分类具体表现占比5 小时配额耗尽Pro/Max 订阅配额用完约 40%TPM 限制/compact 请求 Token 过大约 30%RPM 限制短时间内请求过多约 15%Opus 模型配额Opus 有独立的更严格配额约 10%7 天配额耗尽周配额上限约 5%深入说明/compact命令本身也是一个 API 请求——它将当前对话历史发送给 Claude 模型让模型生成一个压缩摘要。这个请求的 Token 消耗等于整个对话历史的大小可能是 50K-100K tokens。当账户已经接近速率限制或配额上限时这个大请求就会成为压死骆驼的最后一根稻草触发 429 限流。/compact 的 Token 消耗输入 Token整个对话历史 系统提示可能 100K tokens输出 Token压缩后的摘要通常 5K-15K tokens总消耗约 105K-115K tokens单次 /compact 操作3. 解决方案方案一使用 /clear 代替 /compact最推荐如果 /compact 被限流使用 /clear 直接清空上下文。# 步骤 1使用 /recap 保存摘要如果还能执行 /recap # 生成会话摘要保存到文件 # 步骤 2清空上下文 /clear # 不消耗 API 配额本地操作 # 步骤 3重新开始工作 继续处理数据库模块方案二切换到 Haiku 模型后执行 /compactHaiku 模型的速率限制更宽松/compact 更容易成功。# 步骤 1切换到 Haiku /model haiku # 步骤 2执行 /compact /compact # Haiku 的速率限制更高可能不会被限流 # 步骤 3压缩成功后切回 Sonnet /model sonnet方案三等待配额重置后执行 /compact如果是配额耗尽等待重置后再压缩。# 步骤 1查看配额状态 /status # 查看配额重置时间 # 步骤 2等待到重置时间 # 如果显示 resets at 14:30等待到该时间 # 步骤 3重置后执行 /compact /compact方案四减少并发使用关闭其他 Claude Code 窗口降低请求频率。# 步骤 1检查运行中的 Claude Code 实例 ps aux | grep claude | grep -v grep # 步骤 2关闭不需要的实例 kill PID # 步骤 3在单个窗口中执行 /compact /compact方案五手动管理上下文不依赖 /compact手动管理对话历史。# 步骤 1使用 /context 查看当前 Token 使用量 /context # 步骤 2如果使用量超过 70%手动总结关键信息 # 将关键信息写入文件或笔记 # 步骤 3执行 /clear /clear # 步骤 4在新会话中引用保存的信息 参考之前保存的设计文档继续开发方案六升级到更高 Tier 或启用 Extra Usage# 步骤 1检查当前 Tier # Anthropic Console → Settings → Billing # 步骤 2升级 Tier 或启用 Extra Usage # Extra Usage 允许配额耗尽后继续使用按量计费 # 步骤 3/compact 不再被限流 /compact4. 各方案对比总结方案适用场景推荐指数难度方案一/clear 代替不需保留历史⭐⭐⭐⭐⭐低方案二切换 Haiku需要压缩上下文⭐⭐⭐⭐⭐低方案三等待重置配额耗尽⭐⭐⭐低方案四减少并发多窗口冲突⭐⭐⭐⭐低方案五手动管理预防性管理⭐⭐⭐⭐中方案六升级 Tier长期高频使用⭐⭐⭐低5. 常见问题 FAQ5.1 /clear 是否消耗 API 配额不消耗。/clear是本地操作只清空客户端的对话历史缓存不发送 API 请求。所以即使配额耗尽也能执行/clear。5.2 /compact 消耗多少 Token取决于当前对话历史大小。如果对话历史是 80K tokens/compact 的输入约 80K tokens输出约 10K tokens总消耗约 90K tokens——相当于一次大型 API 请求。5.3 为什么 Haiku 能 /compact 但 Sonnet 不能Haiku 的速率限制比 Sonnet 更宽松RPM 和 TPM 更高。切换到 Haiku 后同样的请求可能不会触发限流。5.4 /compact 失败后上下文是否保留是的。/compact 失败不影响当前对话历史。对话历史完整保留可以继续发送请求如果能通过限流检查的话。5.5 如何避免 /compact 被限流在上下文还不太大时50% 使用量就执行 /compact减少 Token 消耗定期执行 /compact 而非等到上下文很大时使用 Haiku 模型执行 /compact避免在配额接近上限时执行 /compact5.6 使用 /recap 是否也消耗配额是的。/recap 也需要调用 API 生成摘要同样消耗 Token。如果配额耗尽/recap 也会失败。5.7 /compact 和 /clear 的区别命令是否调 API是否保留摘要Token 消耗/compact是保留压缩摘要高/clear否完全清空零/recap是生成摘要但保留历史中5.8 企业团队共享 Key 时 /compact 频繁失败多人共享 Key 时所有人的请求叠加限流。建议每个成员使用独立 Key或错峰使用 /compact。5.9 /compact 后 Token 使用量没有明显下降可能是 /compact 的压缩效果不好摘要仍然很大。检查使用/context查看 /compact 后的实际 Token 数如果压缩效果差尝试/clear后手动提供关键信息5.10 排查清单速查表□ 1. /compact 失败时改用 /clear不消耗配额 □ 2. 切换到 Haiku 模型后执行 /compact □ 3. 查看 /status 确认配额状态和重置时间 □ 4. 关闭其他 Claude Code 窗口降低并发 □ 5. 在上下文 50% 使用量时就 /compact不要等到 90% □ 6. 考虑启用 Extra Usage 获得额外配额 □ 7. 使用 /context 监控 Token 使用量 □ 8. 长期方案升级 API Tier □ 9. /recap 保存摘要后再 /clear □ 10. 团队场景分配独立 Key6. 总结根本原因/compact 被限流是因为压缩操作本身是一个大型 API 请求消耗 100K tokens当账户已接近配额或速率上限时触发 429最佳实践/compact 失败时使用 /clear 代替——/clear 是本地操作不消耗配额虽然丢失对话历史但能立即恢复工作预防措施在上下文使用量 50% 时就主动执行 /compact而非等到 90% 时才压缩小上下文的 /compact 消耗更少 Token更不容易被限流模型策略切换到 Haiku 执行 /compact 是巧妙的解决方案——Haiku 的速率限制更宽松压缩成功率更高最佳实践建议养成主动管理上下文的习惯——每 30 分钟检查/context50% 时执行/compact避免等到上下文过大时压缩困难且容易限流故障排查流程图flowchart TD A[/compact 被 Rate Limit] -- B{是否需要保留对话历史?} B --|否| C[执行 /clear 清空上下文] B --|是| D[切换到 Haiku 模型] C -- E[✅ 立即恢复工作] D -- F[重新执行 /compact] F -- G{/compact 成功?} G --|是| H[切回 Sonnet 继续] G --|否| I[查看 /status 配额状态] H -- E I -- J{配额何时重置?} J --|5小时内| K[等待重置后 /compact] J --|已耗尽| L[使用 /clear 代替] K -- E L -- E