ThinkRail: el IDE Agéntico Open Source de JetBrains con Git Worktrees

ThinkRail (JetBrains/thinkrail) es uno de los repos que más rápido suben en GitHub esta semana: un IDE agéntico open source que el InnovationHub de JetBrains armó alrededor de pi, el agente de código minimalista para la terminal. Su idea central: cada workspace es su propio git worktree, con su rama, sus archivos, sus terminales y sus chats, así varios agentes pueden trabajar sobre un mismo repo sin pisarse entre ellos ni tocar tu checkout.

El 3 de noviembre de 2026 leí el README, las specs de arquitectura y de workspaces, los dos scripts de instalación y las notas de la v0.3.0 y la v0.3.1, y contrasté los números con la API de GitHub y la página de trending. No lo instalé ni corrí un agente: cada comando de abajo está chequeado contra el repo, y lo que no pude confirmar quedó afuera.

1. Qué Es: Stars, Licencia y Alcance

ThinkRail se presenta como “el IDE agéntico que mejora cada vez que lo usás”. En la práctica es un workbench con pestañas del editor Monaco, un árbol de archivos que entiende git, terminales y chats, acotado a un workspace a la vez, alrededor de un agente que hace el trabajo. El sitio le da el crédito al InnovationHub de JetBrains, y el README lleva el badge de proyecto incubado de JetBrains. Llega justo cuando la propia encuesta de JetBrains ubica el uso semanal de agentes en el 90% de los developers.

⭐

Stars en GitHub

~7.3K

API de GitHub, 3 nov 2026, con ~435 forks; +4,812 esta semana

⚖️

Licencia

Apache-2.0

La de ThinkRail. pi, el motor, es MIT

🏷️

Última estable

v0.3.1

Publicada el 1 nov 2026. Las nightlies van por la 0.4.0

🧠

Motor

pi 1.5.0

Fijado en el catálogo de paquetes raíz

Por qué está en trending ahora

Se creó el 8 de julio de 2026, se presentó el 19 de agosto y desde entonces sale rápido: la v0.2.0 el 18 de octubre, la v0.3.0 el 29 de octubre y la v0.3.1 el 1 de noviembre, más nightlies casi diarias. La página de trending semanal de GitHub le marca +4,812 stars esta semana, con max-sixty/worktrunk, una CLI de worktrees para agentes en paralelo, en la misma lista.

No es JetBrains Air, y tampoco un plugin

JetBrains ya tiene Air, un entorno agéntico en public preview desde marzo de 2026 que corre Codex, Claude Agent, Gemini CLI y Junie sobre ACP. ThinkRail es un proyecto aparte, solo con pi, cuya spec de producto lista “un segundo runtime de agente” como non-goal. Tampoco es un plugin de IntelliJ: es una app independiente que puede pasarle un worktree a tu IDE.

2. La Arquitectura en 4 Pasos

El README lo resume como “un host liviano que corre pi en el mismo proceso y lo conecta con una interfaz web rica”. Siguiendo architecture.md, un mensaje de chat atraviesa cuatro capas.

🚀

1. Dos launchers, un host

La app de escritorio envuelve el host con Electrobun y un webview nativo del sistema. La CLI thinkrail es un binario autocontenido que levanta el mismo host en localhost:24242 y abre tu navegador. Los dos embeben la misma librería de host, y el estado de la app vive en ~/.thinkrail.

⚙️

2. Un host de motor con pi adentro

packages/server es un host HTTP y WebSocket sobre Bun.serve que corre una sesión de pi en proceso por chat. Cada sesión recibe extensiones de pi incluidas (grafo de specs, workflows, todos, subagentes, comandos en segundo plano) más visualize, ask-user-question y web-access de ThinkRail.

🔌

3. Un protocolo tipado y versionado

packages/contracts es el único acoplamiento entre el host y la interfaz. El cliente React 19 de apps/web depende de eso, nunca del servidor. Lee el estado actual y después se suscribe a los cambios, así una recarga, otra pestaña o un reinicio del host reconstruyen la misma vista, y un teléfono puede conectarse a un host por Tailscale.

🌳

4. Proyectos, workspaces, worktrees

Un proyecto es un repo de git. Un workspace es un git worktree con su propia rama bajo ~/.thinkrail/worktrees/<proyecto>/<rama>, dueño de sus chats, archivos y terminales. Dos excepciones siguen siendo tuyas y nadie las toca: el workspace Default, que es la carpeta del proyecto, y los worktrees existentes que adjuntes en su lugar.

