GitLab Tightens Rate Limits as Coding Agents Drive Demand

Overview of New Rate Limits

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.

Impact on AI Agents and Automation

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.

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.

Detailed Limits by Subscription Tier

Under the new policy, GitLab will establish separate request allowances for Free, Premium and Ultimate subscribers. These limits apply to individual users and top‑level groups, affecting API traffic, web requests and authenticated Git operations over HTTPS.

• Unauthenticated traffic (applies to all projects)

  • 60 requests per hour per IP address

• Authenticated users

  • Free plan: 5 000 requests per hour
  • Premium plan: 15 000 requests per hour
  • Ultimate plan: 25 000 requests per hour

• Per‑minute burst limits

  • Free: 100 requests per minute
  • Premium: 1 250 requests per minute
  • Ultimate: 2 000 requests per minute

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.

Testing and Gradual Rollout

To help customers get ready, GitLab has scheduled two temporary enforcement periods:

• October 7 - October 14
  • Time: 8 a.m. to noon Pacific Time (four‑hour sessions)
  • Scope: 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.

Monitoring, Mitigation, and Purchasing Options

GitLab is also providing technical guidance for customers whose applications approach the new thresholds. Recommended measures include:

• Caching frequently requested information
• Batching API operations
• 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
• CI/CD job tokens

Doing this moves their traffic from the anonymous allowance to the higher limits associated with their subscriptions.

Enforcement and Error Handling

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.

Self‑Managed vs Cloud Differences

The restrictions apply exclusively to GitLab.com. Organizations operating GitLab Self‑Managed or GitLab Dedicated will continue to control their own rate limits.