96.636 estrellas, 152 vigilantes y 115,6 millones de descargas: qué demuestra de verdad el feed de versiones de Orca

Orca es una aplicación de escritorio que ejecuta varios agentes de programación en paralelo, cada uno en su propio worktree de git, y permite controlarlos desde el móvil. Tiene licencia MIT, respaldo de Y Combinator, y su repositorio (stablyai/orca) se creó el 17 de marzo de 2026. Al consultar los metadatos el 19 de octubre de 2026, esto es lo que devolvía:

Todas esas cifras son reales. Lo interesante es que no describen lo mismo, y dos de ellas —estrellas y descargas— se leen habitualmente como si lo hicieran. Esto es un intento de leer el repositorio como datos de instrumentación y no como un concurso de popularidad, y de decir sin rodeos en qué puntos los datos respaldan el marketing y en cuáles no.

La proporción de vigilantes no es un error: es el canal

152 vigilantes sobre 96.636 estrellas es un 0,157%. Medí cuatro repositorios maduros con el mismo método el mismo día, y se agrupan con una estrechez llamativa:

Orca se queda en torno a un cuarto de la referencia más baja. La lectura tentadora es «estrellas falsas». Los datos no lo sostienen, y la razón es mecánica: una estrella es un clic en un repositorio al que alguien te envió; un vigilante es una suscripción a un flujo de notificaciones que hay que querer. La distribución de Orca es un instalador firmado más un changelog dentro de la aplicación, más un Discord y seis README traducidos. Nada en ese embudo le pide al usuario seguir el tráfico de issues del repositorio — y ese tráfico, como muestran las secciones siguientes, no es algo que un usuario normal quiera en su bandeja de entrada.

Así que la proporción de vigilantes mide la forma del embudo, no la honestidad de las estrellas. Lo que sí dice es que el repositorio funciona como registro de compilación, no como foro comunitario. Si juzgas este proyecto leyendo su gestor de issues como leerías el de un proyecto más pequeño, lo malinterpretarás en ambas direcciones.

115.651.862 descargas, y por qué dividir entre 977 es la cuenta equivocada

El README lleva una insignia de descargas. El SVG que la sustenta muestra ahora 107m. Los números de GitHub son mayores y más precisos: recorrí las 977 versiones publicadas y sumé el download_count de cada binario — entre 21 y 22 por versión de escritorio, cubriendo macOS arm64/x64, Windows y varios formatos de Linux.

Total: 115.651.862 descargas en 977 publicaciones, del 21 de marzo al 17 de octubre de 2026.

El divisor ingenuo es el número de publicaciones, y da 118.374 descargas por versión. Esa cifra no significa nada, y la razón es lo más útil de toda esta auditoría. El desglose mensual:

Léase la primera y la última columna juntas. En abril el proyecto publicó 208 versiones en 30 días — casi siete al día — y cada una se descargó 211 veces. En septiembre publicó 24 versiones en 30 días y cada una se descargó 2,3 millones de veces. El volumen de publicaciones cayó cerca de un 88% de abril a septiembre, mientras las descargas por versión subieron cuatro órdenes de magnitud.

De ahí salen dos conclusiones, y apuntan en dirección contraria a las habituales:

1. La cifra de descargas es creíble. 2,3 millones de descargas de una sola compilación de septiembre no es el perfil de una operación de inflado de estrellas. Dividir 115,6 millones entre 977 da un número bajo solo porque 831 de esas publicaciones salieron entre abril y julio, antes de que nadie usara la aplicación.
2. El recuento de publicaciones es un artefacto histórico. «977 versiones en 210 días» promedia 4,65 al día, pero ese promedio describe un verano, no el presente. El ritmo actual es de aproximadamente una publicación diaria, que es lo que muestra el changelog público.

La distribución interna de las 977 lo explica desde otro ángulo. La versión mediana tiene 368 descargas; el percentil 90 llega a 64.455; las 20 publicaciones más descargadas concentran el 54,6% del total. 42 versiones (4,3%) pasaron del millón. La mitad inferior de la lista —488 compilaciones— suma el 0,04% de todas las descargas. Nada de eso es sospechoso: es el aspecto que tiene un contador cuando un proyecto empieza con cero usuarios y termina con millones, y las etiquetas se estampan a diario por el camino.