Quién es dueño de qué: pi vs ThinkRail

pi es dueño de los modelos, las skills, la compactación, el costo y el estado de sesión. ThinkRail es dueño del workspace, el editor y el protocolo, y el README promete que “nunca arma prompts a tus espaldas”. En la práctica lee tu config de ~/.pi/agent, así que logins, skills, paquetes y sesiones se comparten con la CLI de pi, y un servidor de modelos que agregás en ThinkRail termina en el models.json de pi.

Qué es pi, exactamente

pi es la CLI de agente de código del monorepo earendil-works/pi (badlogic/pi-mono redirige ahí): MIT, unas 119.8K stars, npm @earendil-works/pi-coding-agent 1.5.0. npm nombra a Mario Zechner como autor y a Armin Ronacher entre los maintainers. Se define como “un harness de agentes mínimo y extensible” y deja afuera a propósito los subagentes y el modo plan; ThinkRail suma las dos cosas como paquetes de pi. Necesita Node.js 22.19+.

3. Quickstart: App de Escritorio o CLI

Dos formas que podés instalar juntas: una app de escritorio y la CLI thinkrail, las dos publicadas con SHA256SUMS en la página de releases. Los comandos salen del README, los dos scripts de instalación y apps/cli/src/args.ts; no los ejecuté.

Opción A: la app de escritorio

# Stable desktop builds (releases/latest points at the newest stable: v0.3.1 today)
# macOS 14+, Apple Silicon or Intel: open the DMG for your architecture
https://github.com/JetBrains/thinkrail/releases/latest/download/thinkrail-desktop-darwin-arm64.dmg
https://github.com/JetBrains/thinkrail/releases/latest/download/thinkrail-desktop-darwin-x64.dmg

# Windows x64: extract the ZIP, then run its setup executable in place, next to its payload
https://github.com/JetBrains/thinkrail/releases/latest/download/thinkrail-desktop-windows-x64.zip

# Linux x64 / ARM64: extract the tarball, then run ./installer
https://github.com/JetBrains/thinkrail/releases/latest/download/thinkrail-desktop-linux-x64.tar.gz
https://github.com/JetBrains/thinkrail/releases/latest/download/thinkrail-desktop-linux-arm64.tar.gz

# Linux desktop prerequisites: glibc 2.38+ with GTK 3 and WebKitGTK 4.1 (Ubuntu 24.04+)
sudo apt install libgtk-3-0 libwebkit2gtk-4.1-0 libayatana-appindicator3-1 librsvg2-2

Opción B: la CLI (leé el instalador primero)

# The README pipes the script straight into bash:
#   curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash
# macOS / Linux / Git Bash: download it, read it, then run it
curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh -o install.sh
less install.sh
bash install.sh                        # stable channel, binary at ~/.local/bin/thinkrail
# bash install.sh --channel nightly    # nightly builds instead

# Windows PowerShell: a saved copy of install.ps1 takes parameters
irm https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.ps1 -OutFile install.ps1
notepad install.ps1
.\install.ps1                          # stable, binary at %USERPROFILE%\.local\bin\thinkrail.exe

Pasarle un script a bash es una decisión de confianza

El script es cuidadoso: resuelve el release, valida el SHA-256 del binario contra SHA256SUMS y recién ahí pone thinkrail en tu PATH. Pero curl | bash ejecuta lo que el servidor devuelva, sin que lo leas. ¿Sin ningún script? Bajá un binario y SHA256SUMS, verificá el checksum y guardalo como <prefix>/bin/thinkrail para que funcione la autoactualización.

Primer arranque y comandos de todos los días

thinkrail ~/code/my-repo               # boot the host on localhost:24242, open the repo as a project
thinkrail --no-open --port 4000        # headless host, e.g. on a remote machine
PI_CODING_AGENT_DIR=$HOME/.pi/agent-personal thinkrail   # another pi config for this launch
thinkrail --version
thinkrail update                       # re-run the installer for your channel
thinkrail uninstall                    # keeps ~/.thinkrail unless you pass --remove-data

Qué te pide el primer arranque

Necesitás git en tu PATH y un proveedor de modelos. Un asistente corto te hace la pregunta de privacidad y después pasa a Connect a model. Las sesiones que ya tengas en Claude Code, Codex, Copilot, Kimi CLI o Grok Build aparecen en Detected, pero ThinkRail solo lee sus archivos de config y nunca toma prestadas las credenciales: igual iniciás sesión con pi. JetBrains AI se conecta con la CLI central de JetBrains, Settings → Providers acepta cualquier servidor compatible con OpenAI, y las funciones de PR necesitan gh con sesión iniciada.

