Esta versión amplía la migración del motor de terminal que llegó a Linux con Paneflow 0.8.0. Paneflow usa ahora el mismo núcleo VT de Ghostty por defecto en Linux x86_64, Linux ARM64 y Windows x64 MSVC. Alacritty sigue disponible en todas las plataformas como backend explícito de recuperación y continúa siendo la opción predeterminada en macOS y en los destinos no compatibles.

El motor Ghostty funciona ahora sobre ConPTY

Paneflow integra Ghostty en la capa del motor VT. libghostty-vt procesa secuencias de terminal, mantiene la cuadrícula y el estado del cursor, gestiona grafemas, ajuste de línea y reflow, y codifica las entradas de teclado y ratón. Paneflow sigue controlando la ventana, los paneles, las sesiones, el ciclo de vida de los procesos, la persistencia y el renderizado GPUI.

El port para Windows añade un host nativo alrededor de ese motor. Paneflow abre el pseudoterminal mediante portable-pty, que usa ConPTY en Windows, y entrega su salida UTF-8 a libghostty-vt. El estado de Ghostty se copia en snapshots de Rust con ownership propio antes de que GPUI lo pinte. La aplicación Ghostty, su interfaz y su renderizador no están integrados en Paneflow.

Esta separación es importante en Windows. ConPTY gestiona la conexión con el shell y el contrato de procesos del sistema operativo. Ghostty interpreta el terminal. Paneflow controla el producto y los píxeles. De este modo, el mismo renderizador independiente del backend puede mostrar sesiones de Alacritty o Ghostty sin una ruta de renderizado específica para Windows.

El port requería un ciclo de vida completo para Windows

Una biblioteca estática que compila en Windows solo es el primer paso. Las sesiones de terminal también necesitan un inicio, redimensionado, drenaje de salida, cierre y limpieza de procesos descendientes deterministas con PowerShell, consolas, TUI y agentes de código.

El host Ghostty para Windows agrupa los redimensionados de ConPTY, drena la salida final antes de cerrar una sesión, espera a su lector antes de salir y mantiene acotada la contrapresión cuando varios paneles generan salida a la vez. Paneflow 0.8.1 también agrupa los redibujados de Ghostty en Windows para evitar trabajo de renderizado innecesario.

La entrada atraviesa el mismo límite. La integración cubre la codificación de teclado de Ghostty, AltGr, teclas muertas, commits IME, pegado, portapapeles, ratón, foco y enlaces. Dos correcciones finales de la 0.8.1 conservan la entrada multilínea con Shift+Enter a través de ConPTY, incluidos los prompts de agentes de código que usan este atajo para insertar una nueva línea.

Paneflow incluye un artefacto MSVC estático y fijado

La compilación oficial para Windows x64 contiene un archivo ghostty-vt-static.lib fijado. Su commit de origen, toolchain de Zig, headers, bindings de Rust generados, símbolos, metadatos de compilación, licencias y sumas de comprobación se registran en el repositorio.

Los usuarios no necesitan instalar Ghostty, Zig, una DLL ni otro runtime. El MSI estándar consume el archivo verificado durante la compilación de Paneflow y el ejecutable resultante enlaza el motor de forma estática. La reconstrucción nativa y la compilación de Windows que consume el archivo permanecen separadas para que la CI detecte cualquier desviación de código fuente, ABI o artefacto antes de una versión.

Paneflow confina la ABI de C sin procesar a su crate -sys y expone ownership seguro de Rust por encima. Los handles nativos se liberan mediante el allocator correspondiente de Ghostty, los panics de callbacks permanecen tras el límite FFI y ninguna fila o celda prestada de Ghostty sobrevive al bloqueo del terminal ni cruza el límite de un frame.

Ghostty es automático y Alacritty está a un ajuste de distancia

terminal.backend acepta tres valores en Windows: auto, ghostty y alacritty. En la compilación x64 oficial de Paneflow 0.8.1, tanto auto como ghostty seleccionan el motor Ghostty. Configura alacritty en paneflow.json para forzar el backend anterior en las sesiones nuevas:

