Claude速率限制全拆解：免费版、Pro、Max每5小时和每周到底能用多少？

一句话结论：Claude的用量不是按"几条消息"硬数，而是按你烧掉的token在两层窗口里计费——一层是滚动的5小时窗口，一层是2025年8月加上的7天周限额。订阅档大致是：免费版每5小时2到5条、Pro（$20/月）10到45条、Max 5x（$100/月）50到200条、Max 20x（$200/月）200到800条。2026年5月6日官方又把Pro、Max、Team的5小时限额整体翻倍、取消了高峰时段缩水，所以现在的实际额度比多数老教程写的宽松一倍。这篇按官方最新口径，把订阅档、API档、撞墙原理和省额度的打法一次讲清楚。

很多人第一次撞到Claude的限额，都是在一个很糟糕的时间点：跑着跑着，Claude Code突然开始变慢、降级，甚至直接告诉你"额度用完了，请稍后再试"。手头那个跨境独立站的改版还差临门一脚，进度条就这么卡住了。那种感觉，像是开车上了高速才发现油表早就见底。

这件事最让人困惑的地方在于，官方从来没给过一个写死的数字——"Pro每天能发100条消息"这种确定答案根本不存在。额度是浮动的，取决于你用哪个模型、上下文堆了多大、当前服务器多忙。要想心里有数，就得先搞懂它到底按什么计费，而不是去网上抄一个早就过时的"每日条数表"。保哥把官方文档和2026年这几次调整重新对了一遍，下面从原理讲起，再落到每一档该怎么选、撞墙了怎么办。

Claude的额度到底按什么算，为什么没有固定条数？

先纠正一个最普遍的误解：屏幕上一个对话气泡，并不等于系统记的"一条消息"。真正被计量的是这一来一回消耗的token总量。token可以粗略理解为模型处理文字的最小单位，一个汉字大约占1到2个token，一段英文代码会被切得更碎。你发出去的提问、Claude吐回来的答复、它中途读进去的文件内容，全都折算成token记账。

这就解释了为什么同样名义上是"一条消息"，消耗能差出几十倍：

• 问一句"帮我改个错别字"，连上下文也就200个token左右；
• 带一段代码上下文的中等请求，大约5000个token；
• 让Claude Code一口气读10个文件再动手改，轻松冲到50000个token以上。

所以"Pro能发45条"这个说法，只在你都是轻量闲聊时才成立。一旦切到Claude Code的自主模式，让它读项目、跑测试、连续改十几个文件，烧额度的速度能比纯聊天快5到10倍。换句话说，45次"改错别字"和45次"重构整个模块"，根本不在一个量级。这也是不少独立站团队的真实体感：明明没发几次，额度怎么就见底了——因为他们数的是"次数"，系统数的是"token"。

想清楚这一点，后面所有的策略其实就一句话：在拿到同样结果的前提下，让每一次交互少烧token。这比纠结"我这档到底能发多少条"有用得多。

两层窗口是怎么叠在一起的？

Claude的订阅额度用的是双层限制，两层同时盯着你，任何一层先到顶都会触发限速：

第一层，5小时滚动窗口。注意是"滚动"不是"整点重置"——系统盯的是你过去连续5小时里的累计用量，没有一个固定的清零时刻。老的消息一旦超过5小时，对应的额度就慢慢回来了。所以你不会在某个整点突然满血复活，而是像退潮一样一点点恢复。理解这点很关键：与其干等"几点钟刷新"，不如知道大约2到3小时前那波重操作的额度正在陆续归还。

第二层，7天周限额。这是2025年8月28日才加上的，官方说只影响不到5%的重度用户。它衡量的是一整周里你累计占用的"计算小时数"。它的坑在于：你完全可能在头两天就把一周的预算造光，剩下五天处处受限。对那些习惯周一周二猛冲、周末歇着的人，这一层比5小时窗口更容易让人措手不及——5小时窗口顶多让你歇个把小时，周限额一旦触顶，可能要熬到下个结算周期。

怎么直观感受这两层的关系？可以把5小时窗口想成手机的"当日流量"，把周限额想成"月度套餐总量"。单日跑超了，等等就缓过来；要是整个套餐都提前用光，那就只能限速到下个月。重度用户真正要防的，往往是后者。