Notas de plataforma

Los builds de escritorio cubren macOS 14+ (Apple Silicon e Intel), Windows x64 y Linux x64/ARM64; no hay build para Windows en ARM. JetBrains firma los binarios de Windows; la CLI de macOS está firmada pero no notarizada, y los artefactos de Linux no están firmados. La app de escritorio en Linux necesita glibc 2.38+, lo que deja afuera a Ubuntu 22.04.

Telemetría que no podés apagar del todo

Según el README, las apps siempre mandan eventos básicos de uso (arranques, chats, mensajes, proveedores conectados) y reportes de errores, atados a un ID de instalación aleatorio y sin prompts, código ni credenciales. Solo los datos de uso adicionales se pueden apagar: Settings → Privacy, --no-analytics o THINKRAIL_NO_ANALYTICS=1. ¿Necesitás cero telemetría saliente? Hoy eso te frena.

4. El Flujo con Worktrees en Paralelo, Paso a Paso

Esta es la parte que se gana las stars: el ciclo de la idea al PR mergeado, tal como lo describen el README, la spec de workspaces y el post de la 0.3.0.

🧭

1. Elegí el aislamiento a propósito

Al abrir un proyecto caés en una bifurcación de bienvenida: Start building corta un worktree aislado con su rama, mientras que Work in project folder corre en tu checkout sin aislamiento. ThinkRail nunca elige la carpeta por vos, salvo para el chat de setup de un repo nuevo y vacío.

✍️

2. Describí la tarea

En Create workspace elegís una rama base y describís la tarea; ThinkRail le pone nombre al workspace y a la rama a partir de ese texto, que además pasa a ser el primer prompt del agente. El worktree se corta con --no-track, así un git push desde su terminal nunca apunta por accidente a la rama base.

🔀

3. Abrí en abanico

Repetí para la siguiente tarea. Cada workspace mantiene sus propios chats, archivos, terminales y cambios, y cada chat es una sesión de pi separada con su propio modelo y su costo en vivo. Los agentes también pueden delegar en subagentes, 4 a la vez por defecto (de 1 a 16).

🔍

4. Revisá en el lugar

El panel Files alterna entre All y Changed. Anclá comentarios en archivos y diffs y mandalos al chat como contexto estructurado, o hacé que el agente trabaje un plan compartido cuyos pasos se pueden commitear y revisar uno por uno. Open in le pasa el worktree a VS Code, Emacs, Vim o un IDE de JetBrains que tengas en el PATH.

🚢

5. Publicá desde la barra superior

La barra superior siempre muestra el siguiente paso de la rama: Publish, Push N o Sync (que te muestra antes su git pull --rebase y nunca hace force-push). Open PR pushea y abre o actualiza el PR con tu propio gh, y arma la descripción desde el plan, los commits o tu template. Después vienen los checks de CI, Fix with agent para los que fallan y Merge PR.

🧹

6. Mergeá el bueno, borrá el resto

Remove workspace borra sus chats, terminales y worktree, pero conserva la rama. Los workspaces cuyo PR se mergeó o se cerró, o que estuvieron quietos una semana, pasan a un estante por proyecto hasta que vuelvas a trabajar en ellos.

Qué es un workspace en git puro (ilustración, no son comandos de ThinkRail)

# Roughly what "Create workspace" runs (packages/server/src/workspaces/SPEC.md)
git worktree add --no-track -b fix-login-redirect \
  ~/.thinkrail/worktrees/my-app/fix-login-redirect origin/main

# What "Open existing worktree..." parses to list checkouts you can attach
git worktree list --porcelain -z

# What "Remove workspace" runs: the folder goes, the branch stays
git worktree remove --force ~/.thinkrail/worktrees/my-app/fix-login-redirect
git branch --list fix-login-redirect   # still there

Nada exótico, y es una buena noticia: tus ramas y tu historial siguen siendo git puro, que podés inspeccionar desde cualquier terminal. Ojo con el --force: quitar un workspace descarta todo lo que no esté commiteado ahí, así que commiteá o pusheá antes.

Un worktree nuevo es un checkout nuevo