{
  "terminal": {
    "backend": "alacritty"
  }
}

El ajuste solo se aplica a sesiones nuevas. Paneflow puede volver una vez a Alacritty si Ghostty falla antes de que exista un proceso de shell. Después de iniciar el proceso, la sesión nunca cambia de backend y Paneflow nunca lanza un segundo shell detrás de ella.

Esta ruta de recuperación mantiene los fallos del terminal locales y reversibles. Puedes volver a Alacritty sin reinstalar Paneflow ni cambiar los datos de tus workspaces, y regresar a auto cuando se comprenda el problema.

Un solo núcleo de terminal para Linux y Windows

Paneflow 0.8.0 estableció el límite del motor en Linux. La versión 0.8.1 demuestra que ese límite puede cruzar un modelo de PTY y procesos muy diferente sin trasladar detalles de plataforma al renderizador ni al modelo de workspace.

Windows ARM64 queda fuera de esta versión y continúa usando Alacritty. macOS también permanece en Alacritty mientras su ruta Ghostty se evalúa por separado. En las compilaciones compatibles de Linux y Windows, auto significa ahora lo mismo: Ghostty para el núcleo del terminal, GPUI para el renderizado y Paneflow para el workspace multiagente que lo rodea.

Instala Paneflow 0.8.1, abre un panel nuevo y ejecuta el PowerShell, shell WSL, TUI o agente de código que uses habitualmente. Si algún comportamiento del terminal empeora, configura terminal.backend como alacritty para las sesiones nuevas e indica el shell, la versión de Windows, el comando y la secuencia reproducible más corta.

La migración cambia el motor que interpreta los datos VT y mantiene el estado del terminal, no el workspace que lo rodea. Paneflow sigue controlando el PTY, el ciclo de vida de los procesos, el motor de renderizado GPUI, los paneles, las sesiones, el estado de los agentes, los diffs y la persistencia. macOS y Windows continúan usando Alacritty.

Ghostty se incorpora a Paneflow en la capa del motor VT

Hasta Paneflow 0.7.x, las sesiones de terminal se apoyaban en el crate de Rust alacritty_terminal 0.26. Ese motor gestionaba las secuencias de escape, la cuadrícula, el scrollback, los modos de entrada, la búsqueda y parte del modelo de renderizado.

La nueva ruta de Linux usa libghostty-vt, el motor de terminal integrable de Ghostty. Analiza secuencias VT, mantiene el estado del cursor y la pantalla, gestiona grafemas, ajuste de línea y reflow, codifica entradas de teclado y ratón y expone un estado de renderizado incremental a la aplicación anfitriona.

Paneflow no integra la aplicación Ghostty, su interfaz GTK ni su motor de renderizado. Ghostty proporciona el núcleo del terminal. Paneflow convierte ese estado en snapshots propios de Rust y los dibuja con su motor de renderizado GPUI existente. La interfaz del producto y el flujo multiagente siguen bajo el control de Paneflow.

Una frontera de Paneflow separa ahora el motor del producto

Sustituir el parser era solo una parte del trabajo. Los tipos de Alacritty llegaban al bucle PTY, el renderizado, la búsqueda, la selección, los enlaces, la restauración del scrollback y el ciclo de vida de las sesiones. Cambiar una dependencia sin retirar antes ese acoplamiento habría trasladado el mismo problema a otro motor.

Paneflow expone ahora su propia frontera de sesión de terminal. Alacritty y Ghostty producen los mismos comandos, eventos, modos, resultados de búsqueda y snapshots de renderizado de Paneflow. El motor de renderizado ya no necesita saber qué motor de terminal creó una celda.

Esa frontera es la parte duradera de la migración. Linux puede avanzar primero sin modificar macOS ni Windows, y una futura actualización del motor ya no obliga al resto de la aplicación a adoptar sus tipos internos.

La API C inestable queda confinada en un pequeño wrapper de Rust

