ThinkRail, 5.047 estrellas: JetBrains montó su IDE de agentes sobre Monaco y sobre un agente de 118.537 estrellas, y terminó parcheando el agente

ThinkRail es un IDE de escritorio y de navegador para agentes de programación con IA. Lo publica JetBrains bajo su insignia de incubadora, con licencia Apache-2.0, y apareció en las tendencias de GitHub el 28 y 29 de octubre de 2026. Hace lo que ya hacen todos los IDE de agentes —crear un worktree de git por tarea, abrir un chat junto al diff, mantener un plan de pasos— y hace algunas cosas que los demás no: guarda la intención del proyecto en un grafo de archivos SPEC.md que el propio agente puede buscar y reescribir.

Lo que hace que valga la pena leer el repositorio no es la lista de funciones, sino la franqueza con la que documenta qué tomó prestado y cuánto le cuesta ese préstamo. Tres citas resumen el asunto:

• Del documento de producto: «pi es el único motor, ejecutado en proceso — sin un segundo runtime (nada de claude-agent-sdk)».
• De la guía para agentes que contribuyen: «Los fallos fatales del proveedor o del agente pueden tumbar el host; esa falta de aislamiento ante crashes está aceptada».
• De las decisiones de arquitectura: «pi publica versiones que rompen la compatibilidad a diario, así que un rango flotante es un cable en tensión».

Un fabricante de IDE que lleva años vendiendo uno de los motores de edición más maduros del sector publicó un IDE de agentes sobre Monaco —el editor de VS Code— y sobre pi, un agente TypeScript de terceros con 118.537 estrellas en GitHub. Después escribió un registro de 19,5 KB con todos los parches y espejos de código que necesita para que ese arreglo siga funcionando. Ese registro es el documento más interesante del repositorio, y casi nadie lo lee.

Las cifras, antes que los argumentos

Datos leídos de la API de GitHub y del repositorio clonado el 29 de octubre de 2026, entre las 00:45 y las 01:10 UTC.

Dos filas merecen una frase cada una. Los watchers son la cifra que las estrellas no pueden falsear: una estrella es un marcador, un watcher es «avísame cuando esto cambie». Doce personas pidieron que se les avisara. Y el primer commit está fechado dieciséis días antes de que el repositorio existiera, con el mensaje «initial specs»: se desarrolló dentro de JetBrains y se publicó después, lo cual encaja con un proyecto de incubadora y no con un lanzamiento.

Dos motores prestados y un host fino

La arquitectura son tres anillos: un host HTTP+WebSocket de Bun (packages/server), un protocolo tipado (packages/contracts) y una interfaz en React 19 (apps/web) que se publica por separado y puede hablar con cualquier host. El editor es Monaco, el motor de VS Code. El envoltorio de escritorio es Electrobun. El agente es pi.

La especificación reparte el trabajo sin ambigüedad: pi es dueño del registro de modelos, del prompt de sistema, de las skills, las extensiones, la compactación del contexto, la contabilidad de coste y el estado de sesión. De ThinkRail son el espacio de trabajo, el editor, el cable y nada más. Incluso hay una regla contra la trampa obvia —«influir alimentando, nunca ensamblando»—: una función solo puede moldear al agente entregándole contexto, archivos y skills, jamás construyendo prompts a sus espaldas.

Esa disciplina es admirable y también es un límite duro. La sección de no objetivos nombra exactamente dos cosas excluidas por decisión: un segundo runtime de agente, y cualquier tipo de cuenta o pantalla de inicio de sesión. Eso significa que la respuesta a «¿puedo usar Claude Code dentro de este IDE?» no es «más adelante», es «no». Un contribuidor del repositorio, CommanderTvis, lo bifurcó para alojar Claude Code; la bifurcación aparece en Hacker News como «Show HN: bifurqué el nuevo IDE de agentes de JetBrains para alojar Claude Code», y la misma cuenta portó luego ThinkRail de su webview a Avalonia con Ghostty. Cuando gente del propio proyecto lo bifurca para cambiar el motor, la regla de «pi es el único motor» está haciendo un trabajo visible.

La escala del motor es la parte incómoda de la comparación. pi (earendil-works/pi, licencia MIT, antes publicado bajo el espacio @mariozechner) tiene 118.537 estrellas y 15.193 forks; @earendil-works/pi-coding-agent registró 17.004.039 descargas npm el mes pasado, entre Gemini CLI (1,45 M), opencode (11,9 M) y Claude Code (44,6 M). ThinkRail tiene 5.047 estrellas. El host es 23 veces más pequeño que el motor que aloja, y el motor no es de JetBrains.