git worktree add solo hace checkout de los archivos versionados, así que node_modules, los archivos .env y las cachés de build no están en un workspace nuevo, y no encontré un hook de setup para eso en la spec de workspaces de ThinkRail. Contá con un paso de instalación por workspace (o pedile al agente que lo corra) y vigilá el espacio en disco. Git tampoco deja hacer checkout de una misma rama en dos worktrees; por eso cada workspace lleva una rama nueva.

Un worktree no es un sandbox

El aislamiento acá cubre tu checkout, no tu máquina. El README de pi dice que no trae un sistema de permisos para archivos, procesos, red ni credenciales. ThinkRail controla lo que un repo puede inyectar (sus recursos .pi, skills y servidores MCP cargan solo después de que confiás en el proyecto) y pregunta antes de las llamadas MCP que no están marcadas como de solo lectura, pero la herramienta de shell igual corre como vos. Para código en el que no confiás, usá un contenedor, como sugiere la documentación de pi.

5. ThinkRail vs Worktrees a Mano vs un IDE Completo de JetBrains

Los worktrees para agentes en paralelo no son nuevos, y los podés conseguir de otras tres formas. La diferencia está en cuánto del ciclo alrededor del agente resuelve cada opción.

Cómo se comparan

Aspecto	ThinkRail	Worktrunk + tu CLI de agente	IntelliJ IDEA 2026.1+	JetBrains Air
Qué es	Un IDE agéntico alrededor de un solo motor	Una CLI que hace los worktrees tan fáciles como las ramas	Un IDE completo con agentes en el chat de IA	Un entorno agéntico para varios agentes
Agentes	Solo pi, con cualquier modelo que soporte pi	La CLI que lances: wt switch -c -x claude feat	Junie, Claude Agent, Codex y agentes ACP	Codex, Claude Agent, Gemini CLI, Junie (ACP)
Worktrees	Cada workspace es uno; los crea y los quita por vos	Es la función central: switch, list, merge, remove	Soporte de primera clase desde la 2026.1	Worktrees o contenedores Docker, por tarea
Review y PRs	Diff, comentarios anclados, commits por paso, PR y CI en la barra superior	wt merge hace squash, rebase y limpieza; estado de CI en wt list --full	Todo el tooling de VCS y diff del IDE	Review en el contexto del código, después trae los cambios
Profundidad del editor	Pestañas de Monaco; le pasa el trabajo a tu IDE	El editor que ya usás	Refactoring, debugger, inspecciones	Terminal, cliente Git y preview integrados; tu IDE para el resto
Plataformas	macOS 14+, Windows x64, Linux con glibc 2.38+, o un navegador	macOS, Linux y Windows (winget)	macOS, Windows, Linux	macOS en el lanzamiento; Windows y Linux anunciados
Licencia y costo	Apache-2.0, sin plan pago; le pagás a tu proveedor de modelos	MIT OR Apache-2.0, gratis	Licencia de JetBrains; agentes vía JetBrains AI o la cuenta de cada agente	Descarga gratis; plan de JetBrains AI o tus propias keys

El camino con worktrunk, para comparar (según su README)

# Install (macOS / Linux) and enable directory switching
brew install worktrunk && wt config shell install

wt switch -c -x claude feat    # new worktree + branch "feat", start Claude Code in it
wt list                        # every worktree with its status
wt step copy-ignored           # copy gitignored files (node_modules, .env...) between worktrees
wt merge                       # squash, rebase onto the default branch, remove worktree + branch

Cómo elegiría yo

¿Estás cómodo en la terminal con Claude Code o Codex? worktrunk te suma higiene de worktrees sin cambiar de agente. ¿Necesitás refactoring y un debugger al lado del agente? IntelliJ 2026.1+ ya tiene worktrees y varios agentes dentro del IDE. ¿Querés una sola ventana para todo el ciclo, de la tarea al PR mergeado, con pi como motor? Ese es el nicho de ThinkRail. Y se combinan: Open existing worktree… de ThinkRail adjunta un checkout creado con worktrunk o con git a mano, sin tocarlo.

6. Casos de Uso: Dónde Se Gana su Lugar

En estas cuatro, el modelo de un worktree por agente cambia el resultado, no solo la interfaz.

🐛

Tres fixes, tres ramas

Cortá un workspace por bug desde la misma base, dejá correr a cada agente y revisá cada diff por separado. Mergeá el correcto, quitá el resto; tu checkout nunca vio nada de eso.

Ideal para: backlogs de bugs, tests inestables y refactors chicos que querés resolver en paralelo

⚖️

Enfoques que compiten

Dale la misma tarea a dos workspaces con modelos distintos (cada chat elige el suyo) y compará los resultados lado a lado, con la lectura de costo incluida.