Ghostty describe libghostty-vt como funcionalmente maduro, aunque las firmas de su API todavía cambian. Por eso Paneflow fija el commit exacto de Ghostty ae52f97d, su header C, los bindings generados, la versión de Zig, la configuración de build y el checksum del archivo.

La ABI C sin procesar queda aislada en un crate -sys. Un segundo wrapper seguro posee cada handle nativo, valida la versión de la API y los layouts C antes de crear un terminal, contiene los panics de los callbacks y libera las asignaciones de Ghostty con el allocator correspondiente.

La regla de ownership importa especialmente durante el renderizado. libghostty-vt expone filas y celdas prestadas que una mutación posterior del terminal puede invalidar. Paneflow copia los datos necesarios mientras el terminal está bloqueado y después entrega a GPUI un snapshot propio de Rust. Ningún puntero C ni slice prestado sobrevive al bloqueo o al límite de un frame.

Esta estrategia exige más mantenimiento que seguir una dependencia sin fijar. Cada actualización de Ghostty requiere regenerar y revisar el header, los bindings, los archivos estáticos, checksums, símbolos y licencias para ambas arquitecturas Linux. El coste es explícito y está contenido, en lugar de convertirse en incertidumbre en runtime.

Alacritty sigue siendo la referencia diferencial y el rollback

El resultado visible buscado es la continuidad. Shells, agentes de código, TUI a pantalla completa, búsquedas, selecciones, operaciones del portapapeles, scrollback, eventos OSC, cambios de tamaño, reflow y cierre de procesos deben seguir comportándose como antes del cambio de motor.

Paneflow envía los mismos flujos VT deterministas a Alacritty y Ghostty con varios tamaños de fragmento, y después compara sus snapshots normalizados y eventos ordenados. Objetivos de fuzzing separados cubren secuencias malformadas o truncadas, codificación de entrada, cambio de tamaño, reflow y límites donde una secuencia llega en varias lecturas del PTY. Las comprobaciones de paquetes también rechazan un artefacto Linux si depende de libghostty.so en runtime, contiene una identidad de build incorrecta u omite los avisos nativos revisados.

Alacritty no se ha eliminado. Para usarlo en las nuevas sesiones de Linux, configura el backend en paneflow.json:

{
  "terminal": {
    "backend": "alacritty"
  }
}

Una sesión activa nunca cambia de motor en memoria. Ciérrala y abre un panel nuevo después de modificar el ajuste. auto selecciona Ghostty en las builds estándar de Linux y Alacritty en macOS, Windows o builds Linux compiladas con --no-default-features.

Enlace estático sin instalar Ghostty

Los paquetes oficiales para Linux contienen un archivo estático libghostty-vt fijado para x86_64 o ARM64. No necesitas instalar Ghostty, Zig ni una biblioteca compartida en tu máquina. Un cargo build normal desde un checkout limpio de Paneflow también usa el archivo verificado incluido en el repositorio y nunca descarga código fuente nativo durante build.rs.

Linux es la primera plataforma que recibe este backend. Extenderlo a Windows o macOS y retirar Alacritty en el futuro son decisiones separadas. Paneflow 0.8.0 limita el radio de impacto: un nuevo valor por defecto, dos motores compatibles y un rollback inmediato para las sesiones nuevas.

Actualiza a Paneflow 0.8.0, abre un panel nuevo y ejecuta el shell, la TUI o el agente de código que usas habitualmente. Si aparece una regresión del terminal, devuelve las sesiones nuevas a Alacritty e indica el comando, tu distribución Linux y si la sesión se ejecutaba bajo Wayland o X11.

El problema aparece cuando lanzas varios.

Un agente corrige un bug. Otro prepara una refactorización. Un tercero revisa un diff. Al lado, un servidor de desarrollo está corriendo, los tests pasan o fallan y cada terminal cuenta una parte distinta de la historia. En algún momento, lo difícil ya no es iniciar agentes. Es saber cuál está haciendo qué, cuál espera una respuesta, cuál terminó y en qué rama está trabajando.

Paneflow nació de ese problema exacto: mantener varios agentes de código visibles, controlables y comprensibles dentro de un único espacio de trabajo local.