La factura del préstamo: trece costuras y un parche al compilado

ThinkRail fija cada dependencia a una versión exacta, y lo hace cumplir con scripts/check-catalog.ts en el pre-commit y en CI: el script rechaza rangos, desviaciones del catálogo y cualquier grafo de lockfile que resuelva React fuera de su única entrada. El motivo declarado es la tercera cita del principio: el motor se mueve a diario, así que un rango es un cable en tensión.

Lo que eso cuesta está en pi-compatibility.md, un registro de cada punto donde el host compensa una API que falta en pi, un defecto de pi o una limitación de empaquetado. Cada entrada trae su criterio de retirada: qué cambio en el proyecto original permitiría borrar el parche. Bajo «Other pi-sensitive host seams» hay 13 entradas, más cinco áreas solo para MCP.

La primera fila hay que leerla dos veces. ThinkRail no se limita a llamar al SDK de otra forma: publica patches/@earendil-works%2Fpi-ai@1.4.0.patch contra dist/api/anthropic-messages.js, es decir, contra el código compilado del parser de streaming de Anthropic del motor. Sin parche, «dos flujos fallan con el error no reintentable “Could not parse Anthropic SSE event”: un flujo CRLF válido cuyo \r\n se parte entre paquetes de red, y un flujo cortado a mitad de evento». Con parche, el primero funciona y el segundo termina en un error de truncamiento reintentable. La incidencia original es earendil-works/pi#10390, todavía abierta en el momento de esta auditoría.

Hay una segunda frase en el mismo documento que importa más al usuario que todo lo anterior: el catálogo de modelos incluido pasó de 1.554 a 1.599 pares proveedor/modelo, con 71 eliminados y 116 añadidos —y «el host sigue sin mostrar el modelFallbackMessage de pi. Esta actualización no añade ninguna interfaz de reserva ni de aviso». Entre los pares eliminados está openai-codex/gpt-5.5. Así que cuando reanudas una conversación cuyo modelo grabado desapareció del paquete, el host elige otro según reglas documentadas en otro sitio y no muestra nada. El remedio que propone su propia especificación es una nota de versión pidiendo al usuario que revise a mano su modelo por defecto y el de las conversaciones restauradas.

El aislamiento es una rama de git, no un sandbox

La crítica más repetida en Hacker News fue que ejecutar agentes fuera de contenedores es temerario. Leyendo las especificaciones, no es un descuido: es el producto.

Aquí aislar significa un git worktree por espacio de trabajo, con su propia rama y su propio directorio bajo ~/.thinkrail/worktrees, de modo que una mala ejecución del agente se queda en una rama hasta que la fusiones. Eso protege tu trabajo sin confirmar, tu rama principal y tu capacidad de revisar. No protege tus claves SSH, tu configuración de ~/.pi/agent, tus credenciales de nube ni nada que el proceso pueda alcanzar, porque el agente corre en el mismo proceso que el IDE y con los privilegios de tu usuario. pi se lanza en proceso, no como subproceso, y la línea de AGENTS.md citada al principio acepta que un fallo fatal se lleve el host por delante.

Lo que sí añade ThinkRail es una puerta de confianza, y está mejor pensada que en la mayoría: las skill aliases que un repositorio clonado trae confirmadas, su configuración .pi/, sus extensiones, sus prompts, sus definiciones de subagente y sus servidores MCP solo se cargan tras una autorización por proyecto, y un servidor MCP definido por el repositorio necesita además una aprobación por entrada que caduca cuando la entrada cambia. Es una defensa real contra la inyección de prompts desde un repo que acabas de clonar. No es una defensa contra un agente que decide hacer curl a algo.

La autenticación es la red, y la bandera que la mueve

La CLI escucha por defecto en localhost —DEFAULT_HOST = "localhost" en apps/cli/src/args.ts—, así que una instalación sin tocar nada solo acepta conexiones locales. Buen valor por defecto.

Después, la decisión de arquitectura dice: «La autenticación es externa. Las ACL de Tailscale y la identidad del dispositivo son la autenticación; la aplicación lleva un campo owner, no una pantalla de acceso». No hay token, ni contraseña, ni cookie de sesión en el upgrade del WebSocket. El host expone /ws, /health, una ruta de archivos y otra de blobs, y todo su modelo de protección consiste en que solo tus dispositivos puedan llegar al puerto.

