多个项目同时用 Claude Code，额度怎么分配才不打架
数据截至 2026-07，价格与限额以各官网为准。
额度是按账号算的，不是按项目算的。你开三个终端、三个仓库、三条分支，用的还是同一个池子——所以”多项目怎么分配额度”这个问题，本质上不是配置问题，而是排期问题：你得自己决定哪件事值得占用这一窗，哪件事可以往后挪。工具这一层没有开关能帮你分，能帮你分的只有日程表。
先说一个流传很广的误解：不少人以为在不同目录下开 Claude Code、或者用 git worktree 多开几个实例，额度会各算各的，多开就等于多拿。这个想法很自然，但跟实际结构对不上。多开解决的是”任务互相污染”和”等待串行”的问题，让你不用等第一个任务写完才能开第二个；它不会给你更多额度，反而因为几个实例同时在发请求，会让同一个窗被消耗得更快。想了解多开本身怎么操作，可以看 Claude Code 配 git worktree 并行多开实战，但请把它当成”效率工具”而不是”扩容工具”。
先搞清楚你在分的到底是什么
Claude Code 的限额是两层结构，这两层的性质完全不同，多项目排期时要分开考虑。
第一层是 5 小时滚动窗，限制的是一个会话里能发多少条 prompt。它最关键的一个特性是：计时从你发出第一条 prompt 开始，不是按整点时钟走。你上午 10:00 发了第一条，这个窗就在 15:00 重置；中间你发了 3 条还是 30 条，都不改变 15:00 这个时刻。这一条对多项目的人特别重要，后面会讲怎么利用它。窗口机制的细节可以看 Claude Code 的 5 小时窗到底怎么算。
第二层是周限额。官方帮助中心的说法是，它按你账户被分配的固定时刻每周重置——重置日和时刻不随你什么时候开始用、什么时候订阅而改变，每个周期给满额度。也就是说，周限额是一条你无法通过改变使用习惯来挪动的边界，你能做的只有决定怎么花。
至于每个窗到底能发多少条，官方给的是区间而不是定值。第三方汇总的口径是 Pro 每窗大约 10 到 45 条，Max 20x 最高可到约 900 条——注意这是第三方汇总口径，具体以官方页面和你账户里实际显示的为准。之所以官方不给定值，是因为实际条数取决于 prompt 长度、上下文大小和你选的模型。这一点直接决定了多项目分配的核心思路：你不是在分”条数”，你是在分”上下文预算”。 一条带着 20 万 token 上下文的追问，和一条空仓库里的简单提问，消耗完全不是一个量级。
一个能落地的排法：按”重活优先占窗”来排
既然 5 小时窗从第一条 prompt 起算，那你每天的第一条发给谁，就等于决定了这一窗归谁。多项目的人最容易犯的错，是早上随手用主力项目问一个”这个报错什么意思”的小问题，把窗启动了，然后真正要做的大重构排在下午——等做到一半窗满了，卡在最难受的地方。
比较务实的做法是这样：
- 把当天真正需要深度参与的那个项目排在窗口的开头。 先想清楚今天哪件事最需要连续投入，用它来开窗，让整个窗的容量服务于这件事。
- 杂活攒堆，别零敲碎打。 几个项目里的小问题——改个文案、看个报错、补个注释——先记在一个待办里，等大活告一段落再一次性处理，或者留到下一个窗的尾巴上。零散地穿插着问，最伤的是上下文：每次切项目，模型都要重新装载一遍新仓库的背景，这部分开销你是要付的。
- 一个窗内尽量只服务一到两个项目。 频繁在四个仓库之间跳，光是”重新讲清楚这是什么项目”就要吃掉不少额度。窗和项目大致对齐，比按小时随机切换省得多。
- 给次要项目留一个固定的时段。 比如约定周三下午那一窗专门处理边缘项目，其余时间它就排队。听起来笨，但比”想起来就问一句”可控得多。
这套排法的核心不是技巧，是承认一件事：额度是稀缺资源，稀缺资源要靠计划分配，不能靠临场冲动。
每个项目都做好上下文准备，比省着提问更有效
多项目场景下，最大的隐性浪费不是提问太多，而是每次提问都在重复交代背景。同一个池子被几个仓库分，谁的背景交代得省，谁实际能干的活就多。
具体能做的：
- 每个仓库都放一份项目说明文件，把技术栈、目录结构、编码约定、常见命令写清楚，让模型一进来就知道这是什么项目，不用你在对话里现讲。怎么写可以参考 CLAUDE.md 怎么写。这件事的收益是复利的：项目越多，重复交代的成本越高，一份好的说明文件省下来的额度也就越多。
- 切项目的时候果断开新会话，别在一个会话里横跨两个仓库聊。旧项目的上下文会一直挂在那里被反复携带，成本不低而且容易串味。上下文本身怎么管，可以看 Claude Code 上下文管理。
- 谨慎派子代理。 子代理很好用，但它派出去的每一次调用花的都是你自己的额度。2026 年 6 月官方修过一个问题：某些会话会派生过多的并行子代理，比预期更快烧掉用量，修复后为全部 Pro 和 Max 用户做了一次性的限额重置。这件事的启发不是”官方会赔”，而是并行度本身就是成本。细节见 并行子代理烧额度。
随时知道自己还剩多少
分配的前提是能看到余量。/status 命令可以查看剩余额度，多项目并行的时候建议养成习惯：开一个新的大任务之前先看一眼，别等做到一半才发现窗快空了。具体读法可以看 用 /status 查用量。
顺带说一句 2026 年的一次利好：2026 年 5 月 6 日，Anthropic 宣布永久把 Claude Code 的 5 小时限额翻倍（覆盖 Pro、Max、Team 以及按席位的 Enterprise），同时取消了此前对 Pro 和 Max 的高峰时段限额缩减，Opus 的 API 限额也大幅上调，官方把原因归结为新增算力上线。对多项目的人来说，取消高峰时段缩减这一条尤其实在——过去需要刻意避开高峰的排期顾虑少了一项。
撞了限额之后，别做的和能做的
先说一条最该记住的：客服无法实时手动重置或延长配额。 很多人撞了限额第一反应是去找客服解释项目多着急，这条路不通，与其耗在那里不如去调整排期。
真实可选的路径有这么几条：
- 开启 usage credits，在超出包含额度之后继续用；
- 改走 Claude Console 账号的按量付费；
- 升级档位。
这三条都要花钱，各自的价格与规则以官方当前页面为准，这篇不替官方下结论。对多项目的人，做决定前先算一笔账：你是真的额度不够，还是排期太散导致有效产出低。前者花钱能解决，后者花钱只是把浪费放大。额度用完时的完整处理思路可以看 Claude Code 额度用完了怎么办。
诚实说局限：别把重置周期写进脚本
这一节是这篇里最需要认真看的。
一份流传较广的开发者 gist 在 2026 年 6 月上旬约 11 天的时间里持续监测用量字段，得出的结论是”周限额”实际大约每 72 小时重置一次，而不是每 7 天；该 gist 的评论区还显示，不同账号、不同档位观察到的重置日差异很大。
这是第三方实测与官方文档表述不一致的地方，不能当成官方事实来引用。但对多项目的人来说，这个矛盾本身比结论更有价值：不要把任何假定的周期长度写进自动化脚本。 如果你打算写一个脚本，在”额度应该恢复了”的时刻自动触发一批任务，那你等于在赌一个连观测者之间都对不上的数字。稳妥做法是：需要知道余量就去查 /status 拿实时状态，别拿本地算的时间戳去推断。周限额本身的更多讨论见 Claude Code 周限额。
另外，多项目并行往往意味着团队协作，这里也要说清一个前提：Anthropic 官方公布的受支持地区列表不含中国大陆（anthropic.com/supported-countries），具体以官网当前的地区政策页为准。本文不提供也不背书任何第三方中转渠道。
小结
额度按账号算不按项目算，多开实例只解决并行，不会给你更多容量。5 小时窗从你发出的第一条 prompt 起算，所以每天第一条发给谁，就等于决定了这一窗归谁——把当天最需要深度投入的项目排在窗口开头，杂活攒堆处理。真正拉开差距的不是省着提问，而是每个仓库都备好项目说明文件、切项目就开新会话，把重复交代背景的成本压下来。撞了限额别找客服，客服无法手动重置，可选的是 usage credits、Console 按量付费或升级档位。最后一条：重置周期这件事连实测和文档都对不上，任何依赖假定周期的自动化脚本都不可靠，要余量就用 /status 查实时值。