Ideal para: comparar modelos sobre tu propio código en lugar de benchmarks

📐

Proyectos spec-first

Set up project corre una skill que redacta un grafo de SPEC.md a partir del objetivo del proyecto, antes de escribir código. El agente lo mantiene con las herramientas spec_*, así las decisiones sobreviven al chat que las tomó.

Ideal para: repos de larga vida donde el agente vuelve a deducir las mismas decisiones

🏠

Una GUI para tu setup de pi o modelos locales

Lee ~/.pi/agent, tus paquetes de pi, tus skills y tu mcp.json, así que no hay nada que migrar. Sumá un servidor de Ollama, vLLM o LM Studio en Settings y sus modelos aparecen en el selector del chat y en la CLI de pi por igual.

Ideal para: usuarios de pi y equipos que corren modelos propios (por ahora solo la API de chat completions)

Lo que cuestan de verdad los agentes en paralelo

ThinkRail no tiene plan pago ni cuentas; no encontré una página de precios. Le pagás al proveedor que conectes, así que cuatro workspaces ocupados son cuatro facturas a la vez, más los subagentes. La barra del chat muestra el costo que reporta pi, con los subagentes incluidos desde la 0.3.0. Una trampa: la v0.3.1 avisa que iniciar sesión con Claude Pro o Max se factura como uso extra por token, fuera de los límites de tu plan, porque pi se conecta directo por la API.

7. Cuándo NO Usarlo

Esta es la parte que un contador semanal de stars no te cuenta.

✅ Encaja bien si...

• Ya usás pi, o querés un agente agnóstico de modelo con tus propias keys, JetBrains AI o modelos locales
• Corrés de dos a cuatro tareas de agente sobre el mismo repo y perdés el hilo de ramas y terminales
• Revisás los cambios del agente línea por línea y querés que tus comentarios le vuelvan al agente
• Publicás con PRs de GitHub y ya tenés gh con sesión iniciada

⚠️ Evitalo (o dejalo como experimento) si...

• Necesitás una herramienta asentada: es 0.x, con tres releases estables en dos semanas y 351 issues y PRs abiertos
• Querés Claude Code, Codex o Gemini CLI como agente: ThinkRail es solo pi, por diseño
• Necesitás un sandbox: los worktrees aíslan archivos, no procesos, red ni credenciales
• Estás en Ubuntu 22.04 o anterior o en Windows sobre ARM, o necesitás binarios notarizados o firmados en todas partes
• Necesitás cero telemetría saliente: los eventos básicos de uso y los reportes de errores siempre están activos
• Es un solo agente sobre un repo chico: una sola sesión en tu checkout es más simple
• Necesitás refactoring, un debugger y tooling profundo del lenguaje: eso sigue siendo trabajo de tu IDE

Mi postura

Probá la app de escritorio en un repo que conozcas, mantené al agente en workspaces y no en la carpeta del proyecto, y dale a dos de ellos tareas chicas e independientes desde la misma base. Juzgalo por el ciclo de review y PR, no por el chat; si ese ciclo te ahorra cambios de contexto, vale el vaivén de una 0.x. Antes de escalar, poné un límite de gasto con tu proveedor, commiteá antes de quitar un workspace y meté en un contenedor todo lo que no te dé confianza.

Conclusión

La propuesta de ThinkRail se sostiene en el repo: pi hace el trabajo de agente, ThinkRail es dueño del workspace, el editor y el protocolo, y cada workspace es un git worktree común. El ciclo alrededor del agente, de la tarea al review y al PR mergeado, es donde le gana a una CLI de worktrees pelada.

Los costos son los típicos de una 0.x: releases que se mueven rápido, pi como único motor, telemetría básica siempre activa, ningún sandbox y agentes en paralelo que multiplican tu factura de modelos. Empezá de a poco, mantené el trabajo en workspaces aislados y dejá que el flujo de PR se gane la confianza de tu rama principal.

Sello de verificación

Las estadísticas del repo y los releases salen de la API REST de GitHub, y el delta semanal de stars de github.com/trending, los dos el 3 de noviembre de 2026. Los comandos, flags, puertos y rutas salen del README, los dos scripts de instalación, apps/cli/src/args.ts, architecture.md y la spec de workspaces en el commit c10f880 (v0.3.1). Los datos de pi, worktrunk, Air e IntelliJ salen de sus propios READMEs, documentación y anuncios. No instalé ThinkRail ni corrí un agente.