GitLab ties GitLab.com rate limits to your subscription to absorb AI agent traffic
Starting October 19, 2026, GitLab.com caps requests by subscription — 60 per hour per anonymous IP, 5,000/hour on Free, up to 25,000/hour on Ultimate — to absorb load from AI agents and automation. Authenticate your scripts and agents, and check your peaks before the October 7 and 14 brownout windows.
17 September 2026. GitLab announces that GitLab.com rate limits will now align with your subscription tier. 7 and 14 October 2026. Two test windows — brownouts — briefly switch the new caps on from 15:00 to 19:00 UTC. 19 October 2026. The limits take effect for Free and unauthenticated traffic, with Premium and Ultimate following in January 2027. Why it matters: load from coding agents and automation is exploding, and GitLab is choosing to regulate it by tier rather than let a single workload slow the platform for everyone else.
The new ceilings, in numbers
The change introduces two limits per plan for authenticated traffic: a sustained limit measured per hour, and a burst limit measured per minute. The sustained limit is the one that governs long-running use.
| Plan | Sustained limit (per hour) | Burst limit (per minute) |
|---|---|---|
| Unauthenticated | 60 per IP | — |
| Free | 5,000 | 100 |
| Premium | 15,000 | 1,250 |
| Ultimate | 25,000 | 2,000 |
The anonymous cap of 60 requests per hour per IP is the sharpest break: it applies wherever the request comes from, including automation that hits a paid account without authenticating. The burst limit is not a sustainable rate — sending at full speed for a solid hour exhausts the sustained allowance in roughly 50 minutes on Free, 12 minutes on Premium, and 12.5 minutes on Ultimate. In short: burst is a ceiling for short spikes, not a cruising speed.
Why now
The motivation is one sentence in the official post: demand is “climbing quickly,” and platform load is expected to “grow several times over this year.” The engine of that growth is named plainly — automation and the agent workloads teams are building on the platform. GitLab has already published dedicated limits for its MCP server, the standard gateway for coding agents, and this change generalises the logic: an agent polling the API in a tight loop consumes quota like a human user, but without ever getting tired.
The comparison with neighbouring platforms is telling. GitLab says it set the Free limit and the anonymous allowance “to match the industry norm,” while Premium and Ultimate are “more generous, at levels other platforms reserve for their enterprise tiers or don’t publish at all.” In other words, the anonymous cap is deliberately punitive to push integrations toward authentication, and the paid tiers are calibrated not to penalise ordinary human work.
The deeper signal is that agents are no longer an incidental load. A human makes a few dozen API calls per session; a coding agent chains hundreds of requests — reading files, posting reviews, polling pipeline status — without ever stopping. GitLab had already introduced dedicated limits for its MCP server, the standard agent interface, and this announcement extends the same logic across the whole API. What is new is not technical, it is accounting: for the first time, the cost of an agent is measured in API quota rather than a seat.
What this means for your pipelines
When a limit is crossed, GitLab.com responds with HTTP 429 Too Many Requests and a Retry-After header stating how long to wait, plus RateLimit-Limit, RateLimit-Remaining and RateLimit-ResetTime headers on every response, throttled or not. A client that reads its own headers “mostly fixes itself,” GitLab notes: honouring Retry-After and backing off exponentially recovers faster than retrying immediately.
Two traps deserve attention. The first is unauthenticated CI/CD: a script that calls the API without a personal access token, an OAuth token or a job token falls back to the anonymous 60 requests/hour. The second is tight-loop polling: an agent that checks a status every second burns through a monthly quota in hours. GitLab advises batching, caching, paginating and honouring Retry-After — and watching RateLimit-Remaining to slow down before you exhaust the quota.
The new tiers do not replace the current limits, they stack on top of them. The documentation notes that “whichever limit is lower applies”: authenticated API traffic, for example, remains capped at 2,000 requests per minute across all plans. On Ultimate, the 2,000-per-minute burst therefore meets the existing ceiling; on Free and Premium, the plan burst fires first. For an agent workload, that means two floors of ceilings to watch, not one.
# Read the quota headers before pushing harder
curl -s -D - -o /dev/null \
-H "PRIVATE-TOKEN: $GITLAB_TOKEN" \
"https://gitlab.com/api/v4/user" \
| grep -iE 'ratelimit|retry-after'The economics are deliberate. GitLab is effectively moving the anonymous tier down to near-zero — 60 requests per hour is enough for a status badge and little else — while making Premium and Ultimate allowances generous enough that paying teams never think about them. The message to the long tail of unauthenticated scrapers and free-tier agents is blunt: authenticate and upgrade, or be throttled.
What this does not change
The scope matters, if only to avoid panic. The change applies only to GitLab.com: GitLab Self-Managed and GitLab Dedicated keep limits controlled by the operator. Your data and repositories remain exportable at any time. And ordinary human work — browsing the UI, pushing and pulling with git, running CI/CD within your plan — “carries on exactly as it does today.” GitLab estimates that “almost all users are already inside the new limits.”
The 7 and 14 October brownouts exist precisely to validate that assumption: during those windows the new caps switch on and then back off, with nothing else about the service changing. That is your chance to measure how your real workloads behave before the hard date of 19 October.
On the observability side, GitLab is building a product view, due later this year, that shows your usage against your plan’s limits. Until then, the RateLimit-Remaining header is your fastest signal: a client that polls it can throttle itself before the 429 arrives. For teams running many agents behind a single NAT or proxy, remember the anonymous cap is per IP address — ten agents sharing one egress IP will collectively burn the 60-requests-per-hour allowance in minutes unless each one authenticates.
The brownout approach is worth stealing. By switching the limits on for two four-hour windows weeks ahead of the real date, GitLab turns a breaking change into a rehearsal: teams get to watch their own dashboards light up with 429s while there is still time to fix the code, instead of discovering the break in production on 19 October.
Verdict
If you run coding agents or automation against GitLab.com, authenticate them now with a personal access token or a CI/CD job token: that single change moves a workload from the anonymous 60 requests/hour to your plan’s allowance, up to a thousand times higher. Measure your peaks during the 7 and 14 October brownouts, and identify heavy Free workloads that will hit the sustained ceiling. If your integration genuinely cannot authenticate, email [email protected] before the deadline rather than after. If you are on GitLab Self-Managed or Dedicated, this change does not touch you — but watch your own agents: the pressure that pushed GitLab to regulate will hit your instance too.