Demo video: /videos/paneflow-landing-demo.mp4

La demo completa también está disponible en YouTube.

El hilo de lanzamiento está en Hacker News: Show HN: Paneflow.

La terminal sola no siempre basta

Me gustan las terminales. tmux, Zellij, Ghostty, Kitty y WezTerm son herramientas muy buenas, sobre todo cuando trabajas por SSH o en una máquina remota.

Pero cuando ejecutas varios agentes locales en el mismo proyecto, el problema cambia. Una cuadrícula de terminales muestra procesos. No te dice realmente qué agente está pensando, cuál espera tu aprobación, cuál produjo un diff interesante o cuál está repitiendo el trabajo de otro.

Con suficientes ventanas abiertas, acabas reconstruyendo el estado del proyecto en tu cabeza. Pasas de una terminal a otra, relees el scrollback, buscas el directorio correcto, verificas la rama actual y vuelves al diff. Una vez no es un gran problema. Como forma principal de trabajo, se vuelve caro.

Paneflow no intenta reemplazar tu editor. Reemplaza esa capa de coordinación que muchos desarrolladores construyen a mano con splits, nombres de ventanas, convenciones de ramas y mucha memoria a corto plazo.

Un espacio de trabajo por tarea, no solo un panel por comando

En Paneflow, un panel sigue siendo una terminal real. Puedes ejecutar Claude Code, Codex, OpenCode, Grok Builder o cualquier otra CLI que funcione en una shell.

La diferencia está alrededor de la terminal.

Una tarea puede tener su agente, sus tests, su servidor de desarrollo, su rama git, sus diffs y sus sesiones anteriores. Paneflow mantiene esas piezas en el mismo espacio de trabajo para que no tengas que redescubrirlas cada vez que cambias de contexto.

Cuando quieres aislar el trabajo, cada tarea puede correr en su propio git worktree. La vista Review muestra después los diffs lado a lado, un worktree por columna. Ves lo que produjo cada agente sin cambiar de ventana, rama ni editor.

Esa organización se vuelve especialmente útil cuando dos agentes trabajan en zonas cercanas del código. Puedes mantener sus salidas abiertas, comparar sus cambios y decidir cuál merece conservarse, corregirse o descartarse.

La coordinación pasa por la interfaz CLI

La apuesta más importante de Paneflow no es la visualización. Es la coordinación.

Llamo a esa capa Paneflow Conductor. Por ahora, lo que expongo a los agentes pasa intencionalmente por la interfaz CLI y el socket local. La GUI sigue siendo el lugar donde supervisas, lees y tomas el control de cualquier panel.

paneflow ps lista los paneles y agentes en ejecución con su estado real. paneflow watch emite cambios como JSONL, alimentados por hooks y el event bus en lugar de consultar la terminal en bucle. Un agente puede observar qué está corriendo, esperar un evento, preparar un prompt para otro panel y dejarte aprobar el envío final.

Por defecto, Paneflow rellena los prompts y tú sigues pulsando Enter. Auto-submit existe, pero es opt-in. Esa decisión es intencional: cuando varios agentes pueden actuar dentro del mismo proyecto, el control humano debe seguir visible.

Los agentes pueden leer sin tomar el control

Otra pieza importante es el servidor MCP integrado. Expone tres herramientas de solo lectura: list_panes, read_pane y search_pane.

En la práctica, Claude Code en un panel puede leer la salida de tests que Codex acaba de producir en otro. Un agente puede buscar un error en una terminal vecina antes de proponer un arreglo. Ya no necesitas copiar y pegar la salida de una herramienta en otra.

El límite es estricto: este puente no puede escribir en un panel ni manejar un agente por ti. La salida de terminal se trata como no confiable, porque un transcript de agente o un repositorio puede contener texto hostil. Paneflow hace más explícito el intercambio de contexto, pero no convierte cada terminal en una superficie de ejecución abierta.

Esa frontera es la parte que me importa: dar a los agentes suficiente contexto para que no trabajen a ciegas, sin darles poder silencioso sobre toda la sesión.