怎么估自己一周大概会不会撞周限额？

周限额按的是"计算小时数"，听起来很抽象，其实可以拿你的真实工作节奏粗估一下。假设你是Pro用户，周限额大致在40到80小时这个区间，那就反过来算：你一周里有多少个钟头是真的在让Claude连续干重活儿？

这里的"小时"不等于你开着窗口发呆的挂机时间，而是模型实际在为你处理任务的累计时长。一个粗略的换算：纯聊天、问答这类轻交互，几乎不怎么吃这个额度；真正快速消耗的是Claude Code的自主操作——让它读一大堆文件、连续改代码、跑测试再回看结果。一次饱满的自主重构，可能十几二十分钟就抵得上你一上午零碎问答的消耗。

所以一个朴素的自检：如果你一周里只有那么几次"放手让它自己干"的重活儿，剩下都是轻问答，那Pro的周限额基本碰不到边；但要是你每天都开着自主循环跑好几轮，把它当全天候的结对程序员使，那一两天就摸到周限额并不稀奇，这时候该认真考虑Max了。心里有这个换算，比死记"40到80小时"这个数字管用得多。

还有一个共享额度的坑必须说清楚：网页版的Claude.ai和命令行的Claude Code，共用同一个额度池。你白天在网页上问了一上午方案，下午再开Claude Code写代码，额度是接着前面算的，不是各发各的。规划用量时，得把两边一起算进去。想把Claude Code的额度花在刀刃上，可以先读一遍Claude Code最佳实践里关于模型选择和会话管理的部分。

各档订阅每5小时和每周到底能用多少？

下面这张表是2026年的大致区间。再强调一次，都是浮动值，受模型、上下文和服务器负载影响，官方给的是范围而非保证：

几个要点单独拎出来说：

免费版基本只够试用。每5小时2到5条、只能用Sonnet、没有Claude Code、高峰还要再砍，拿来评估一下产品能不能打可以，真要拿它干活远远不够。对认真想用Claude辅助开发的人，免费版的意义更像是"试驾"，开两圈就该决定上不上Pro了。

Pro是性价比最高的入门档。用Sonnet时一个5小时窗口大概能发35到45条，切到Opus就缩到10到20条。换算成真实活儿：随手修个bug能撑一整天；做一个完整功能撑2到3小时；多文件重构30到60分钟就紧张；要是开自主循环让它自己跑，15到30分钟就可能把5小时额度榨干。所以Pro用户最该记住的一条：把默认模型设成Sonnet，只在真正需要复杂架构决策时才动用Opus。对绝大多数独立开发者，Pro配上正确的用法，已经能覆盖日常八九成的活。

Max两档是给重度用户和团队的。Max 5x把额度抬了一档，还解锁了Pro没有的能力——可以按标准API费率额外购买用量，撞了限额也能续上不掉链子。Max 20x则基本告别5小时墙，并发开好几个会话也扛得住，适合一天泡在Claude里4小时以上、或者经常同时跑好几个项目的人。

Team档按人头独立计算，不共享。标准档每人是Pro的1.25倍倍率，高级档6.25倍，管理员还能统一开关"额外用量"的权限。对小型出海团队来说，Team最实际的好处是额度不会被某个猛用的同事一个人吃光，每个人的份额是隔开的，结算和管理也更清楚。

2026年5月那次"限额翻倍"到底改了什么？

这是这篇文章最该更新的一段，也是很多老教程还没跟上的地方。Claude的限额并不是一成不变，2026年上半年它来回调了好几次，时间线如下：

重点是2026年5月6日这次调整。它一次性做了三件事：把订阅档的5小时额度翻了一倍、彻底取消了3月才加上的高峰时段缩水、还抬高了Opus在API侧的限额。这意味着如果你看的还是2026年初的攻略，上面那些"Pro每5小时45条"的数字，现在实际上要再宽松一截。详细口径以官方的Anthropic速率限制文档为准，那里会随调整实时更新。

对国内用户尤其要提醒一句：高峰时段缩减按的是太平洋时间早5到11点，换算成北京时间大约是晚上8点到凌晨2点——这恰好是很多人下班后写代码的黄金时段。所以3月那阵子，不少人晚上感觉"特别卡"，并不是错觉。好在5月6日这一刀把这个缩减彻底砍掉了，晚上写代码的体验回来了。