Eso convierte a --host en la bandera más consecuente del programa. Su texto de ayuda completo es --host <h> Bind host (default localhost). No avisa de que enlazar 0.0.0.0 entrega un agente sin autenticación capaz de ejecutar shell a cualquier dispositivo de tu red local. El README no menciona --host en ningún momento; solo aparece en el --help de la CLI. Si sigues el camino documentado —aplicación de escritorio, o thinkrail en loopback— estás bien. Si te inventas el acceso desde el teléfono, dependes de una ACL de Tailscale que ninguna instrucción de instalación te dijo que crearas.

La ruta de instalación que no existe en ninguna versión estable

El apartado de escritorio del README dice: «macOS 14+ (Apple Silicon o Intel) — abre el DMG de tu arquitectura: thinkrail-desktop-darwin-arm64.dmg o thinkrail-desktop-darwin-x64.dmg».

En las 28 versiones estables publicadas, desde v0.0.1 el 8 de julio hasta v0.2.0 el 18 de octubre, thinkrail-desktop-darwin-x64.dmg no se ha adjuntado nunca. Cada estable desde v0.1.0 trae 17 archivos: el DMG arm64, un zip de Windows, tarballs de Linux, tres binarios de CLI, SHA256SUMS y JSON del actualizador. El DMG para Intel aparece por primera vez en v0.3.0-nightly.9, el 28 de octubre, después de al menos doce versiones seguidas sin él. Un usuario de Mac Intel que siga el README no tiene archivo que descargar en el canal estable.

El resto de la matriz de plataformas es honesto consigo mismo, y por eso llama la atención la ausencia: la CLI y el instalador de Windows están firmados, la CLI de macOS está «firmada pero aún no notarizada» y «los artefactos de Linux no están firmados». Las compilaciones de escritorio necesitan glibc 2.38+ con GTK 3, WebKitGTK 4.1, Ayatana AppIndicator 3 y librsvg 2: Ubuntu 24.04 o superior. Y aun así el botón principal de la web es «Download for Linux», apuntando justo a la plataforma cuyos artefactos no están firmados y cuyo mínimo es dos LTS por delante de la distribución más común.

Los tamaños también dicen algo: los binarios de CLI van de 121 a 145 MB (thinkrail-linux-x64 son 140 MB), mientras que el paquete de escritorio es un tarball de 45 MB. Para un proyecto cuyo subtítulo es «ligero», publicar un binario único de 140 MB es una decisión, no un accidente: es lo que cuesta un runtime de Bun autocontenido.

Faltan dos archivos que suelen existir: no hay SECURITY.md —así que no hay canal declarado para reportar vulnerabilidades— ni CHANGELOG.md —así que las notas de las 121 versiones en GitHub son el único historial de cambios. El código de conducta remite a la política comunitaria de JetBrains en lugar de a una propia.

Lo que sí está bien construido

Sería deshonesto terminar la auditoría ahí, porque buena parte de este repositorio está por encima de la media de los proyectos que llegan a tendencias.

• Pruebas, no corazonadas. 470 archivos de prueba unitaria y 142 especificaciones end-to-end, con una regla de reparto documentada (la mitad de las CPU, con tope de ocho) y puertas separadas para los artefactos binarios y de escritorio. La especificación exige la suite completa de navegador antes de entregar, no en cada commit.
• Especificaciones que se ganan el sitio. 106 archivos SPEC.md con 2,1 MB en total, uno por módulo y submódulo, cada uno declarando responsabilidad, superficie pública, dependencias permitidas y accesos prohibidos. Te guste o no la prosa, las reglas de frontera se hacen cumplir: bun run check:boundaries y check:seams son puertas de commit.
• Versiones exactas con verificador. Ni ^, ni ~, ni .x. check:deps rompe la compilación ante un rango o una desviación del catálogo. Más disciplina de la que logra la mayoría de los monorepos.
• Un instalador de verdad. install.sh descarga SHA256SUMS, extrae la entrada del archivo exacto y verifica con sha256sum o shasum -a 256, fallando ruidosamente si no existe ninguno de los dos. Las sumas están publicadas en la página de versiones.
• Puertas de confianza para repositorios clonados. Explicadas arriba; es la mitigación que de verdad importa en un modelo de aislamiento por worktree.
• Analítica con lista blanca, no lista negra. Los informes de error se clasifican por tipo, código, origen, ámbito, método de petición y marcos de pila que pertenecen solo a ThinkRail; el texto del mensaje queda excluido por una lista blanca en el código, no por una promesa en prosa.