Por qué una app nativa

Paneflow está escrito en Rust y usa GPUI, el framework de interfaz detrás de Zed. Esa elección viene de una restricción simple: los agentes pueden ejecutarse durante mucho tiempo, a veces en paralelo, y el lugar que los contiene debe seguir siendo ligero.

No quería una app Electron alrededor de terminales que ya ejecutan procesos pesados. Tampoco quería una herramienta solo para macOS cuando mi propio trabajo se mueve entre Linux y Windows. Hoy Paneflow ofrece builds para Linux, macOS Apple Silicon y Windows x64. macOS Intel y Windows ARM64 aún no se distribuyen.

El resultado no es un IDE. Es un espacio de trabajo local y open source para desarrolladores que ya saben usar sus agentes CLI, pero ya no quieren coordinarlo todo a mano.

Prueba Paneflow en tu próxima sesión multiagente

Si lanzas un solo agente de vez en cuando, tu terminal actual probablemente basta.

Si empiezas a ejecutar varios agentes en paralelo, la pregunta cambia: ¿cómo mantienes su estado legible, sus ramas separadas, sus diffs revisables y su contexto compartible sin perder el control?

Ese es exactamente el problema que Paneflow busca resolver.

Descarga Paneflow, abre un proyecto, lanza dos agentes en dos paneles y comprueba si el espacio de trabajo reduce la carga mental que habías empezado a aceptar como normal.

Paneflow Conductor llega con Paneflow 0.6.0 para hacer explícita esa coordinación. Un agente puede descubrir a sus pares, leer su salida, enviar el siguiente prompt y esperar a que termine el turno mediante la CLI pública paneflow.

Demo video: /videos/paneflow-conductor-demo-linkedin.mp4

Una CLI para toda la flota

Todo pasa por el socket local de Paneflow. El conductor puede ser Claude Code, Codex, OpenCode, Gemini o un script, porque la interfaz son comandos de shell.

paneflow ps
paneflow status claude-impl
paneflow read claude-impl --lines 120
paneflow send claude-impl "Keep going and finish with REPORT_DONE"
paneflow wait --match claude-impl --pattern '^REPORT_DONE'
paneflow watch

Ese es el cambio importante. Codex puede inspeccionar lo que produjo Claude Code. Claude Code puede pasar una revisión a OpenCode. Un script puede iniciar el mismo workflow sin importar qué harness ejecuta cada panel.

Para trabajo repetible, paneflow up inicia un espacio de trabajo con hooks desde un archivo TOML, y paneflow flow run ejecuta una pipeline multiagente con spawn, espera, contexto y revisión.

Delegar sin ocultar las terminales

Paneflow Conductor no reemplaza a los agentes y no convierte Paneflow en un runtime hospedado. Los paneles siguen siendo terminales reales. Puedes leerlos, tomar el control, detener un comando o cambiar de dirección.

El valor está en que los agentes ya no necesitan contexto copiado y pegado. Un agente conductor puede leer un panel vecino, entender el estado actual, enviar un follow-up preciso y esperar una línea centinela como REPORT_DONE antes de continuar.

Ese patrón importa cuando separas implementación, revisión, tests y documentación. El agente líder no tiene que adivinar desde notas viejas. Puede inspeccionar la flota real.

Esperar estado, no temporizadores

Paneflow 0.6.0 añade una máquina de estados por turno para los agentes con hooks. Un panel puede reportar estados como thinking, waiting_for_input y finished. paneflow watch emite eventos de ciclo de vida como JSONL, y paneflow wait bloquea sobre una condición en lugar de dormir durante un retraso arbitrario.

Esa es la diferencia entre orquestación y screen scraping. Un conductor no debería consultar una terminal cada pocos segundos esperando que la salida se estabilice. Debería reaccionar cuando el agente se detiene de verdad, pide entrada o imprime el marcador prometido.

Mantener visible el límite de control

El modelo de seguridad es deliberado. El puente MCP es de solo lectura. paneflow read trata la salida de pares como datos no confiables. Por defecto, paneflow send pre-rellena un prompt y una persona sigue pulsando Enter.