这里也藏着一个反复出现的认知陷阱：每逢节假日促销翻倍、促销结束回落，社交媒体上就会冒出一波"Claude偷偷削额度"的声讨。其实多数时候是促销窗口开合造成的错觉。看额度变化，别只看自己这两天的体感，去对一眼官方公告更靠谱。新鲜度在这个话题上特别重要——一篇半年前的限额攻略，数字大概率已经不准了。

API的速率限制为什么和订阅是完全两套？

如果你不是在网页或命令行里交互，而是拿API Key写自动化脚本、做批量处理，那订阅那套5小时窗口对你完全不适用。API是另一个世界，按分钟计费，三个维度同时限制：

• RPM：每分钟请求数；
• ITPM：每分钟输入token数；
• OTPM：每分钟输出token数。

API的额度按"使用层级"（Tier）划分，靠累计充值自动升档，达到门槛立刻生效，不用申请。下面是官方当前的标准层级表，注意限额是按模型分类分别计算的，Opus和Sonnet各有各的池子，互不挤占：

这张表里有一处特别容易被老教程写错：很多攻略把Tier 1的输入限额笼统写成"3万"，那其实只是Sonnet的数字。Opus在Tier 1就有50万的输入限额，量级完全不同。引用数据时一定要分清模型，否则估算容量会差出十几倍，方案直接做歪。需要补充的是，每个层级还配着一个月度消费上限（Tier 1是$500、Tier 4到$200000），到顶之前只要持续充值就会自动往上走。

API相比订阅有三个本质区别，理解了它们才知道什么时候该转API：

• 没有5小时窗口，也没有周限额。限额每分钟回血，理论上你愿意付费就能一直跑，不会被"今天额度用完了"卡住整整一段时间。
• 缓存命中的token不计入限额。这是官方明确写的一条大福利——除了已退役的Haiku 3.5，绝大多数模型的缓存读取token都不算进ITPM。配合提示缓存，你的实际吞吐能轻松翻好几倍。官方举的例子：2百万ITPM的限额配上80%缓存命中率，相当于每分钟能处理1千万的输入token。各模型每百万token的具体价格，可以查官方的Anthropic定价页。
• 按模型独立限制。你可以同时把Opus和Sonnet都跑到各自上限，两边不互相拖累，做混合调度时很方便。

那什么场景该从订阅转向API？大致是这几种：用量波动极大（有时一天烧很多、有时几天不碰）、需要精确的成本核算和发票、要更高吞吐去喂自动化流水线，或者你干脆要基于SDK自己搭一套Agent工具。反过来，如果你是相对稳定的日常交互式开发，订阅几乎总是更省心也更便宜——别为了"看起来更专业"就盲目转API。

怎样才能不那么容易撞到限额？

搞懂了计费原理，省额度就有章可循了。下面这套打法对订阅和API都适用，按收益从高到低排：

第一，默认Sonnet，Opus按需。同一个请求，Opus消耗的限额token大约是Sonnet的3倍。日常的读代码、改bug、写测试，Sonnet完全够用，把它设成默认模型，能省下最大一笔开销。命令行里一条配置就能搞定：

claude config set model sonnet

这一条几乎能解决一半的"额度焦虑"。很多人撞墙不是因为档太低，而是从头到尾挂着最贵的模型干最普通的活儿。把模型选择当成一个需要刻意管理的开关，而不是装好就忘，体验会完全不同。

第二，把提示词写具体。"修复登录bug"这种模糊指令会触发好几轮反复澄清，每一轮都在烧token。直接点明文件、行号、报错现象和期望结果，Claude一次就能动手，省掉中间的来回。这本质上也是一种成本控制——含糊的沟通税，最后都记在你的额度上。写提示词花的那一分钟，往往能省下后面五轮的额度。

第三，用CLAUDE.md提供上下文。把项目的技术栈、目录约定、代码规范写进项目根目录的CLAUDE.md，Claude每次开会话自动读，就不必每次重新跟它解释一遍项目背景，实测能省下20%到30%的token。怎么写得既精炼又管用，可以参考CLAUDE.md记忆管理那篇里的模板。注意别把它写成长篇大论，CLAUDE.md本身也占上下文，太臃肿反而帮倒忙。

