Los límites de tasa en GitLab.com están cambiando
Los nuevos límites de tasa de GitLab.com — 60 solicitudes por hora para usuarios anónimos y 5,000 por hora en el nivel gratuito autenticado — están generando preocupación sobre la facilidad con la que humanos, pipelines de CI y contribuyentes de open source podrán interactuar con proyectos públicos. Muchos ven el cambio como una respuesta al scraping automatizado intensivo por parte de LLM y bots, y como parte de una tendencia más amplia hacia muros de pago, requisitos de autenticación y una web menos abierta. Otros argumentan que los límites son una medida razonable de control de costes que incentiva iniciar sesión o autoalojar, aunque temen que esto aún empuje el alojamiento y la colaboración de open source hacia modelos más comercializados o fragmentados.
Razón percibida: scraping de LLM y tráfico de bots
- Muchos asumen que los límites más estrictos están motivados por el scraping de LLM/agentes y el tráfico automatizado.
- Algunos sostienen que esto es un primer paso en un cambio más amplio: la web abierta no puede soportar el scraping a escala de IA, así que se volverá más cerrada, autenticada y con muro de pago.
- Otros dicen que el scraping de IA podría mitigarse técnicamente y que se está usando como una justificación conveniente para la monetización.
Impacto de los nuevos límites de tasa
- Los usuarios no autenticados reciben 60 solicitudes/hora por IP; varios señalan que eso es “una solicitud por minuto” en promedio, pero probablemente implementado como un cubo de tokens.
- A la gente le preocupa que esto:
- Afecte a personas detrás de CGNAT o redes compartidas de escuelas/oficinas.
- Haga frustrante la navegación casual de issues/PRs o las cargas de varias páginas de la API.
- Según los informes, los usuarios gratuitos con sesión iniciada получают 5,000 solicitudes/hora, algo que muchos ven como razonable.
- Algunos prevén un retroceso; otros piensan que los límites aún podrían ser demasiado generosos dado el volumen de bots.
Debate más amplio sobre Internet y la comercialización
- El hilo deriva hacia llamados a un “internet no comercial” sin anuncios ni bots, pagado directamente por los usuarios.
- Contraargumentos:
- Todo lo valioso atrae comercialización y abuso.
- Los muros de pago perjudican a los usuarios de menores ingresos; los ISP ya controlan el acceso.
- La prueba de identidad para bloquear bots socavaría la privacidad y el anonimato.
- Algunos sugieren enfoques de “indie web” (sitios personales, webrings), pero señalan que cualquier cosa popular atraerá depredadores y spam.
Financiación del open source y muros de pago
- Idea: cobrar a los scrapers y compartir los ingresos con los repos, como las regalías del streaming.
- Otros advierten de incentivos tipo “efecto Cobra”: repos falsos y auto-scraping para cobrar pagos.
- Preocupa que los límites genéricos más la guía “actualiza a Premium/Ultimate” empujen efectivamente al OSS a configuraciones con muro de pago o privadas.
GitHub y otras plataformas
- Los usuarios observan una fricción creciente en GitHub (detección de bots, límites estrictos sin sesión iniciada).
- Las comparaciones sugieren que 60/hora sin autenticación se está convirtiendo en una norma de facto.
- Algunos creen que el acceso generoso sin autenticación es insostenible a escala de IA.
GraphQL, APIs y agentes
- Varios recomiendan usar GraphQL para agentes LLM para reducir el número de solicitudes y el tamaño de las cargas útiles.
- Otros advierten que las consultas GraphQL complejas pueden ser costosas para el servidor, topar con límites ocultos y sobrecargar backends como GitHub/GitLab.
- La visión general: excelente para agentes cuando se acota con cuidado; peligroso para los servidores si no.
Autoalojamiento y alternativas
- Algunos se están moviendo a plataformas Git autoalojadas (p. ej., Forgejo, GitLab autoalojado) para evitar límites de tasa externos y futuros muros de pago.
- Se sugiere que, si necesitas acceso amplio sin autenticación, deberías ejecutar tu propio mirror o infraestructura.