Auto-submit existe, pero es opt-in mediante la puerta de scripting o el modo AI free access. Eso deja disponible el camino potente para worktrees aislados y workflows confiables, sin convertir las escrituras silenciosas entre paneles en el comportamiento por defecto.

Ese límite es el punto: dar a los agentes suficiente contexto compartido para trabajar juntos, mientras las terminales siguen visibles y la persona puede tomar el control.

Empezar con una flota pequeña

La referencia completa está en la documentación de Conductor. Empieza con dos paneles: un agente de implementación, un agente de revisión y un conductor que lee ambos antes de enviar el siguiente prompt.

Si ya ejecutas varios agentes CLI lado a lado, Paneflow Conductor les da una superficie común en lugar de otro protocolo privado.

Demo video: /videos/paneflow-diffview.mp4

Revisa todos los cambios de tu rama

Abre la vista Diff desde la barra lateral o con Ctrl+Shift+G. Paneflow muestra todos los archivos modificados desde que la rama se separó de su base, incluidos los cambios sin confirmar.

Puedes recorrer los bloques modificados, comparar añadidos y eliminaciones, y alternar entre una vista unificada y una vista lado a lado. Las cabeceras permanecen visibles mientras desplazas el contenido y el resaltado de sintaxis usa Tree-sitter, el mismo analizador sintáctico que Zed y GitHub.

Compara varias ramas sin cambiar de worktree

La vista de proyecto muestra el diff de la tarea actual. La vista Multi-project reúne los repositorios abiertos en pestañas. La vista Worktree coloca las ramas vecinas lado a lado, un git worktree por rama, para comparar su avance sin extraerlas una por una.

Pide una revisión a varios agentes

Cada rama tiene un botón Review. Elige Claude Code, Codex, OpenCode o Pi y Paneflow abre cada agente en un terminal real, directamente bajo el diff y en el directorio correcto.

Paneflow prepara el prompt de revisión pero nunca lo envía sin tu aprobación. Puedes revisarlo antes de pulsar Enter. El agente analiza entonces el diff y devuelve observaciones vinculadas a los archivos y las líneas correspondientes.

Lanza dos agentes para obtener dos lecturas distintas del mismo cambio. El segundo recibe una consigna más crítica para reducir las respuestas demasiado similares.

También puedes enviar una línea o un bloque concreto a un agente para hacerle una pregunta específica.

Haz que Paneflow revise tu próxima rama

La vista Diff y la revisión por agentes están disponibles desde Paneflow 0.3.7, una versión después de las sesiones de agente. Descarga la última versión, abre un proyecto y selecciona Diff en la barra lateral.

Demo video: /videos/sessions-agents.mp4

Encuentra las sesiones del proyecto correcto

Paneflow detecta las sesiones de Claude Code, Codex y OpenCode asociadas al directorio de trabajo activo. Aparecen agrupadas por agente, sin mezclar las conversaciones de tus otros proyectos.

Elige una sesión y Paneflow la retoma en el panel actual con su historial intacto.

Vuelve a una tarea sin empezar de cero

Una sesión contiene los intercambios, las decisiones y el plan ya construido con el agente. Poder dejarla y retomarla te permite pasar de una tarea a otra sin perder ese contexto ni repetir las mismas explicaciones.

Puedes cerrar un panel, reiniciar Paneflow o volver más tarde al proyecto. Las sesiones que importan siguen disponibles cuando las necesitas.

Retoma tu próxima sesión en Paneflow

Las sesiones de agente están disponibles desde Paneflow 0.3.6, la misma versión que la barra lateral Files. Descarga la última versión, lanza un agente en un proyecto y encuentra su sesión desde Paneflow.

Demo video: /videos/paneflow-dock.mp4

Navega por el proyecto actual

Abre la barra lateral desde el botón Files para ver las carpetas y archivos del proyecto. El árbol sigue automáticamente el espacio de trabajo activo y se actualiza cuando los archivos cambian en el disco.