Ese último punto es donde la lectura honesta se pone interesante, porque el nombre de la bandera no coincide con el comportamiento.

--no-analytics no apaga la analítica

El README dice que los informes de error siempre se envían, lo cual es una franqueza poco habitual. La especificación de analítica dice algo más afilado: el seguimiento de errores de PostHog queda «sin efecto por analyticsEnabled, --no-analytics o THINKRAIL_NO_ANALYTICS», y más adelante, «--no-analytics / THINKRAIL_NO_ANALYTICS suprimen solo los eventos adicionales sin cambiar el consentimiento».

O sea que la bandera apaga el paquete opcional y deja corriendo los eventos básicos y los informes de error, ligados a un identificador de instalación aleatorio. Ejecutar thinkrail --no-analytics no deja la aplicación callada: la deja menos habladora. Si eso es engañoso o solo un mal nombre depende de cuánta confianza deposites en quien lee una línea de --help, y la línea de ayuda dice únicamente «turns additional sharing off for that run», que es exactamente cierto y suena a otra cosa.

El mecanismo de atribución de marketing es la parte que casi nadie verá. Con el uso adicional activado, una compilación empaquetada puede abrir el blog de ThinkRail una vez en tu navegador para vincular esa instalación con la visita web que te trajo hasta aquí —palabras del README—. El código es un pequeño intercambio tipo PKCE: un verificador de 32 bytes, un desafío SHA-256 enviado a https://thinkrail.ai, hasta 54 sondeos cada 10 segundos dentro de un plazo de 9 minutos y un canje final. La atribución caduca a los 30 días del último toque. Está divulgado, es opcional, y es una aplicación de escritorio llamando a casa para reclamar una atribución de marketing sobre tu propia descarga: justo el tipo de cosa que hoy es normal y que en 2019 habría sido un escándalo.

Cómo lo leyó la comunidad

Dos hilos de Hacker News corrieron con un día de diferencia: el 24 de octubre (59 puntos, 84 comentarios) y el 25 de octubre (242 puntos, 174 comentarios). Leídos los 174 comentarios, la discusión más ruidosa no fue sobre arquitectura.

Fue sobre si el README lo había escrito un modelo. Un comentarista afirmó que era «100 % IA según Pangram» y se negó a tomarse el repositorio en serio; las respuestas se dividieron entre «si no te molestaste en escribir un readme, ¿qué más no te habrás molestado en hacer?» y «no se puede detectar la IA, importa si el readme es bueno». Otro fue directo contra las especificaciones: «¿Cómo se supone que este “vómito de LLM” son “especificaciones que son la verdad de referencia”?».

Las objeciones de ingeniería eran más afiladas y recibieron menos atención:

• «Que JetBrains use VS Code es realmente triste» y «ni siquiera usar su propio motor central es francamente sombrío». La respuesta está en el repositorio —pi está en TypeScript y corre en proceso, así que un host en React con Monaco es la forma barata de envolverlo— pero «la forma barata de envolverlo» no es una réplica que nadie quisiera decir en voz alta.
• «Ejecutar agentes fuera de contenedores me parece una locura». Confirmado por las especificaciones; ver arriba.
• «Por cierto, ¿qué es “InnovationHub”? Se menciona pero no encuentro un enlace ni una explicación decente». Aquí hay un vacío real: la insignia del README dice «JetBrains incubator project» y enlaza a una página genérica de JetBrains en GitHub; la web dice «JetBrains InnovationHub»; nada público explica a qué se compromete ninguno de los dos programas. Compárese con la historia de Fleet en el mismo hilo —años de desarrollo, alfa pública, cierre, y al parecer un renacimiento como Air—. Una insignia de incubadora es una coartada, y los lectores la reconocieron como tal.

El comentario más útil para quien evalúe el producto fue el menos dramático: «¿por qué querría usar Monaco? Si estoy en el ecosistema JetBrains, ¿no es porque prefiero sus IDE a VS Code?». En el repositorio no hay respuesta, porque la respuesta honesta es que el editor es justo la parte que no construyeron.

Qué conviene verificar por tu cuenta antes de adoptarlo

La documentación no resuelve estas cosas; solo tu propio clon puede hacerlo.

