并行子代理烧额度：一个被官方修过的坑
数据截至 2026-07，价格与限额以各官网为准。
如果你曾经觉得”我明明没干多少活，额度怎么就没了”，这个感觉未必是错觉——Anthropic 在 2026 年 6 月确实修复过一个问题：某些 Claude Code 会话会派生过多的并行子代理，比预期更快地烧掉用量，官方为此给全部 Pro 和 Max 用户做了一次性的 5 小时与周限额重置。这件事最有价值的地方不是”官方赔了额度”，而是它把一个平时看不见的成本结构摆到了台面上：你派出去的每一个子代理，都在花你自己的额度。
先承认一个很常见的误解：不少人以为子代理是”免费的并行”，觉得开五个子代理同时干活，跟自己在主会话里串行做完同样的事，花的额度应该差不多，无非是快一点。这个直觉不成立。子代理各自带着自己的上下文、各自读文件、各自产出，合并回主会话时还要再吃一遍结果。并行省的是你的墙上时间，不是账面用量——多数情况下它反而更贵。上面那个被修掉的坑，本质上就是这条成本结构在失控时的极端表现。
先搞清楚：额度到底是怎么算的
要判断”我这次是不是烧多了”，得先知道限额有几层。Claude Code 在订阅计划下是两层结构：
5 小时滚动窗，限制一个会话周期里能发多少条 prompt。这里有个关键细节很多人没注意：计时是从你发出第一条 prompt 那一刻开始的，不是按整点时钟走。也就是说你 10:00 发出当天第一条，15:00 就重置，中间发了 3 条还是 30 条，都不影响这个重置时刻。这个机制的实际含义是——如果你只想问一个小问题，问完就走，那这个窗口的剩余时间其实是被”占着”的；反过来，一旦窗口已经开了，在窗口内把相关的活儿做完，比拖到下一个窗口再开一次要划算。
周限额是第二层。官方帮助中心的说法是按账户被分配的固定时刻每周重置，重置日和时刻不随你何时开始使用、何时订阅而变，每个周期给满额度。
至于”一个窗口到底能发多少条”，官方给的是区间而不是定值，因为实际条数取决于 prompt 长度、上下文大小和你选的模型。按第三方汇总的口径，Pro 每窗大约 10 到 45 条 prompt，Max 20x 最高约 900 条。这个数字请当作量级参考而不是承诺——它是第三方汇总口径，不是官方逐字表述，具体以官方页面和你账户里实际显示的为准。
理解这两层结构之后，“并行子代理烧额度”这句话才有具体含义：子代理消耗的不是某个独立的池子，它跟你在主会话里的对话共用同一份额度。派得越多、每个带的上下文越大，5 小时窗和周限额掉得越快。
那个被修过的坑，具体发生了什么
时间线上有两件事值得记住。
2026 年 5 月 6 日，Anthropic 宣布永久把 Claude Code 的 5 小时限额翻倍，覆盖 Pro、Max、Team 以及按席位的 Enterprise，同时取消了此前对 Pro 和 Max 的高峰时段限额缩减，Opus 的 API 限额也大幅上调。官方把这次放宽归因于新增算力上线，公告里提到的规模是超过 300 兆瓦、约 22 万张 NVIDIA GPU。
2026 年 6 月，Anthropic 为全部 Pro 和 Max 用户做了一次性的 5 小时与周限额重置，给出的原因是修复了”某些 Claude Code 会话会派生过多并行子代理、比预期更快烧掉用量”的问题。
把这两件事放在一起看，你会发现一个对使用者更有用的结论：限额本身是会变的，而且往两个方向都变过。5 月是结构性放宽，6 月是针对具体缺陷的一次性补偿。所以任何写死在你脑子里或者脚本里的”我这档一天能跑多少”，都有保质期。
同时也别过度解读。官方修的是”派生过多”这个异常行为，不是说子代理机制本身有问题、以后不该用。子代理该用还是要用，只是你得知道它的代价来自哪里。
一个必须诚实说的矛盾：重置周期没那么确定
这里有一处第三方实测和官方文档对不上的地方，值得单独拎出来讲。
有开发者（GitHub 上一份流传较广的 gist，作者 monperrus）在 2026 年 6 月 9 日到 6 月 20 日的约 11 天里持续监测 utilization 字段，得出的结论是”周限额”实际上大约每 72 小时重置一次，而不是每 7 天。而这份 gist 的评论区显示，不同账号、不同档位观察到的重置日差异很大。
必须说清楚：这是第三方实测记录，不能当作官方事实陈述。官方文档的表述是按账户固定时刻每周重置，两边不一致。你可以把它理解成实测环境复杂、口径不同，也可以理解成实际实现比文档描述更细，但无论哪种解释，对你的操作建议是同一条——
不要把任何假定的周期长度硬编码进自动化脚本。 如果你写了一个定时任务，假设”每周一早上额度满血”，然后安排了一批重活儿排队跑，那么一旦实际重置节奏跟你的假设不一致，这批任务要么白等，要么在半路撞墙中断。正确做法是让脚本读实际状态再决定跑不跑，而不是靠日历推算。
日常怎么用子代理才不至于翻车
下面这些是可以立刻落地的做法。
第一，默认串行，并行是需要理由的。 只有当几个任务之间确实没有共享状态、也没有先后依赖时，并行才划算——比如同时给五个互不相关的模块补测试。如果任务之间有依赖，并行只会让子代理各自猜测另一半的进度，最后你还得花额度收拾不一致的结果。
第二，控制每个子代理带走的上下文。 子代理贵不贵，主要看它要读多少东西。给它一个明确的、范围收窄的任务描述，比给它一句”帮我看看这个项目哪里能优化”要省得多。上下文怎么控制这件事本身值得单独学，可以看 Claude Code 上下文管理：/compact 与 /context 怎么用。
第三，先跑一个小样本再放量。 打算派十个子代理做同一类改造，先派一个，看它实际消耗和产出质量。第一个跑歪了，剩下九个就是十倍的浪费。
第四，长时间批量作业前先看一眼剩余额度。 用 /status 命令可以查看剩余额度。在开始一个预计要跑很久的任务前花两秒看一眼，比跑到一半被打断、上下文还得重建要划算得多。
第五，需要真并行时，考虑用工作区隔离而不是无限派生子代理。 如果你的目的是”同时推进几条独立的线”，多开隔离工作区往往比在一个会话里堆子代理更可控，做法见 Claude Code 配 git worktree 并行多开实战。
关于 subagent 本身怎么定义、放哪个目录、description 和 tools 字段怎么配，可以看 Claude Code 自定义 Subagent 怎么写。
真撞上限额了，别做什么
撞墙之后第一反应去找客服，是很多人会犯的错。客服无法实时手动重置或延长你的配额——这条要记住，省得白白等一个不会来的回复。
现实可选的路径有这么几条：开启 usage credits，在超出包含额度之后继续用；或者改走 Claude Console 账号的按量付费；再或者升级订阅档位。这几条各有各的成本结构，具体条款以官方计费页当次显示为准。关于订阅额度与 API 按量这两种计费方式的底层差别，之前写过一篇 Claude Code 撞到用量限制怎么办？计费与额度说明 可以对照着看。
还有一件事：不要指望通过反复新开会话来”绕过”5 小时窗。窗口是账户级的，跟你开几个终端没关系。
诚实说局限
这篇讲的是机制和判断方法，不是精确的数值表。有三处限制要说明白。
一是具体条数不可预测。同样是”一条 prompt”，让模型读三千行代码和让它改一个变量名，消耗差着量级。任何声称”某档能跑几条”的确定说法，包括本文引用的那个区间，都只是量级参考。
二是政策会变。前面已经看到 2026 年就调整过至少两次。以官方最新说明为准，不要拿几个月前的文章当依据做技术选型。
三是访问前提。Anthropic 官方的受支持国家/地区列表不含中国大陆（anthropic.com/supported-countries），注册、控制台与 API 端点都在境外。本文不提供也不背书任何第三方中转渠道，其合规性与稳定性风险由使用者自负；以各厂商官方公布的受支持地区为准。
小结
Claude Code 的额度是两层结构：5 小时滚动窗从你发第一条 prompt 开始计时，周限额按账户固定时刻重置，而每窗能发多少条取决于上下文和模型，官方给的本来就是区间。2026 年 6 月官方修复了”某些会话派生过多并行子代理、比预期更快烧用量”的问题并做了一次性重置，这说明并行子代理的成本是真实存在且可能失控的，不是免费的加速。第三方实测记录到的重置周期与官方文档不一致、各账号表现还不一样，所以别把任何假定的周期写进自动化脚本，让程序读实际状态再决策。日常做法上，默认串行、收窄子代理的上下文、放量前先跑小样本、开工前用 /status 看一眼，比事后补救省事得多。真撞上了也别找客服要求重置，那条路走不通，剩下的选择是 usage credits、按量付费或升档，具体以官方最新说明为准。