GitHub está apretando el acceso sin login, y ya no solo en su API. En los últimos meses, varios usuarios han empezado a recibir errores 429 de “Too many requests” después de apenas unos clics al navegar repositorios públicos. Si trabajas con código abierto, documentación técnica o simplemente sueles revisar un archivo sin iniciar sesión, el cambio te toca directo.
La parte importante es esta: GitHub sí confirmó en mayo de 2025 que endureció los límites para solicitudes sin autenticación, con el argumento de frenar scraping abusivo y proteger la estabilidad de la plataforma. El problema es que, en la práctica, la fricción ya no parece quedarse solo en clones, API y descargas de archivos raw. También está golpeando algo mucho más básico: mirar código público en la web como un humano normal.
¿Qué cambió exactamente en GitHub?
El 8 de mayo de 2025, GitHub publicó una actualización oficial sobre sus límites para solicitudes no autenticadas. Ahí explicó que los nuevos topes afectarían operaciones como clonar repositorios por HTTPS, usar la API REST sin credenciales y descargar archivos desde raw.githubusercontent.com. La razón declarada fue un aumento en la actividad de scraping contra su API.
En su documentación técnica, GitHub mantiene que la API REST pública sin autenticación tiene un límite primario de 60 solicitudes por hora por IP. En cambio, una cuenta autenticada con token personal sube a 5.000 solicitudes por hora, y ciertas configuraciones enterprise llegan a 15.000. En papel, eso suena razonable: si automatizas más, autentícate. El lío empieza cuando esa lógica termina afectando usos casuales del sitio web.
Eso es lo que muestran varias discusiones recientes en la propia comunidad de GitHub. Hay usuarios que reportan errores 429 al abrir apenas tres archivos de un repositorio sin iniciar sesión. Otros dicen que una búsqueda simple dentro de un repo ya dispara el mensaje de “Too many requests” casi de inmediato. Lo relevante es que GitHub sí respondió en una de esas discusiones: Martin Woodward, vicepresidente de experiencia de desarrolladores en la empresa, dijo que el bloqueo al browsing humano fue una “consecuencia no intencional” de los límites aplicados contra el scraping anónimo, y que ajustaron la lógica para reducir los falsos positivos. O sea: el problema fue real, GitHub lo reconoció y, al menos según su versión, intentó afinar el throttle.
El problema no es solo el rate limit: es a quién castiga primero
GitHub tiene un argumento válido: el scraping masivo existe, cuesta plata y puede degradar el servicio. Nadie discute eso. El problema es que el remedio parece estar castigando primero al visitante anónimo común, al estudiante que llega desde una búsqueda, al usuario que abre un issue enlazado desde documentación, o al curioso que quiere revisar una librería antes de decidir si la instala.
En otras palabras, el costo del abuso lo está pagando el browsing casual del código abierto. Y eso pega justo en una contradicción incómoda. GitHub vive del ecosistema open source, pero cuando endurece la puerta de entrada para leer código público, empieza a comportarse menos como infraestructura abierta y más como una plataforma cerrada que prefiere usuarios identificados en todo momento.
La señal también choca con otros movimientos de la propia industria. Hace poco vimos a OpenAI intentar congraciarse con maintainers y comunidades con beneficios para proyectos open source, algo que analizamos en nuestro artículo sobre Codex para maintainers open source. GitHub, en cambio, está enviando la señal opuesta: si quieres confiabilidad, autentícate; si no, acepta la fricción.
Qué implicancias tiene para desarrolladores y para la web abierta
La consecuencia más inmediata es práctica. Mucha documentación en internet enlaza directo a archivos blob, tree o raw de GitHub. Si una persona cae ahí desde Google, Reddit, Hacker News o un blog técnico y el sitio empieza a responder con 429 tras pocos clics, la experiencia se rompe. No estás bloqueando a un bot sofisticado; estás espantando a la persona que quería entender tu proyecto.
- Menos descubrimiento casual: si revisar un repo público se vuelve incómodo, menos gente explora herramientas nuevas.
- Más dependencia del login: GitHub empuja a que incluso el consumo pasivo del código pase por identidad y sesión.
- Peor interoperabilidad web: enlaces públicos que antes eran estables ahora pueden volverse frágiles según IP, sesión o patrón de clics.
- Más presión para usar la API: técnicamente puede ser una salida, pero no reemplaza la experiencia real de hacer clic en un link público.
También hay una lectura más profunda. Durante años discutimos las licencias del open source como si la gran batalla fuera GPL versus MIT. Pero en 2026 la pelea también pasa por otra capa: quién controla la interfaz donde el mundo descubre, lee y comparte ese código. Esa tensión conecta muy bien con nuestro análisis sobre licencias open source y control de ecosistemas: el código puede seguir siendo abierto, pero la infraestructura alrededor puede cerrarse por diseño, por negocio o por defensa antiabuso.
¿Es una medida razonable o un síntoma de una web más hostil?
Las dos cosas pueden ser verdad al mismo tiempo. Sí, GitHub necesita protegerse de crawlers agresivos, extracción masiva de datos y automatización oportunista. Pero también es cierto que la solución actual parece poco fina. Si un visitante humano no autenticado activa límites severos tras unos pocos clics, el sistema está priorizando el control por sobre la usabilidad.
Y aquí aparece la ironía del momento. Parte de esta presión existe porque el boom de la IA disparó el scraping a una escala nueva. Es decir: el auge de los modelos que aprendieron leyendo repositorios públicos está haciendo más difícil leer repositorios públicos. No es solo un problema técnico; es una señal de cómo la fiebre por entrenar y monetizar modelos está deformando la infraestructura abierta que hizo posible esa misma fiebre.
GitHub todavía tiene margen para corregir el tiro. Podría ofrecer mensajes más claros, umbrales más razonables para browsing humano, o mecanismos de autenticación ligera que no conviertan cada visita en una obligación de iniciar sesión. Lo que no parece sostenible es fingir que el problema solo afecta a “usuarios sin autenticar” cuando, en la práctica, toca una conducta central de la web abierta: entrar a un enlace público y leer.
Por qué importa
Esto importa porque GitHub ya no es solo un hosting de código. Es una capa crítica de la internet técnica. Cuando navegar un repo público empieza a comportarse como un privilegio condicionado en vez de un acto básico de lectura, cambia algo más grande que una cuota por hora: cambia la forma en que circula el conocimiento técnico.
Si la web abierta se vuelve demasiado costosa de sostener frente al scraping industrial, veremos más plataformas cerrando el acceso anónimo, endureciendo límites y empujando a login obligatorio. GitHub no inventó esa tendencia, pero su tamaño la vuelve legitimadora. Y si eso se normaliza, el open source seguirá existiendo, sí, pero cada vez más dentro de jardines con torniquete.
Fuentes
- GitHub — meta-wearables-dat-android/CHANGELOG.md
- GitHub Changelog — Updated rate limits for unauthenticated requests
- GitHub Docs — Rate limits for the REST API
- GitHub Community — Error 429: Too Many Requests When Accessing Repository Files Without Login
- GitHub Community — Search in repository immediately throws "Too many requests" message
