GitLab Is Putting Its API on a Meter: What the October 19 Rate Limits Mean for Your Agents and CI

A single watch -n 30 curl against the GitLab API — one request every 30 seconds, the most innocent polling loop imaginable — will blow through GitLab.com's new anonymous allowance twice over. Starting October 19, 2026, unauthenticated API traffic gets 60 requests per hour per IP address, down from 500 per minute today. That is a 500-fold cut, and it lands alongside the first tier-aligned rate limits in GitLab.com history: Free, Premium, and Ultimate accounts each get their own hourly and per-minute budgets.

GitLab announced the change on September 17, and the stated load driver should get your attention if you run automation: "the automation and agent workloads teams are building on the platform." Platform load is expected to grow several times over within the year. Whether you poll the API from CI, run coding agents against your repos, or mirror public projects anonymously, here is exactly what changes, whether it breaks you, and what to do about it — in cheapest-first order.

The new meter, in one table​

The published per-plan limits come in two flavors per tier: a sustained hourly budget that governs your usage, and a per-minute burst ceiling that caps short spikes. The hourly budget always wins for sustained work.

Three things to notice before you do any math:

• Free and unauthenticated go first, on October 19. Premium and Ultimate limits do not change until January 2027. If you are on a paid plan and authenticated, nothing moves for you this year.
• The meter covers API requests, web requests, and authenticated Git over HTTPS. Unauthenticated Git over HTTPS is explicitly excluded — it stays under today's generous per-IP limit — so anonymous git clone and git pull are unaffected. This meter is aimed at API-shaped traffic, not at fetching code.
• Today's limits stay on underneath. GitLab checks your plan limit first, then the current limits, and whichever is lower applies. The current unauthenticated API allowance of 500 requests per minute per IP is what collapses to 60 per hour: 30,000 requests per hour down to 60. Hence the 500x.

One more calibration point, and it is a compliment to GitLab's framing: Free's 5,000 authenticated requests per hour and the 60-per-hour anonymous allowance are exactly GitHub's long-standing numbers. GitLab says the Free limit "matches the industry norm," and that checks out. The authenticated Free tier is not punitive — the bite is concentrated in anonymous traffic and short bursts.

What 60 an hour and 100 a minute actually buy you​

Limits are only real when you translate them into cadences. So let's do that.

Anonymous traffic: 60 per hour means one request per minute, on average. A status check that polls every 5 minutes uses 12 of its 60 and is fine. A dashboard refreshing every minute sits exactly at the ceiling with zero headroom for a retry. And that 30-second poll loop from the intro burns 120 an hour — double the budget — and starts eating 429 Too Many Requests halfway through each hour. If you have any unauthenticated poller on a sub-minute interval pointed at GitLab.com, it breaks on October 19. Full stop.

Also note the trap GitLab calls out explicitly: unauthenticated requests are capped "no matter where they come from, including automation running against a paid account without credentials." A Premium or Ultimate account does not protect traffic that arrives without a token. The meter keys off the credential, not the account that owns the repo being hit.

Authenticated bursts: the per-minute ceiling binds before the hourly budget does. GitLab publishes the exhaustion math itself: holding the per-minute burst rate consumes the whole hourly budget in about 50 minutes on Free, 12 minutes on Premium, and 12.5 minutes on Ultimate. In other words, treat the burst figure as spike protection, never as a sustainable rate.

The Free burst limit of 100 per minute is the number most likely to surprise a team that did its hourly math and relaxed. Consider a coding agent that, per task, lists merge requests, fetches a handful of files, reads two pipeline statuses, and posts a comment — call it 30 API calls in a minute-long burst. One agent is fine. Four agents bursting at once under the same user blow past the 100-per-minute ceiling while the hourly dashboard still shows plenty of headroom. Hourly budgets are for planning; burst limits are what page you.

Agent fleets: do the fleet math, not the single-agent math. At 50 calls per task, Free's 5,000 hourly budget supports 100 tasks per hour for one user — generous for a human, but a fleet of 10 agents each completing a 50-call task every 6 minutes lands exactly on 5,000. Anything beyond that, or any shared service account that multiplexes several agents' traffic through one user identity, needs Premium's 15,000, separate user identities per agent, or a serious caching layer. The per-user scoping cuts both ways: it isolates your agents from each other's usage only if they actually authenticate as different users.

What throttling looks like: a 429 Too Many Requests with a Retry-After header giving seconds until reset, plus RateLimit-Limit and RateLimit-Remaining headers on every response — throttled or not — so you can watch the gauge drain. One honest caveat from the docs: the Projects, Groups, and Users APIs do not return the informational headers, and some limits are not reflected in headers at all, so you can still get a surprise 429 with quota showing on the previous response. Honor Retry-After, back off exponentially, and slow down as RateLimit-Remaining approaches zero rather than treating it as exact.

October 7 and 14 are your fire drill​

GitLab is running two preview brownouts — October 7 and October 14, 15:00 to 19:00 UTC — during which the new limits switch on for Free and unauthenticated traffic, then switch back off. Premium and Ultimate authenticated traffic is unaffected in both windows. Engineers call these brownouts; you should call them a free load test with a known answer key.

Use them deliberately:

