GitLab.com（GitLab.com）为各种规模的团队托管数百万个需要可靠平台的项目。需求正在快速攀升，我们预计今年平台负载将增长数倍。可预测的访问限额让包括自动化与代理工作负载在内的所有用户保持快速。为在扩展中维持这一点，我们将更新限额方式。从2026年10月19日起，GitLab.com 的限额将依据订阅层级划分，免费账户与未认证请求率先于10月19日生效，Premium 和 Ultimate 则移至2027年1月。
正文
GitLab.com 托管着数百万个项目，平台负载今年预计翻几倍。可预期的速率限制能让每个人用得顺畅，包括团队在平台上跑的自动化和代理任务。
为了撑住规模，我们要更新速率限制规则。从 2026 年 10 月 19 日起，GitLab.com 的速率限制将按订阅层级划分。免费账号和未认证请求先在 10 月 19 日调整，Premium 和 Ultimate 在 2027 年 1 月跟进。
变更内容
限制与订阅层级挂钩。 Free、Premium、Ultimate 各有自己的限制，按用户和顶层组分别计算。Free 于 10 月 19 日生效，Premium 和 Ultimate 在 2027 年 1 月。
登录即用满额限制。 已认证请求按你的订阅计划计算；不带凭据的请求每个 IP 地址每小时限 60 次。
各计划的具体限制见速率限制文档。
10月19日会发生什么
针对 Free 和未认证流量，会在 10 月 7 日、10 月 14 日 15:00–19:00 UTC 安排两次预览窗口（工程师叫 brownouts，即短时开启新限制再关掉，服务其他部分不变），让你在新限制永久生效前几周，真实看看自己的工作负载表现。已登录的 Premium 和 Ultimate 请求不受影响。未认证请求无论来源一律受限，包括对着付费账号却无凭据跑的自动化。
10 月 19 日新限制正式生效。
这些限制是根据 GitLab.com 实际使用情况，并参考同类平台设定的。Free 和匿名额度符合行业惯例，Premium 和 Ultimate 更宽裕，达到别家留给企业版或不公开的级别。几乎所有用户已在新限制内，无感知。
如果你接近限制
接近限制时，先给请求做认证：调用 personal access token、OAuth token 或 CI/CD job token，就能从匿名每小时 60 次挪到计划的高得多的限制上。
再看看 API 调用方式。批处理、缓存、分页很有用，紧密轮询很快耗光额度。超限会收到带 Retry-After 头的 HTTP 429，客户端读懂响应头基本能自愈；指数退避比立即重试恢复更快。
升级到 Premium 或 Ultimate 也能提高限制。
若长期需要更高限制，我们正在做超计划购容的方案，细节今年晚些公布；有需要可联系客户团队或发邮 limits@gitlab.com。
什么变，什么不变
设限是为了不让单一负载拖慢所有人。普通登录操作不是目标，绝大多数用户日常无变化：逛 UI、编辑器里干活、git 推拉、计划内跑 CI/CD 都照旧。少数重型自动化和 Free 层负载会触顶。
不变的有：
- 你随时能访问和导出自己的数据和仓库。
- GitLab Self-Managed 和 GitLab Dedicated 限制归你的运维方，这只是 GitLab.com 的变更。
- 后续再加限制我们会先通知。
提醒： 务必认证请求以获得更高限制。
常见问题
怎么知道是否影响我？
拿最忙的一分钟对比计划公布的限制，多数客户离得远。最快看 API 响应里的 RateLimit-Remaining 头知剩余额度；今年晚些会出产品内用量视图。
我的项目公开又繁忙，怎么办？
三招：让调用项目的自动化登录；若流量非目标受众，设私有挡掉匿名；或升 Premium/Ultimate 拿高限制。
我属于多个顶层组？
用户限制取你能用到的最高订阅层；若是 Ultimate 组成员，就用 Ultimate 限制。
触限会怎样？
收到带 RateLimit-* 头和 Retry-After 的 429 Too Many Requests，等够时间再试。
集成真不能认证呢？
发邮 limits@gitlab.com，比如公开状态徽章属合理匿名模式，担忧受影响就来信。
适用于 Self-Managed 或 Dedicated 吗？
不适用，仅 GitLab.com 变更。
其他资源
评论
社区普遍将限流归因于大模型智能体与自动化流量倒逼平台控制成本，但在未登录配额是否过分严苛、以及开源访问权是否应被牺牲上分歧明显，少数人转向自托管或预测政策回退。
认为限流是 LLM 抓取和自动化流量倒逼的结果
- 较多人指出未登录限流源于大模型智能体大规模爬取仓库及闲置 CI 流水线滥用，导致平台带宽与成本压力剧增，甚至加剧网络整体恶化。
- > Gitlab 为机器人流量支付巨额成本，其中大多恶意或纯垃圾（@bearjaws）
认为未登录 60 次/小时限制过于严苛
- 较多人抱怨无凭证每分钟仅 1 次请求，在校园或办公室共用网络下，几个人浏览源码就会耗尽配额，损害开源随意访问精神。
- > 对校园或办公网络来说太低了，几个人看源码就能很快耗光（@lateatdesk）
认为认证后配额充足且匿名访问本应淘汰
- 较多人澄清免费计划实际有每小时 5000 次请求完全够用，类比 Docker 限制匿名拉取，指出想要匿名应自托管镜像。
- > 未登录糟糕但免费计划每小时五千次没问题，匿名访问早该淘汰，要匿名就自己镜像（@solatic）
预测平台将迫于压力撤回限流
- 少数人用倒计时玩笑表达认为政策不可持续、预料不久后回退。
- > 十秒倒计时，准备撤回……（@throwitaway222）
建议通过回馈开源或改变架构缓解矛盾
- 少数人提议平台应像流媒体那样向被抓取的开源项目分成，或让智能体在去中心化 CI 中自验证明以减少 API 呼叫，并希望为开源留豁免。
- > 给被抓取仓库提供分账回扣能资助开源，也是对抗竞品的大差异化（@cush）
有价值的补充
- 对接大模型智能体时优先用 GraphQL 而非 REST，因能约束返回字段与跨类型联结，同等上下文窗口下可读取数十倍数据并大幅减少请求数（@bob1029）。
- 自托管代码平台时可利用 HTTP 402 状态码让智能体先付费再获取抓取权限，试探自动化工具的授权边界（@xyst）。