Una salvedad que no se puede resolver desde fuera: las descargas de binarios incluyen actualizaciones automáticas, trabajos de CI, réplicas y gente que instala, desinstala y reinstala. La cifra de septiembre acota la base instalada por abajo en unos 2,3 millones de dispositivos si cada dispositivo instala cada versión, y por arriba en mucho más si los dispositivos actualizan con menos frecuencia de la que el proyecto publica. No es un recuento de usuarios. Es el único dato de adopción que publica el proyecto que no es un gesto de un clic, lo que lo convierte en el más útil.

El changelog y el feed de versiones no coinciden en dos números

El README lo dice con sus propias palabras: «we ship daily, so this list is perpetually behind. The changelog is the real feature list» («publicamos a diario, así que esta lista va perpetuamente por detrás; el changelog es la lista real de funciones»). Es una declaración de intenciones inusualmente directa, y en general se cumple: entre el 11 de septiembre (1.4.200) y el 15 de octubre (1.4.226) el changelog tiene 19 entradas con fecha que cubren 25 publicaciones.

Pero las dos superficies no encajan en la parte superior. Las entradas más recientes del changelog son la 1.4.225 del 14 de octubre y la 1.4.226 del 15 de octubre. El feed de versiones no tiene ni publicación ni etiqueta para ninguna de las dos. Salta de la v1.4.224 (10 de octubre) a la v1.4.227 (16 de octubre) y luego a la v1.4.229 (17 de octubre), que lleva 22 binarios y, en el momento de escribir esto, 919.663 descargas.

Desde fuera no puedo saber si esas dos compilaciones se retiraron, si la numeración del changelog está desacoplada de la de las publicaciones, o si la 1.4.226 fue una compilación interna con nota pública. Ninguna fuente lo explica. Lo que sí puedo afirmar es que las dos secuencias de versiones que usarías para responder «¿cuál es la versión actual?» no coinciden, y que un equipo que fije versiones debería leer /releases y no el changelog de marketing. Solo la rama 1.4 acumula 568 de las 977 publicaciones.

Quién escribe realmente este código

15.007 commits son muchos para siete meses. La lista de colaboradores es donde se ve la forma del proyecto:

604 colaboradores, y cuatro cuentas concentran cuatro quintas partes del historial. No es raro en el repositorio de producto de una startup —es una empresa, no un proyecto de voluntarios—, pero significa que el número de colaboradores del panel lateral exagera cuánta gente podría revisar de verdad un cambio.

Los trailers de los commits responden a la siguiente pregunta: quién, o qué, está escribiendo. En los 100 commits más recientes, 13 llevan al menos un trailer de coautoría con IA, y esos 13 commits contienen 47 líneas de ese tipo: 43 nombran un modelo Claude (Claude, Claude Opus 5, Claude Opus 5.5, todos en noreply@anthropic.com) y 4 nombran Orca Worker <orca-worker@localhost>. Ampliando a los 300 commits más recientes: 30 commits (10%) llevan trailer de IA y los mensajes contienen 117 líneas así —112 nombran a Claude, 5 a Orca Worker. El número de líneas supera al de commits porque un commit aplastado (squash) agrupa varias sesiones de agente y cada sesión añade su propio trailer; uno de los de la muestra lleva diez.

Es un suelo, no un techo. El trailer es opcional y el 87% de los commits recientes no lleva ninguno. Pero encaja con las instrucciones del propio repositorio, escritas para agentes y no para personas. AGENTS.md son 13.806 bytes de política de ingeniería, y CLAUDE.md son 11 bytes: @AGENTS.md. El archivo gobierna la ruta de fusión con un lenguaje que solo tiene sentido si es software quien fusiona:

«Pending, failed, cancelled, or missing required checks block agent merges even when repository settings allow them. gh pr merge --auto is not proof that CI passed: GitHub may merge immediately when checks are optional. Never use --admin or disable protection to bypass a failed check.»

y

«An explicit user instruction to make an emergency exception overrides this default; otherwise fix the failure or wait. Use --match-head-commit to prevent merging a different commit after validation.»

Esta es la parte que enseñaría a quien descarta sin más el software construido por agentes. Un equipo que deja que un agente fusione su propio trabajo debería escribir exactamente esto: comprobar la identidad del flujo y no solo el nombre del trabajo, reverificar cuando cambia la cabeza de la rama, no usar nunca --admin, fijar el commit. AGENTS.md también recoge ese conocimiento de plataforma que normalmente se pierde en un wiki —la mutilación de argumentos de CommandLineToArgvW en Windows, MSYS reescribiendo /c, el suelo de glibc 2.31, wsl.exe expandiendo $name bajo --.