1. Inventory your anonymous traffic now. Grep CI configs, cron jobs, dashboards, and status-page integrations for gitlab.com/api calls without an Authorization header or token. Every hit is a suspect.
2. Watch the brownout windows live. Alert on 429 responses from gitlab.com during 15:00–19:00 UTC on both days, and log RateLimit-Remaining values on your busiest integrations to see how close to the ceiling you actually run.
3. Compare your busiest minute against your plan's limits. That is GitLab's own recommended self-check: your peak minute, not your average hour, is what the burst ceiling grades.
4. Fix what breaks, then confirm in the second window. The two-week spacing is deliberate — October 7 finds the breakage, October 14 verifies the fix, October 19 makes it permanent.

A product usage view showing consumption against plan limits is promised for later this year, but it is not here yet. Until then, the response headers are your only gauge — instrument them during the brownouts, not after the cutoff.

The fix list, cheapest first​

If the brownouts turn red, work this list top to bottom. Each step is strictly more expensive than the last.

1. Authenticate everything. This is the single highest-leverage change: moving anonymous traffic to any credential jumps it from 60 per hour to your plan's full hourly budget — an 83x increase on Free alone. Personal access tokens, OAuth tokens, and CI/CD job tokens all count. Audit for the classic failure: automation that hits a paid group's repos while sending no credentials at all. That traffic is metered as anonymous regardless of who owns the target.

2. Stop polling like it is free. Batch requests, cache responses, use pagination instead of repeated filtered calls, and honor Retry-After instead of retrying blind. Most integrations written against the old 500-per-minute anonymous allowance never needed discipline; the new meter prices indiscipline directly. Conditional requests and webhooks instead of poll loops are the structural fix for the "dashboard refreshing every 30 seconds" pattern.

3. Split shared identities. If several agents or services share one token, they share one budget. Per-user scoping means giving each heavy consumer its own identity multiplies the budget linearly — and if you belong to multiple top-level groups, your limit is the highest tier available to you, so an Ultimate membership anywhere lifts that user everywhere.

4. Upgrade the tier, or buy headroom. Premium triples the sustained budget and multiplies burst headroom 12.5-fold over Free; Ultimate goes further still. And if your needs exceed even Ultimate's allowance on an ongoing basis, GitLab says an option to purchase capacity above plan limits is in design, with details later this year — contact your account team or limits@gitlab.com in the meantime. That address is also the escape hatch for legitimate anonymous patterns that genuinely cannot authenticate, like public status badges.

5. If you run a busy public project, GitLab offers three options: ask the automation hitting your project to sign in (moving it onto its own budget), make the project private if the traffic is not your real audience, or upgrade for higher limits. Note what this implies: popular public projects now have a mild incentive to either gate their audience or pay — a dynamic worth watching for the open-source ecosystem on GitLab.com.

The self-hosted counterfactual​

Here is the sentence that matters most for the self-hosting crowd, quoted from the announcement's what-doesn't-change list: "GitLab Self-Managed and GitLab Dedicated limits stay with your operator. This is only a GitLab.com change." If you run your own instance, your rate limits are whatever you configure — there is no per-tier API meter at all, because there is no tier. Gitea and Forgejo go further: no built-in API rate limit by default, with throttling left entirely to the instance operator.

That makes this announcement the latest entry in a playbook GitLab.com observers know well. The Free tier has been tightening for years: five users per namespace, 400 CI/CD minutes a month, 5 GB of storage with 10 GB of transfer, a 2021 requirement for credit-card details on free accounts to fight crypto-mining abuse, and the 2022 plan to delete dormant free projects that was walked back only after community backlash. Each step was individually defensible — abuse prevention, cost control, aligning free usage with conversion — and each one pushed a cohort of heavy users to weigh the same question: pay per seat for metered SaaS, or operate the forge on machines you own.

This round fits the pattern precisely, including the load driver. GitLab expects platform load to grow several-fold within the year, driven substantially by agent and automation workloads — and it is not alone. As InfoWorld put it, GitLab has joined a broader "rush to slow AI coders," alongside Anthropic throttling Claude subscriptions and GitHub moving Copilot toward usage-based billing. When every hosted platform meters the same agent-driven load spike simultaneously, the self-hosted counterfactual gets comparatively cheaper with each announcement: your agents can hammer your own Gitea or self-managed GitLab as hard as your hardware allows, and the only rate limit is the one you chose.

That is not an argument that everyone should self-host tomorrow — operating a forge is real work, and GitLab is correct that almost all users sit inside the new limits. It is an argument that heavy API consumers should price the exit. If your agent fleet's GitLab.com budget requires Premium seats plus forthcoming overage purchases, compare that against a Hetzner box running Forgejo with no meter at all. The honest spreadsheet now has a row it did not have last month.

What to watch next​

The story does not end on October 19. Three follow-ups are already on the calendar: the Premium and Ultimate enforcement in January 2027 (paid teams get a grace period, not an exemption), the in-product usage view promised later this year (which finally makes the meter legible), and the purchasable-headroom option still in design (which will reveal the actual dollar price of API capacity above your plan). Watch all three before you conclude your current tier is safe.

The deeper trend is unmistakable: agent workloads are forcing every hosted development platform to put its API on an explicit meter. GitLab's version is unusually well-signposted — published numbers, two brownouts, a four-week warning, and GitHub-parity Free limits. Take the gift: inventory your anonymous traffic this week, instrument the October 7 brownout, and authenticate everything before October 19. The teams that treat the brownouts as a fire drill will experience this as a non-event. The teams that discover their anonymous pollers via a wall of 429s on a Monday morning will experience it very differently.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. If hosted meters keep tightening, owning the underlying compute starts looking better every quarter. Star the repo on GitHub or deploy your first app today.