Os limites de taxa no GitLab.com estão mudando

Artigo original ↗ Discussão no Hacker News ↗

Os novos limites de taxa do GitLab.com — 60 requisições por hora para usuários anônimos e 5.000 por hora no plano gratuito autenticado — estão gerando preocupação sobre quão facilmente humanos, pipelines de CI e contribuidores de código aberto conseguirão interagir com projetos públicos. Muitos veem a mudança como uma resposta ao pesado scraping automatizado por LLMs e bots, e como parte de uma tendência mais ampla em direção a paywalls, exigências de autenticação e uma web menos aberta. Outros argumentam que os limites são uma medida razoável de controle de custos que incentiva login ou self-hosting, embora ainda possam empurrar o hospedagem e a colaboração de código aberto para modelos mais comercializados ou fragmentados.

Razão Percebida: Scraping por LLM e Tráfego de Bots

  • Muitos assumem que os limites mais rígidos são motivados por scraping de LLM/agentes e tráfego automatizado.
  • Alguns argumentam que este é um passo inicial em uma mudança mais ampla: a web aberta não consegue lidar com scraping em escala de IA, então ela se tornará mais fechada, autenticada e com paywall.
  • Outros dizem que o scraping por IA poderia ser mitigado tecnicamente e está sendo usado como uma justificativa conveniente para monetização.

Impacto dos Novos Limites de Taxa

  • Usuários não autenticados recebem 60 requisições/hora por IP; vários observam que isso equivale a “uma requisição por minuto” em média, mas provavelmente é implementado como um token bucket.
  • As pessoas temem que isso:
    • Afete humanos atrás de CGNAT ou redes compartilhadas de escola/escritório.
    • Torne frustrante a navegação casual por issues/PRs ou carregamentos de múltiplas páginas da API.
  • Usuários gratuitos autenticados supostamente recebem 5.000 requisições/hora, o que muitos veem como razoável.
  • Alguns preveem uma recuada; outros acham que os limites ainda podem ser generosos demais dado o volume de bots.

Debate Mais Amplo sobre a Internet e Comercialização

  • A discussão deriva para pedidos por uma “internet não comercial”, sem anúncios ou bots, paga diretamente pelos usuários.
  • Contra-argumentos:
    • Tudo o que é valioso atrai comercialização e abuso.
    • Paywalls prejudicam usuários de menor renda; os ISPs já controlam o acesso.
    • Prova de identidade para bloquear bots minaria a privacidade e o anonimato.
  • Alguns sugerem abordagens de “indie web” (sites pessoais, webrings), mas observam que qualquer coisa popular atrairá predadores e spam.

Financiamento de Open Source e Paywalls

  • Ideia: cobrar de scrapers e compartilhar a receita com os repositórios, como royalties de streaming.
  • Outros alertam para incentivos de “efeito Cobra”: repositórios falsos e auto-scraping para obter pagamentos.
  • Preocupação de que limites genéricos mais orientações do tipo “faça upgrade para Premium/Ultimate” empurrem o OSS para configurações paywalled ou privadas.

GitHub e Outras Plataformas

  • Usuários observam fricção crescente no GitHub (detecção de bots, limites rígidos para usuários deslogados).
  • Comparações sugerem que 60/hora sem autenticação está se tornando uma norma de fato.
  • Alguns acreditam que o acesso generoso sem autenticação é insustentável em escala de IA.

GraphQL, APIs e Agentes

  • Vários recomendam usar GraphQL para agentes LLM para reduzir a contagem de requisições e o tamanho dos payloads.
  • Outros alertam que consultas GraphQL complexas podem ser caras para o servidor, atingir limites ocultos e sobrecarregar backends como GitHub/GitLab.
  • Visão geral: ótimo para agentes quando cuidadosamente delimitado; perigoso para servidores se não for.

Self-Hosting e Alternativas

  • Alguns estão migrando para plataformas Git auto-hospedadas (por exemplo, Forgejo, GitLab auto-hospedado) para evitar limites externos e futuros paywalls.
  • Sugestão de que, se você precisa de acesso amplo sem autenticação, deveria operar seu próprio mirror ou infraestrutura.