GitLab is introducing new rate limits for its cloud-based DevOps platform as growing demand from AI agents and automated development tools increases pressure on its infrastructure.
The changes, which begin October 19, will restrict the volume of requests users can send to GitLab.com based on their subscription plans. Free-tier customers and users making unauthenticated requests will face the new restrictions first, while Premium and Ultimate customers will see changes in January 2027.
The restrictions address a challenge facing developer platforms as AI coding agents generate vast volumes of automated requests. GitLab forecasts several times more traffic on its infrastructure for 2026, prompting the company to establish usage limits designed to maintain service performance.
GitLab is certainly not alone in addressing this issue. GitHub and Anthropic have also introduced rate limits as AI-powered development tools greatly boost the use of computing and network resources.
Automated Workloads
Under the new policy, GitLab will establish separate request allowances for Free, Premium and Ultimate subscribers. These limits will apply to individual users and top-level groups, affecting API traffic, web requests and authenticated Git operations over HTTPS.
The most significant immediate change concerns unauthenticated traffic, which will be limited to 60 requests per hour for each IP address. Authenticated users on the Free plan will be allowed 5,000 requests per hour, while Premium subscribers will receive 15,000 and Ultimate subscribers 25,000. GitLab is also establishing per-minute limits to accommodate short bursts of activity: 100 requests for Free, 1,250 for Premium and 2,000 for Ultimate.
The 60-request limit applies regardless of the subscription associated with a project. For example, an automated tool accessing a paid GitLab account without supplying credentials will receive the lower anonymous allowance.
For companies using AI agents, this distinction can make a difference. Automated development tools can generate substantial API traffic. Without proper authentication, these applications could encounter restrictions even when operating within a paid enterprise environment.
GitLab said its analysis of customer activity shows that nearly all users currently operate below the new thresholds. The company expects the restrictions to primarily affect demanding automation workloads and a relatively small number of Free-tier customers.
October Testing Schedule
To help customers get ready, GitLab has scheduled two temporary enforcement periods on October 7 and October 14, running from 8 a.m. to noon Pacific Time. During these four-hour sessions, Free-tier and unauthenticated traffic will operate under the new limits, allowing developers to identify potential problems before permanent enforcement begins October 19.
Customers needing extra capacity will have another option. GitLab is developing a mechanism to purchase request allowances beyond standard subscription limits, with further details expected later this year.
The company is also preparing an interface that will display customer usage against plan limits. Until that feature arrives, developers can monitor the RateLimit-Remaining header in API responses to determine their available capacity.
GitLab is also providing technical guidance for customers whose applications approach the new thresholds. Recommended measures include caching frequently requested information, batching API operations and reducing unnecessary polling.
Premium and Ultimate customers making authenticated requests will retain their existing allowances until January. Developers can authenticate requests using personal access tokens, OAuth tokens or CI/CD job tokens. Doing this moves their traffic from the anonymous allowance to the higher limits associated with their subscriptions.
When an application exceeds its allowance, GitLab will return an HTTP 429 response. The accompanying Retry-After header tells the application when it can resume sending requests.
The restrictions apply exclusively to GitLab.com. Organizations operating GitLab Self-Managed or GitLab Dedicated will continue to control their own rate limits.