代码托管平台免费、不限速对外开放接口的旧秩序，正被加速改写。GitLab 宣布将于 2026 年 10 月 19 日起，在 GitLab.com 正式推行基于订阅层级的分级速率限制（Rate Limits），未认证请求额度被直接压缩至每小时 60 次/IP；同时官方透露，年内将筹备推出超出标准限额的付费加购机制。
表面上，这是一次防范自动化爬虫与高负载作业的稳定性微调，但背后其实是一场精准的商业划界。随着生成式 AI 和自主编程代理（AI Coding Agents）带来倍数级膨胀的并发调用，以 GitLab 为代表的代码托管平台开始告别宽容时代，用严苛的配额机制将匿名调用彻底锁进认证围栏，并为日后的 API 用量计费铺平道路。
未认证流量暴跌 99.8%，免密调用公地终结
新规最核心的变化，在于对外部请求身份的强制重构。自 2026 年 10 月 19 日起，GitLab.com 将彻底打破过往较为宽松的访问限制。对于未携带 Token 的未认证匿名请求，配额将从过去的每分钟 500 次/IP 骤降至每小时 60 次/IP，降幅高达 99.8%。这意味着匿名调用不仅失去了并发能力，就连常规的健康检查或状态拉取都将变得异常脆弱。
已认证请求则严格按照账户层级分级执行：Free 免费计划在 10 月 19 日同步生效，提供持续 5,000 次/小时配额；而付费的 Premium 和 Ultimate 计划将于 2027 年 1 月落地，配额分别提升至持续 15,000 次/小时与 25,000 次/小时。
为验证现有业务链的耐受力，GitLab 在全面实施前设置了两次停网演练（Brownout）：分别定于 2026 年 10 月 7 日和 10 月 14 日的 15:00 至 19:00 UTC。在这两个窗口期内，新限流规则将短暂上线 4 小时后撤回，专门用于暴露那些仍在使用匿名调用的外围脚本。
对于依赖外部自动化工具的工程团队而言，这意味着过去习惯性的免密拉取将全面碰壁。
- 风险.使用统一 NAT 网关出口的企业内网，所有员工若共用同一公网 IP 进行未认证请求，60 次的额度可能在数秒内耗尽，导致整间办公室遭遇隐蔽的 HTTP 429 报错。
代码拉取首次入池，突发限制成为隐蔽杀手
比小时总额削减更棘手的，是两个常常被开发者忽视的深层规则变更。
首先是配额池的统计范围发生了根本转变。过去，开发者通常将 REST 或 GraphQL API 与日常代码操作视作两套独立的通道。但在新体系下，已认证的 Git-over-HTTPS 请求被直接并入同一配额池中。如果一条构建流水线频繁执行 git fetch 或 git clone，它所消耗的将不再只是网络带宽，而是直接削减系统调用 API 的剩余额度。
其次是每分钟的突发上限（Burst limit）设定极为苛刻。虽然 Free 计划名义上保留了 5,000 次/小时，但其每分钟突发上限仅为 100 次/分钟；即便是在 Ultimate 档，突发上限也仅有 2,000 次/分钟。若团队在持续集成流水线中配置了高并发并发拉取，极易在几秒钟内打穿分钟级突发阈值，即使此时一小时的总限额还剩大半。
此外，当特定功能端点本身的限速规则与订阅层级配额重叠时，GitLab 将以更严格的一方作为判定标准。而根据官方支持策略，普通技术支持团队无权为任何单一租户手动调高或豁免限额，遇到容量阻碍只能转向商业沟通。
横向对比：向高价值客户倾斜的博弈算盘
放眼整个行业，代码托管平台对流量的收紧并非孤立事件。在 GitHub 与 Bitbucket 的既有限流矩阵中，匿名访问早已受到不同程度的压制。但将 GitLab 的方案与 GitHub 放在同一坐标系下审视，可以看清其截然不同的商业分流意图。
| 订阅计划与维度 | GitLab.com 持续限额 | GitLab.com 突发限制 | GitHub 对照配额 | 核心差异与判断 |
|---|---|---|---|---|
| 未认证请求 | 60 次 / 小时 / IP | 极低单次熔断 | 60 次 / 小时 / IP | 双方底线一致，匿名抓取空间几乎归零 |
| Free 免费层 | 5,000 次 / 小时 | 100 次 / 分钟 | 5,000 次 / 小时 | 基础额度相当，但 GitLab 额外卡死突发峰值 |
| 企业高阶层 | 25,000 次 / 小时 (Ultimate) | 2,000 次 / 分钟 | 15,000 次 / 小时 (Enterprise Cloud) | GitLab 付费上限更高，全力招揽大体量客户 |
从数据对照中可以看出，GitLab 在免费层的收缩近乎与 GitHub 看齐，但在最高层级的 Ultimate 计划中，其实际给出的 25,000 次/小时配额，明显高出 GitHub Enterprise Cloud 公开的应用上限（15,000 次/小时）。
这种两极分化的设计说明，GitLab 无意做全方位的普惠限制，而是在明确地通过防御性手段完成用户筛洗：把难以带来商业收益的高频匿名抓取与免费重载自动化阻挡在门外，同时向愿意为 Ultimate 买单的大型企业提供更充裕的资源池。
从按席位收费走向用量消费的商业铺垫
在这份公告的技术细节背后，隐藏着 GitLab 商业模式转型的明确信号。官方在应对高用量需求时明确提及，正在筹备推出超出标准计划限制的额外容量付费加购（Capacity Add-on）机制。
长期以来，SaaS 软件行业特别是研发协作工具，主要依靠按席位收费（Seat-based）维持营收。但进入自动化 Agent 广泛介入软件工程的阶段后，代码平台的主要资源消耗者正在由人转变为无休止运行的程序。一个 5 人的初创团队，如果接入了自主代码审查与自动化拉取代理，其对服务器 API 的吞吐消耗可能抵得上过去数百名普通工程师。
席位制衡量的是肉身数量，而算力时代计费的真正标尺只能是吞吐量。
如果平台继续沿用单一的人头授权模型，就必然面临算力与带宽成本呈倍数增长，而商业回报无法匹配的失衡局面。将 Git 操作并入配额池、严控未认证流量、推出用量加购通道，正是将计费颗粒度从席位向席位加用量（Usage-based）混合模式过渡的关键一步。
- 结论.开发团队现阶段应当迅速清理流水线中的无认证拉取，在所有 CI/CD 脚本中显式注入 Job Token，并在应用端严格引入指数退避（Exponential Backoff）算法解析 429 响应头，以避免在 10 月的停网演练中遭遇构建崩溃。