REA sumó 255.126 estrellas en ocho días: vuelvo a medir la curva más rápida de GitHub, donde los forks crecieron 43x frente al 18x de las estrellas y el 76% del historial git tiene 16 días

Hace ocho días este sitio publicó una auditoría medida de REA, el servidor MCP que permite a un agente de código hacer ingeniería inversa de cualquier cosa, desde una aplicación Electron hasta un binario nativo. Aquella medición dejó el repositorio en 15.095 estrellas, 44 watchers y 1.569 forks, y tasó un análisis real en 209.619 tokens para ocho archivos.

El 2026-10-16, a las 00:51 UTC, el mismo endpoint de la API devolvió 270.221 estrellas, 915 watchers y 67.778 forks.

Eso son +255.126 estrellas, +871 watchers y +66.209 forks en ocho días. Ningún otro repositorio que haya medido se mueve así, de modo que este artículo hace lo único que vale la pena hacer con un número semejante: medir la curva contra una línea base y separar lo que es genuinamente anómalo de lo que es simplemente el aspecto de un repositorio de la era de los agentes en 2026.

Dos mediciones del mismo repositorio, con ocho días de diferencia

Ambas filas son lecturas de la API de morluto/rea hechas por este sitio, no cifras copiadas de un panel.

Por día, en esa ventana: 31.891 estrellas, 8.276 forks y 109 watchers.

Los números se corroboran de forma independiente. En el hilo de Hacker News sobre REA (806 puntos, 338 comentarios), un comentarista siguió el repositorio en vivo el 2026-10-10 y escribió: “Oct 5 ~4.2k, Oct 7 ~10.3k, Oct 8 ~17–18k, Oct 10 54.6k en vivo… Aún más raro es el caso de los forks: 438 → 10.376. Es una aceleración de forks inusualmente alta.” Nuestra propia medición de 15.095 estrellas cae justo entre las lecturas del 7 y del 8 de octubre de ese comentario. Dos observadores, dos métodos, una sola curva.

¿Cuánto es 31.891 estrellas al día?

Aquí está la misma métrica —media histórica de estrellas por día— para los repositorios más grandes de GitHub, calculada con la API el mismo día.

Lean los dos últimos bloques juntos. React acumuló 251.069 estrellas en 13,4 años; REA acumuló 255.126 en ocho días, unas 623 veces la media histórica de React. Linux promedia 45,7 estrellas al día durante 15 años.

La comparación interesante no es con los clásicos, sino con sus pares. deepseek-ai/deepseek-harness, el repositorio de 2026 más rápido que medí, promedia 4.039 estrellas al día en sus 62 días de vida, y la ventana de ocho días de REA sigue siendo 7,9 veces más rápida que eso, y 21,7 veces más rápida que la media de 184 días del propio REA (1.468 al día).

La curva no describe “un proyecto nuevo y popular”. Describe una discontinuidad dentro de la historia del propio proyecto.

El ratio de watchers no es lo anómalo; el de forks sí

La lectura obvia de 270.221 estrellas frente a 915 watchers es “0,34%: tienen que ser falsas”. Para comprobarlo descargué los 30 repositorios con más de 40.000 estrellas y calculé ambos ratios en cada uno.

El derrumbe del ratio de watchers es un efecto de cohorte, no un efecto de REA. Todos los repositorios grandes de la era de los agentes en el top 30 se sitúan entre el 0,37% y el 0,58%: obra/superpowers 0,37%, NousResearch/hermes-agent 0,38%, anomalyco/opencode 0,38%, deepseek-ai/deepseek-harness 0,43%, mattpocock/skills 0,52%. El 0,34% de REA está en el extremo bajo de esa banda, no fuera de categoría. Si buscan el verdadero valor atípico, es DigitalPlatDev/FreeDomain con 0,14% y 204.368 estrellas.

El ratio de forks es otra cosa. REA está en 25,1%, y dentro de los 30 repositorios más grandes solo tres son más altos: tensorflow (39,6%), n8n (29,5%) y el kernel de Linux (27,0%). Esos tres combinan su alto ratio de forks con ratios de watchers del 3,75%, 0,57% y 3,37%. REA es el único repositorio del top 30 con un ratio de forks superior al 25% y un ratio de watchers inferior al 0,5%. El fork se supone que es intención: alguien piensa trabajar sobre el código. 67.778 forks contra 915 watchers es una combinación que la cima de GitHub no produce en ningún otro caso.

Y los forks crecieron más rápido que las estrellas: 43,2x frente a 17,9x en los mismos ocho días.

De dónde viene realmente el tráfico

Las estrellas y los forks son métricas de vanidad en el sentido de que son clics baratos. Las descargas son más difíciles de falsificar a escala y, además, son lo que un usuario necesita para ejecutar la herramienta. npm las publica a diario, así que muestran la forma de la curva de adopción.

Es un aumento de 218x en la tasa diaria, y el 97,6% de las descargas de todo el mes ocurrió en la última semana. La serie diaria lo dice mejor:

npm cuenta descargas de tarballs, y las descargas vienen de CI, réplicas y compilaciones de contenedores además de personas, así que 103.109 no son 103.109 usuarios. Pero la forma —plana en dos dígitos durante un mes y luego cinco duplicaciones consecutivas— es un evento de lanzamiento, y arranca dos días después del estallido de estrellas. Nótese que el número siguió subiendo dos días después de que el hilo de Hacker News tocara techo.

La lista de contribuidores contiene una granja de pull requests

El repositorio tiene 230 contribuidores y 3.391 commits. Las cuatro cuentas principales suman 2.848 de esos commits (84,0%), por debajo del 95,6% que medimos el 8 de octubre: la base de commits sí se amplió de verdad.

Y está el cuarto nombre de esa lista. rudycelekli tiene 91 commits en REA y 4.498 pull requests en GitHub, de los cuales 2.278 se fusionaron y 814 se cerraron sin fusionar. 142 son pull requests a morluto/rea. Solo el 2026-10-16 esa cuenta creó 39 pull requests. La muestra del mismo día incluye mvschwarz/openrig (#1337, #1338, #1339), openclaw/Peekaboo (#1085), proffesor-for-testing/agentic-qe, Yeachan-Heo/oh-my-claudecode (#4403) y HKUDS/Vibe-Trading (#1870): proyectos sin relación entre sí, abiertos en las mismas horas.

Ese patrón coincide con lo que describió otro comentarista del mismo hilo: “cuando un repositorio entra en la lista de tendencias de GitHub lo invade algún tipo de contribuidor y la mayoría de esos perfiles empezaron a contribuir a repositorios aleatorios hacia marzo/abril. Es un patrón, pero no sé qué sacar de él.” Otro comentarista fue más directo sobre el proyecto completo: “Huele a bots, algunos comentarios de aquí también parecen artificiales.”

Revisé los forks de la misma forma. Los 100 forks más recientes se crearon todos el 2026-10-16. De una muestra de 28 propietarios: 16 tienen cero seguidores, 4 tienen dos repositorios públicos o menos, y 7 cuentas se crearon en 2025 o después, entre ellas 258036-KK, una cuenta creada el 2026-10-16 cuyo único repositorio es el fork que acaba de hacer de REA. El commit de cabecera de cada fork muestreado es idéntico al de upstream 808339f0, es decir, nadie ha publicado nada en ellos.

Eso es compatible con una granja de forks y también con un lanzamiento viral: los usuarios reales hacen forks y nunca los tocan. Lo que los datos no sostienen es la historia sencilla de que 270.221 estrellas representen a 270.221 personas con intención de usar una herramienta de ingeniería inversa. El contador de watchers, la única señal que exige un segundo clic deliberado, dice 915.

El 76% del historial git tiene 16 días

El último número raro no tiene que ver con GitHub, sino con la cronología del propio repositorio.

El 75,9% de todos los commits de la historia del proyecto llegó en una ventana de 16 días. El repositorio también es un renombrado: el primer commit es un MCP para el desensamblador Hopper llamado betterBinaryMCP, inactivo durante dos meses y medio, reescrito desde julio como un MCP general de ingeniería inversa. El ritmo de publicación actual acompaña el estallido: 36 releases y 36 tags, con rea-agents pasando de 6.0.0 a 6.5.0 en seis días.

Las dos lecturas son defendibles. Un bucle de desarrollo con agentes puede producir 161 commits al día, y el andamiaje que lo rodea es real: 719.095 líneas de TypeScript, de las cuales 387.222 (53,9%) viven en archivos de test — 1.396 archivos de prueba sobre 2.985 archivos .ts. La otra lectura es que un repositorio que reescribe el 76% de su historial en dos semanas mientras suma un cuarto de millón de estrellas se construye y se promociona a un ritmo que deja poco espacio para que alguien verifique el resultado.

Lo que sí es verificable y bueno

Si se quitan los números de crecimiento, REA sigue siendo una de las herramientas de agente más cuidadosas que he medido.

• Nada se ejecuta durante la instalación. El tarball publicado de rea-agents@6.5.0 trae 39 dependencias de ejecución y ningún script install ni postinstall, solo prepack/prepare, que no se ejecutan para quien consume el paquete. Lanzar npx no ejecuta código del repositorio al instalar.
• No hay telemetría en el código fuente. Buscar SDK de analítica (posthog, sentry, mixpanel, amplitude) en las 71 MB del checkout no devuelve nada, y los únicos hosts de red que aparecen en src/ fuera de fixtures son github.com y www.hopperapp.com. Todo lo demás son fixtures *.example.test.
• La superficie de instalación es honesta sobre lo que cambia. El setup escribe un registro MCP más instrucciones en la configuración de tu agente: .claude/skills/reverse-engineer-anything/SKILL.md, .codex/config.toml, .cursor/mcp.json, .agents/skills/…, con copias de seguridad de lo existente. Estás instalando instrucciones que tu agente va a seguir, no solo un binario, y eso conviene entenderlo antes de aprobar el plan.
• Los requisitos están declarados y son estrictos. Node.js ^22.19.0 || ^24.11.0 || >=26.0.0 (el repo fija .nvmrc en 24.18.0), la inspección de SQLite exige 24.15+ y el análisis nativo profundo requiere tu propia licencia de Hopper, Ghidra o IDA. El proyecto es explícito: no concede “ninguna licencia, clave ni derecho de activación” de herramientas, así que la frase “libre y open source” llega con un desensamblador de pago acoplado para el caso de uso principal.
• El punto débil lo señalan los usuarios, no yo. La ruta de Android sigue pasando por JADX headless, y un investigador de seguridad del hilo de HN explicó que “jadx tarda decenas de minutos en preprocesar un APK”, lo que en su opinión hace inviable el triaje masivo de APKs; escribió una alternativa más rápida.

Cómo leer un repositorio como este

Cinco comprobaciones, cada una a un coste de una llamada a la API:

1. Watchers, no estrellas. Divide subscribers_count entre stargazers_count y compáralo con la cohorte de su época, no con 2015. Por encima del 0,5% es normal para un repo de agente de 2026; por debajo del 0,35% merece una segunda mirada.
2. Forks entre estrellas, emparejado con watchers. Cualquiera de los dos ratios por separado es ruido. Un ratio de forks por encima del 25% junto a un ratio de watchers por debajo del 0,5% es la combinación que los 30 repositorios más grandes no producen en ningún otro caso.
3. La forma de las descargas, no el total. Una línea plana que se duplica cinco días seguidos es un lanzamiento. Una curva que crece durante un año es adopción.
4. La concentración de commits por mes. Si la mayor parte del historial tiene semanas de vida, estás leyendo una reescritura, no una trayectoria.
5. Quién está en la lista de contribuidores. Una cuenta con miles de pull requests en repositorios sin relación te dice cómo se está inflando el gráfico de contribuciones, sea cual sea la calidad del repositorio.

Ninguna de estas comprobaciones mide si el software funciona. Eso exige instalarlo y ejecutarlo, que es lo que hizo la auditoría del 8 de octubre, y su conclusión no ha cambiado: el modelo de evidencias es bueno y la salida está tarifada para una máquina, no para un modelo.

Preguntas frecuentes

¿De verdad REA ganó 255.126 estrellas en ocho días? Sí, según dos lecturas de la API del mismo repositorio hechas por este sitio: 15.095 estrellas el 2026-10-08 y 270.221 el 2026-10-16 a las 00:51 UTC. La trayectoria se observó de forma independiente en el hilo de Hacker News el 2026-10-10.

¿El bajo ratio de watchers demuestra que las estrellas se compraron? No. El 0,34% está cerca de la mediana de todos los repositorios grandes creados desde 2025 (0,40–0,43%), así que demuestra que la cohorte más reciente de GitHub atrae muy pocos watchers. La anomalía es el ratio de forks, 25,1%: la única cifra del top 30 que combina un ratio alto de forks con un ratio de watchers inferior al 0,5%.

¿Qué dicen los números de npm? Que alrededor del 2026-10-08 ocurrió algo real. Las descargas pasaron de 0–56 al día durante un mes a 103.109 el 2026-10-12: un salto de 218x en la tasa diaria, con el 97,6% de las descargas del mes concentradas en la última semana.

¿El proyecto se mantiene de verdad? Sí, y mucho. 230 contribuidores, 3.391 commits, 36 releases, y la cuota de commits de las cuatro cuentas principales bajó del 95,6% al 84,0% en ocho días. La advertencia es que el 75,9% del historial de commits tiene 16 días.

¿Debería instalarlo con npx rea-agents setup? Es seguro en el sentido concreto de que el paquete no tiene scripts de instalación ni telemetría. No está exento de consecuencias: el setup escribe un registro MCP y un archivo de instrucciones SKILL.md en la configuración de tu agente, y los motores de análisis subyacentes (Hopper, IDA) son productos comerciales con licencia aparte.

¿El repositorio que crece más rápido es el mejor para usar? No necesariamente, y en este caso las dos preguntas son independientes. El valor de la herramienta está en su modelo de evidencias y en su cobertura de bridges; su número de estrellas dice con qué rapidez se propaga un lanzamiento y nada sobre si ocho archivos deberían costar 209.619 tokens.

Lo que conviene recordar

El número interesante de esta historia no es 270.221. Es 915: las personas que pidieron que se les avisara de lo próximo del proyecto, de un cuarto de millón que hizo clic en una estrella. Medido contra su propia época, REA no es un valor atípico en ese ratio; es atípico en cuántos de los que llegaron también hicieron fork del repositorio (67.778) y en la velocidad con la que se puede reescribir todo el historial de un proyecto (el 76% de 3.391 commits en 16 días).

A la herramienta hay que evaluarla por sus propios méritos, y este sitio ya lo hizo una vez. Lo que demuestran los ocho días intermedios es otra lección: en el GitHub de 2026, un buen repositorio y un repositorio que crece rápido son dos hechos distintos, y el segundo ya no dice nada sobre el primero.