第四，不相关的任务就开新会话。长对话会不断累积上下文，每多发一条，前面所有内容都要再喂一遍给模型，越聊越贵。一个任务做完，换个不相干的活儿，果断开新会话，别让上下文无谓地滚雪球。一个简单的习惯：换主题先想想"前面那堆上下文，这次还用得上吗"，用不上就重开。

第五，API用户务必上提示缓存。把系统提示、大段上下文文档、工具定义这些重复内容缓存起来，缓存命中的输入成本能直接降到原价的10%，而且不计入限额。对要长期跑的自动化流水线，这一招几乎是必选项，省下的既是钱也是吞吐量。

第六，用命令盯实时消耗。命令行里随时敲/cost，能看到当前会话烧了多少；在控制台的用量页面还能看到输入/输出token的曲线和缓存命中率。心里有个底，撞墙前就能提前收手或换策略，而不是等被限速了才反应过来。

第七，重复劳动交给Hooks。格式化、代码检查、跑测试这类机械动作，没必要每次都让Claude自主操作一遍——用Hooks把它们自动化掉，既稳定又不占模型的额度。具体配法可以看Claude Code Hooks完全指南。把能交给脚本的都交给脚本，模型的额度就只花在真正需要它思考的地方。

额度紧张时，换更便宜的模型扛得住吗？

不少成本敏感的出海团队会问：既然Opus贵、Sonnet省，那能不能干脆全程用最便宜的模型，甚至换别家更便宜的国产模型来扛额度？这事得分两面看。

在Claude体系内，"默认Sonnet、关键时刻才上Opus"这个组合，已经能在省额度和保质量之间取得很好的平衡，绝大多数日常开发用Sonnet完全不掉链子，没必要为了省那一点而全程用更弱的模型，把简单任务也做得磕磕绊绊。真正该上Opus的，是那种需要全局权衡、跨多个文件做架构决策的硬骨头，省这种地方的钱往往得不偿失——返工的额度比省下的还多。

至于换别家或国产模型，思路上没问题：可以把Claude当"主力大脑"专攻难题，把一些机械的、确定性高的子任务分流给更便宜的模型或脚本去做。但要注意两点：一是不同模型在复杂指令和长上下文上的稳定性差别不小，盲目替换可能省了额度却赔上了正确率；二是工具链和生态的兼容性要先验证，别等接了一半才发现某个能力不支持。务实的做法是先小范围试，拿真实任务比一比产出质量，再决定哪些环节值得分流。

一个真实的踩坑场景

保哥接触过一个做户外装备的出海独立站团队，三个人合用一个Max 5x账号赶一次大改版。头两天他们怎么用都没事，第三天上午突然集体被限速，谁都跑不动。复盘下来问题出在两处：一是三个人共用一个账号，额度是叠加消耗的，相当于把一份Max当三份在烧；二是他们图省事全程开着Opus跑自主循环，等于拿最贵的模型干最费额度的活儿。后来改成每人一个账号、默认切Sonnet、只在定架构方案时短暂切Opus，同样的工作量，再没撞过墙。这个案例的教训很朴素：限额本身没那么小气，是用法没踩对点。更多类似的常见误用，整理在Claude Code常见错误那篇里。

另一个反向的例子：一个做B2B工业品的外贸团队，一开始嫌Pro小气想直接上Max 20x，保哥拦了一下，让他们先在Pro上把上面这套打法跑两周。结果两周里只在赶提案那两天碰到过一次限速，根本用不着月付200美元的档。省下来的预算，他们转头买了团队席位给另外两个同事——同样的钱，覆盖的人更多。选档这件事，先优化用法、再谈升级，几乎永远是对的顺序。

撞到限额的当下，能立刻做点什么？

道理都懂，但被限速的那一刻总归手忙脚乱。给几个能马上执行的动作：

• 先确认是哪一层触顶。如果只是响应变慢、Opus被降级成Sonnet，多半是5小时窗口快满了，歇一会儿就缓过来；如果是连续好几天都受限，那大概率撞的是7天周限额，得熬到周期重置。
• 立刻切到Sonnet。就算额度紧张，Sonnet能用的余量通常比Opus多得多，把当前任务降级到Sonnet往往还能接着干。
• 把手头任务拆小。别再让它一次读十几个文件，缩小范围、明确目标，单次消耗降下来，撞墙的频率自然低。
• 错峰。虽然5月6日已经取消了高峰缩减，但服务器整体负载高的时候，浮动额度仍会偏紧。把重活儿挪到相对空闲的时段，体验会稳一些。
• 真扛不住就考虑升档或临时转API。如果限速已经在实打实地拖慢交付，升Max省下的时间通常远值回那点差价；临时的爆量需求，用API按token顶一阵也是个灵活的选择。