Lo que no dice es cuántas personas revisan una pull request. No hay ningún número mínimo de aprobaciones en todo el archivo. La página Enterprise afirma que «Every agent change lands in a worktree and a pull request, so it is reviewed the same way as human code» («cada cambio de un agente acaba en un worktree y una pull request, así que se revisa igual que el código humano»), lo cual describe el mecanismo, no un cuórum de revisores. Si la aprobación humana es tu criterio de adopción, tendrás que preguntarlo; el material público no lo responde.

Las 11.876 ramas son la otra pista. Un flujo de trabajo con un worktree por agente deja exactamente ese residuo.

La cola: 64 fusiones al día, doce días para cerrar

La API de búsqueda de GitHub da el desglose que el panel lateral esconde:

13.955 fusiones en 217 días son 64 fusiones al día, fines de semana incluidos. 2.532 issues abiertas en los últimos 30 días son 84 al día. Es un proyecto funcionando a un ritmo que ningún proceso humano de triaje puede seguir, y el repositorio no lo disimula: publica la cola.

Para quien decide si confiar, la medida honesta no es el tamaño de la cola sino cuánto tiempo pasa un elemento en ella. De una muestra de 100 issues cerradas recientemente, 41 eran issues y no pull requests; de esas, la mediana hasta el cierre fue de 287 horas —unos 12 días—, el percentil 90 de 1.327 horas (55 días), y solo 6 de 41 se cerraron en menos de 24 horas. Siete de las 41 las abrieron cuentas automatizadas. Una mediana de 12 días no es abandono, y tampoco es un servicio de soporte. Si tu adopción depende de que un fallo se reconozca rápido, ese es el número que debe gobernar tu decisión, no las 96.636 estrellas.

Hacker News no ofreció contrapeso: las consultas en Algolia por el nombre del proyecto, la frase del producto y la empresa no devolvieron ningún hilo por encima de un punto. Un proyecto de esta escala sin apenas discusión en HN significa que su tráfico no vino por los canales habituales de lanzamiento: una aplicación de escritorio que se propaga por una página de descargas, un Discord y el boca a boca, no por un hilo de comentarios.

Qué puedes verificar tú mismo y qué no

El repositorio es inusualmente generoso con las afirmaciones verificables, lo que facilita separar el marketing de la mecánica.

Verificable, con comandos que el proyecto documenta:

• pnpm tc, pnpm test, oxlint, pnpm run check:code-quality:changed: comprobación de tipos, pruebas y la puerta de líneas modificadas.
• ORCA_REAL_CLAUDE_CLI_TEST=1 pnpm test src/main/claude/claude-structured-real-cli.test.ts …: ejecuta las pruebas de sesión estructurada contra un inicio de sesión real de Claude. Es la prueba rara que demuestra la integración en vez de simularla.
• .github/workflows/pr.yml: el trabajo agregado PR checks passed (ID verify) que AGENTS.md exige antes de fusionar. Puedes leer si la puerta es real y cómo falla.
• /releases y /graphs/contributors: todas las cifras de este artículo.
• LICENSE: MIT, sin trampa de licencia dual.

Afirmaciones que no puedes verificar con material público:

• «Prompts and code go straight to the providers you configure. Orca does not inspect or store them». El cliente es abierto; un binario empaquetado no es el cliente que puedes leer, y el relé móvil bajo cloud/ es un servidor que no controlas.
• «AICPA SOC 2 Readiness». Esa frase reclama preparación, no una auditoría completada. No se referencia ningún informe Tipo I ni Tipo II en toda la página. Si un cuestionario de seguridad pide evidencias, «readiness» no es evidencia, y la página no finge que lo sea.
• Gobernanza empresarial —aplicación central de modelos aprobados, SSO, envío a SIEM, controles de retención— no está descrita. La página ofrece una conversación («Get in touch») y no hay página de precios: /pricing devuelve 404.
• Si alguna persona aprobó un commit fusionado concreto.