Los elementos ignorados por .gitignore siguen siendo visibles pero aparecen atenuados, para que destaquen los archivos que importan. Paneflow también recuerda las carpetas abiertas entre reinicios.

Lee el Markdown en un panel

Haz clic en un README, un PRD u otro archivo Markdown para abrirlo renderizado en un panel. Así puedes mantener las instrucciones, el plan y el agente que los usa en la misma disposición.

El resto de archivos se muestra para que entiendas rápidamente la estructura del proyecto, sin convertir Paneflow en un gestor de archivos completo.

Mantén la documentación cerca de tus agentes

La barra lateral Files está disponible desde Paneflow 0.3.6, la misma versión que las sesiones de agente. Descarga la última versión, abre un proyecto y usa el botón Files para navegar por su contenido.

Paneflow parte de ese problema: varios agentes necesitan un espacio de trabajo diseñado para mantenerlos comprensibles.

Una tarea no se reduce a un terminal

Una tarea puede reunir un agente, una rama de git, un servidor de desarrollo, tests, un diff y varias sesiones. Si esos elementos están dispersos, tienes que reconstruir su contexto cada vez que cambias de ventana.

Paneflow los agrupa en un único espacio de trabajo y restaura ese entorno cuando vuelves. No encuentras solo un terminal abierto. Encuentras la tarea tal como la dejaste.

Los agentes pueden ayudarse sin tomar el control

El servidor MCP de Paneflow expone tres herramientas de solo lectura, list_panes, read_pane y search_pane, para que un agente pueda leer la salida de otro panel. Puede verificar un test, buscar un error o consultar el trabajo de otro agente sin que tengas que copiar y pegar su contenido.

Este puente es deliberadamente de solo lectura. Los agentes pueden compartir contexto, pero no pueden escribir comandos el uno en el otro. Tú mantienes el control de las decisiones y las acciones.

Una herramienta local que puedes entender

Paneflow funciona en local, sin cuenta y sin telemetría. Su código está disponible bajo licencia GPL-3.0-or-later.

La elección es simple: el espacio que ejecuta tus agentes y contiene el contexto de tu trabajo debe ser rápido, transparente y estar bajo tu control.

Prueba este enfoque en tu próximo proyecto

Descarga Paneflow y reúne los agentes, terminales y herramientas de tu próxima tarea en un solo espacio de trabajo.

Paneflow reúne tus agentes de código, sus terminales y todo lo que los rodea en un único espacio de trabajo local-first.

Un espacio de trabajo por tarea

Lanza Claude Code, Codex, OpenCode y otros 13 agentes CLI en paneles lado a lado. Añade los tests, los servidores de desarrollo o los comandos que la tarea necesite y vincula ese espacio a su rama de git.

Cada espacio conserva su disposición, sus terminales y sus sesiones. Puedes pasar de una tarea a otra o reiniciar Paneflow sin reconstruir tu entorno.

El contexto permanece visible

• Agentes y terminales: ve todo lo que está en marcha y pasa de un panel a otro con el teclado.
• Ramas y diffs: mantén cada tarea vinculada a su rama y revisa sus cambios sin salir de Paneflow.
• Sesiones de agentes: encuentra y retoma las sesiones de Claude Code, Codex y OpenCode del proyecto actual.
• Contexto entre paneles: gracias al servidor MCP integrado, un agente puede leer la salida de un test o buscar un error en otro panel, sin copiar y pegar.
• Entorno local: sin cuenta, sin telemetría y sin ningún servicio externo impuesto.

Una aplicación nativa diseñada para durar

Paneflow está escrito en Rust y usa GPUI, el motor de renderizado de Zed. Los paneles y los terminales se renderizan directamente por la aplicación, sin un navegador embebido alrededor de procesos que pueden ejecutarse durante horas. La aplicación completa pesa entre 14 y 19 MB.

El proyecto es open source bajo licencia GPL-3.0-or-later y funciona en Linux, macOS y Windows.

Lanza tu próximo agente en Paneflow

Descarga Paneflow, abre un proyecto y crea un espacio de trabajo para la tarea en la que quieres avanzar.