Pro、Max还是直接走API，到底该怎么选？

不用纠结，按你每天实际泡在Claude里的时长对号入座就行：

一个朴素的判断逻辑：先从Pro起步，用一两周看自己多久撞一次墙。要是一周都碰不到限额，就别急着升；要是三天两头被限速，那升Max省下的时间早就值回那80美元的差价。对独立开发者和小团队，与其纠结档位，不如先把上面那套省额度的打法落实到位——很多时候不是档不够，是用法太费。把"先优化用法、再谈升级"当成默认动作，你会发现需要升档的时刻，比想象中晚得多。

最后把这篇的逻辑收一下：Claude的限额是浮动的、按token算的、分两层窗口管的，2026年5月之后整体比年初宽松了一倍。与其去背一张随时会过时的"每日条数表"，不如记住几条不变的底层逻辑——默认用Sonnet、提示写具体、上下文用CLAUDE.md托底、重复活儿交给Hooks。把这几条落地，无论官方怎么调限额，你都能把每一分订阅费花在刀刃上。真到了反复撞墙拖慢交付的那天，再升档或转API也不迟，那时候你已经清楚自己到底卡在哪一层、为什么卡。

常见问题解答

Claude Pro一个5小时窗口到底能发多少条消息？

用Sonnet大约10到45条，用Opus会更少（10到20条左右）。但这只是参考区间，实际条数取决于每条消息的长度和上下文大小。如果你都是带代码上下文的重活儿，能发的条数会明显比闲聊时少。2026年5月翻倍之后，这个区间的实际值还会再宽松一些。

撞到限额之后会直接断掉吗？

不会硬断，而是降速。响应间隔会变长，原本用Opus的请求可能被降级成Sonnet来处理。随着5小时滚动窗口里旧消息的额度逐步释放，你的可用量会慢慢恢复，不需要手动做什么。

网页版Claude.ai和命令行Claude Code的额度是分开的吗？

不是，两者共用同一个消息额度池。你在网页上的消耗会直接占用命令行的可用量，反过来也一样。所以规划用量时要把两边一起算，别以为开了两个入口就有两份额度。

Pro能不能像Max那样额外买消息？

不能。Pro没有额外购买用量的功能，撞了限额只能等窗口滚动恢复。想要"超额还能按API费率续"的能力，必须升级到Max套餐才行。

为什么我感觉额度突然变少了？

大概率不是被偷偷削减，而是促销窗口的开合造成的错觉。比如2025年12月底的节日促销把限额临时翻倍，2026年1月初恢复常态，很多人就误以为是被砍了。判断额度变化，对一眼官方公告比凭体感靠谱。

API的限额和订阅是同一套吗？

完全不是两回事。订阅按5小时窗口和7天周限额算消息数；API按每分钟的RPM、ITPM、OTPM算，没有窗口概念，且缓存命中的token多数不计入限额。用量波动大或要做自动化的，走API通常更划算也更可控。

团队一起用，怎么分配额度才不互相挤？

最关键的一条：别让多个人共用一个账号。订阅额度是按账号叠加消耗的，三个人挤一个账号，相当于把一份额度当三份烧，很快就集体限速。正确做法是上Team套餐，每人一个独立席位，份额互相隔开，谁用得猛也不会拖累别人。再配合统一约定"默认Sonnet、Opus按需"，整个团队的额度利用率会高很多。预算有限的小团队，甚至可以先各自用Pro，等确实撞墙了再升级，没必要一上来就堆顶配。

北京时间晚上用Claude会不会更容易被限？

2026年5月6日之前确实会，因为当时有工作日高峰时段的缩减，换算到北京时间正好覆盖晚上到凌晨。5月6日之后这个缩减已被取消。不过服务器整体繁忙时浮动额度仍可能偏紧，真要赶工，错开全球高峰会稳一点。

权威参考资料