La telemetría es la parte mejor documentada del producto, y merece citarse porque es específica: los eventos se asocian a un identificador local aleatorio; sin cuenta, sin correo, sin IP, sin contenido de archivos, prompts, salida de terminal, nombres de repositorio, nombres de rama, rutas ni mensajes de commit. Detalla exactamente qué envía: ciclo de vida de la aplicación, eventos de creación de repositorio o espacio de trabajo (el método, nunca el repositorio), tipo de agente y origen del lanzamiento, categorías gruesas de error y alternancias de configuración en lista blanca; todo valores de enumeración fijos, cadenas de versión o el identificador local. Va a PostHog Cloud, región de EE. UU., y se puede desactivar con DO_NOT_TRACK=1, ORCA_TELEMETRY_DISABLED=1 o un interruptor en Ajustes. El único punto blando está dicho en voz alta en lugar de esconderse: «Retention: PostHog Cloud’s plan-level default per their pricing page. We do not set a custom retention window» («Retención: el valor por defecto del plan de PostHog Cloud según su página de precios; no fijamos una ventana de retención propia»). Si necesitas un periodo de retención contractual, esa frase es tu problema, y al menos la escribieron.

Qué sostienen los números

96.636 estrellas, 2,3 millones de descargas por compilación en septiembre, 604 colaboradores, licencia MIT y una suite de pruebas que puedes ejecutar: esas son las marcas de un producto real y muy rápido, y el repositorio publica lo suficiente para que un escéptico confirme casi todo sin fiarse del post de nadie, incluido este.

Las distorsiones van en dirección contraria a la acusación habitual. El contador de descargas no está inflado por bots; está rebajado por el divisor que la gente le aplica, porque 831 de las 977 publicaciones son anteriores a que existiera audiencia. Las estrellas no están compradas; simplemente son una señal peor que los vigilantes, que dicen que casi nadie sigue la producción diaria de este repositorio porque no lo necesita: ejecuta la aplicación.

Lo que un lector debería llevarse es más estrecho y más útil. Un repositorio que fusiona 64 pull requests al día, cierra issues en doce días, publica bajo reglas de fusión escritas por y para agentes y deja 11.876 ramas detrás es el escape de una organización de ingeniería, publicado en abierto. Léelo como evidencia de velocidad y de disciplina de proceso —la puerta de fusión de AGENTS.md es buena práctica de verdad— y no como evidencia de cómo se comportará en tu máquina, en tu red o bajo tu régimen de cumplimiento. Para eso necesitas las dos cosas que el repositorio no puede darte: una revisión de seguridad que hagas tú, y una conversación con el proveedor sobre las preguntas que su página Enterprise deja abiertas.

Preguntas frecuentes

¿Orca es código abierto? Sí: MIT, el cliente de escritorio completo y el relé de emparejamiento móvil bajo cloud/. También es un producto comercial, con respaldo de Y Combinator, una oferta Enterprise y ninguna lista de precios pública.

¿Por qué tiene 96.636 estrellas y solo 152 vigilantes? Porque las estrellas llegan desde una página de descargas y los vigilantes exigen suscribirse a un flujo de notificaciones de un repositorio que produce 84 elementos nuevos al día. La proporción es del 0,157%, frente al 0,555–0,641% de cuatro repositorios maduros medidos el mismo día.

¿Son reales los 115,6 millones de descargas? Son cifras reales de la API de GitHub, sumadas en 977 publicaciones. No son 115,6 millones de usuarios. En septiembre cada versión promedió 2,3 millones de descargas; la lectura honesta es una base instalada de varios millones, con las actualizaciones automáticas contadas una vez por ciclo.

¿El código lo escribe una IA? En parte. De los 300 commits más recientes, 30 (10%) llevan trailer de coautoría con IA: 112 líneas nombran a Claude y 5 al Orca Worker propio del proyecto. El trailer es opcional, así que es un suelo. Cuatro cuentas concentran el 79,5% de todos los commits.

¿Envía mi código o mis prompts a algún sitio? Según su documentación de telemetría: no envía contenido de archivos, prompts, salida de agentes, nombres de repositorio, nombres de rama, rutas ni mensajes de commit; los eventos de uso se asocian a un identificador local aleatorio y van a PostHog Cloud en EE. UU. Puedes desactivarlo con DO_NOT_TRACK=1 o ORCA_TELEMETRY_DISABLED=1. La ruta de prompts y código va al proveedor de modelos que configures, algo que no puedes verificar con material público, solo auditar.

¿Está certificado SOC 2? La página Enterprise dice «AICPA SOC 2 Readiness». La preparación no es una auditoría completada y no se referencia ningún informe Tipo I o Tipo II.

¿Conviene fijar una versión? Sí, y lee /releases en lugar del changelog: solo la rama 1.4 acumula 568 publicaciones, y las dos entradas más recientes del changelog (1.4.225, 1.4.226) no tienen publicación ni etiqueta correspondiente.