1. Comprueba que existe el archivo que necesitas. Abre la última versión estable y confirma que está adjunto el archivo de tu plataforma. El 29 de octubre, el DMG para Mac Intel que pide el README solo existía en una nightly.
2. Decide la frontera de aislamiento antes de la primera ejecución. Úsalo en una máquina donde perder ~/.ssh, ~/.pi/agent y tus credenciales de nube sea sobrevivible, o mételo tú mismo en un contenedor. La herramienta no lo hará por ti.
3. Nunca enlaces más allá de loopback sin una ACL de red. Si usas --host 0.0.0.0, pon Tailscale o un cortafuegos delante y confirma que nada más en la red local alcanza el puerto.
4. Prueba a propósito una caída de modelo. Reanuda una conversación antigua tras una actualización de pi que cambie el catálogo y mira qué dice la cabecera. La especificación dice que no hay interfaz de reserva, así que la pregunta es si notas la sustitución silenciosa.
5. Verifica que el parche de pi sobrevive a tu próxima actualización. El parche SSE de Anthropic está atado a pi-ai@1.4.0, y Bun omite en silencio un parche cuya versión no coincide. Su propio archivo de pruebas decide si todavía aplica; si bifurcas, conserva esa prueba.
6. Lee pi-compatibility.md antes de abrir una incidencia. Buena parte de los «ThinkRail no funciona» son comportamientos de pi que el host documentó y decidió no tapar.

Preguntas frecuentes

¿ThinkRail es un producto de JetBrains? No. Lleva una insignia de «JetBrains incubator project» en el README y la marca «JetBrains InnovationHub» en la web, tiene licencia Apache-2.0 y se distribuye por las versiones de GitHub y npm, no por las páginas de producto de JetBrains. Ninguna página pública define a qué se compromete ninguno de los dos programas.

¿Puedo usar Claude Code u otro agente dentro? No por configuración. La especificación de producto lista «un segundo runtime de agente» como uno de sus exactamente dos no objetivos, y la implementación ejecuta pi en proceso sin un segundo runtime. Un contribuidor del proyecto bifurcó el código para alojar Claude Code en lugar de añadir una opción.

¿El agente está en un sandbox? No. La frontera es un worktree de git con su propia rama y su propio directorio, lo que protege tu árbol de trabajo y tu rama principal. No hay contenedor, máquina virtual, usuario del sistema separado ni jaula de sistema de archivos: el agente comparte el proceso del host y tus privilegios.

¿Envía datos a casa? Sí, por defecto, a PostHog: eventos básicos (arranques, creación de chats, envío de mensajes, conexión de proveedores) ligados a un identificador de instalación aleatorio, más informes de error siempre activos que llevan tipo, código y marcos de pila solo de ThinkRail. --no-analytics apaga únicamente el paquete adicional opcional; no apaga los eventos básicos ni los informes de error.

¿Qué pasa si el modelo de una conversación desaparece tras una actualización? El catálogo incluido pasó de 1.554 a 1.599 pares entre las versiones auditadas, con 71 eliminados y 116 añadidos. La especificación afirma que el host no muestra el modelFallbackMessage de pi y que no añade interfaz de reserva ni de aviso, así que revisa la cabecera después de cualquier actualización que toque el motor.

¿Qué plataforma está mejor soportada hoy en el canal estable? Los artefactos de escritorio de Windows y de Linux arm64/x64, más el DMG arm64 de macOS. Linux exige glibc 2.38+ (Ubuntu 24.04 o superior) y sus compilaciones de escritorio no están firmadas; la CLI de macOS está firmada pero no notarizada; el DMG de macOS Intel faltaba en las 28 versiones estables a 29 de octubre.

Conclusión

ThinkRail es un esfuerzo de ingeniería serio con un rastro documental inusualmente legible, y su afirmación más interesante no es la de la web. Es que un fabricante grande de IDE decidió que el motor del agente no era lo que había que poseer. Alquiló el motor a un proyecto 23 veces más popular que su propio IDE, lo fijó a una versión concreta, parcheó su código compilado donde se rompía y anotó trece formas de compensarlo, cada una con su criterio de retirada para que el préstamo siga siendo honesto.

Es una estrategia defendible, y también es una dependencia que heredas. Si adoptas ThinkRail adoptas el ritmo de publicación de pi, su rotación de catálogo, sus defectos de streaming y cada prueba de paridad que el host escribió para mantener el espejo intacto. El primer paso correcto no es instalarlo y ponerse a trabajar: es leer pi-compatibility.md, comprobar qué archivos existen de verdad para tu plataforma y ejecutarlo en algún sitio donde tus credenciales no sean críticas.