Terminal Browser: le puse ojos a mi agente
Introducción
Creo que nunca lo habia dicho, pero me gusta demasiado la terminal. La uso para todo: levantar servidores, editar código, mirar logs, abrir dashboards, y obviamente también para hablar con el agente de IA de La Cueva del Neandertech NTCODE. Y una de las cosas que más me gusta de la terminal es que todo está en la misma ventana: no hay pestañas, no hay ventanas flotando, no hay contextos distintos. Todo lo que necesito está ahí, y puedo cambiar de foco con un par de teclas. Y que creen? Ahora también tengo un navegador de verdad ahí mismo, en la terminal, y el agente puede usarlo para leer y manejar páginas sin que yo tenga que abrir otra ventana. Y justo eso es lo que veremos en este post.
Honestamente creo que algo de lo que no me siento orgulloso es trabajar con NTCODE e ir alternando ventanas con Super+`.Yo le pedía al Agente que revisara la documentación de un proyecto, él me tiraba un resumen basado en el HTML crudo, y yo igual terminaba abriendo el navegador en otra ventana para confirmar que lo que decía se parecía a lo que yo estaba viendo. Dos contextos, dos pantallas, y la sensación de que le estaba pidiendo a alguien que describiera una película que no puede ver.

Hace poco, mientras revisaba los docs de ShellRest, probé algo distinto: en vez de abrir Firefox aparte, le dije al agente que abriera la página en Terminal Browser. Se partió mi panel solo, la doc quedó a la derecha de la conversación, y de golpe el agente y yo estábamos mirando exactamente lo mismo. No es un cambio revolucionario en el papel. En la práctica me sacó una fricción que arrastraba hace meses.

Qué es Terminal Browser
Es un navegador real dentro de una celda de la terminal: motor de verdad, con JavaScript, render y DOM, no un lynx ni un scraper. Sin argumentos toma el panel actual; con --split right (o down, left, up) abre uno nuevo al lado. Y una ruta a un .html local se abre igual que una URL, así que mostrar algo que el agente genera es abrir el archivo, sin subir nada a ningún lado.
terminal-browser open localhost:3000
terminal-browser open ./plan.html --split right
Para ubicarlo, sirve compararlo con cosas que ya conoces:
- Como un Playwright o un Chrome headless, pero al revés en dos cosas. Playwright también levanta un navegador real y lo maneja por API, pero lo hace invisible y pensado para que un test lo conduzca. Terminal Browser lo deja a la vista, en un panel a tu lado, y la "API" es una CLI (
terminal-browser action) que tanto tú como el agente pueden usar a mano. No es para suites de tests, es para mirar y tocar. - Como el panel de preview que traen algunos editores (el "Simple Browser" de VS Code, el preview de JetBrains), pero desacoplado del editor. No vive dentro de un IDE ni de una extensión: es un binario de terminal, así que funciona en
ssh, entmux, enherdr, en cualquier flujo que ya tengas, sin depender de qué editor abriste.
Lo que no es: un live server. No observa tus archivos ni recarga solo cuando guardas. Comparte con Live Server o browser-sync el gesto de "apunta a localhost y mira", pero ahí termina el parecido; si quieres que refleje un cambio, lo recargas tú, o le pides al agente que lo haga con un eval o reabriendo la pestaña.
Eso no significa que no podamos ejecutar browser-sync y abrir la URL en Terminal Browser.
El plugin de herdr
No lo instalé a mano. Hace unos meses les conté que me pasé de tmux a herdr, un multiplexor de terminal pensado para trabajar con agentes. Y da la casualidad de que Terminal Browser lo hace la misma gente (zenbu-labs) y tiene plugin oficial para herdr:
herdr plugin install zenbu-labs/terminal-browser/herdr-plugin
El plugin hace dos cosas concretas. La primera, en el paso de build ejecuta curl -fsSL https://terminal-browser.sh/install | bash por ti, así que no tienes que preocuparte por descargar el binario. La segunda, agrega una acción a la paleta de comandos de herdr, open-split, que divide el panel enfocado y abre Terminal Browser a la derecha, que es exactamente el gesto que hago cien veces al día.
El plugin pide herdr >= 0.8.2 y aporta la instalación y el atajo de paleta. Pero el terminal-browser action que le da ojos y manos al agente es de Terminal Browser, funciona igual sin herdr. Lo que herdr suma al combo es su modelo de fondo: agente y navegador acotados a la misma pestaña de terminal, sin ventanas sueltas por ahí.
El agente maneja la pestaña
Esto es lo que lo separa de "abrir un navegador y ya". Sobre una pestaña ya abierta hay un subcomando action que expone una CLI compatible con agent-browser:
terminal-browser action -- snapshot
terminal-browser action -- click @e14
terminal-browser action -- fill @e3 "hola"
terminal-browser action -- eval "document.title"
snapshot fue el que me cambió la forma de trabajar. Devuelve el árbol de accesibilidad de la página, con referencias tipo @e14 para cada elemento. El agente deja de adivinar sobre HTML crudo y pasa a leer la página como la lee un lector de pantalla: encabezados, botones, links, texto real, en el orden real. Con esas referencias después puede hacer click, fill o eval sobre elementos concretos.
En el caso de ShellRest, el agente sacó un snapshot, me listó las dieciséis secciones de la doc y me marcó qué badges tenía el header, todo sin que yo tocara el mouse ni él inventara nada. Estábamos leyendo la misma fuente.

Lo que no esperaba: el snapshot sale casi instantáneo y es bastante más limpio que pasarle el HTML crudo a un agente. Nada de <div> anidados diez niveles ni clases de Tailwind: encabezados, roles, texto, en orden de lectura. Para el modelo es menos ruido, y para mí menos tokens quemados en markup que no aporta.
Todos los navegadores que abres en paneles comparten un mismo proceso por debajo, como optimización. Si quieres cerrar todo de una vez, terminal-browser shutdown mata el daemon y con él todas las pestañas.
Cuánta RAM consume
"Un navegador en la terminal" suena liviano hasta que miras los procesos. Por debajo es Electron, así que abrir Terminal Browser levanta el mismo árbol que Chromium: un daemon, un par de zygotes, un proceso de GPU, uno de red y un renderer por pestaña. Con la doc de ShellRest abierta y nada más, esto es lo que medí en mi máquina:
| Métrica | Valor (1 pestaña abierta) |
|---|---|
Procesos electron | 8 |
| RSS sumado | ~1.05 GB |
| PSS real (descuenta memoria compartida) | ~380 MB |
| Renderer de la pestaña (PSS) | ~73 MB |
| Proceso de GPU (PSS) | ~86 MB |
| Daemon (PSS) | ~133 MB |
| CPU en reposo | ~0.3% de pico, casi 0 el resto |

El RSS sumado asusta pero engaña: cuenta la misma memoria compartida una vez por proceso. El número honesto es el PSS, y ~380 MB para tener un navegador real embebido al lado de la conversación me parece un trato justo. Cada pestaña nueva suma sobre todo un renderer (esos ~70 MB), no otro árbol entero. Aun así: no es gratis, y en un equipo con poca RAM se nota. No lo dejo abierto todo el día porque sí; lo abro cuando lo necesito y cierro con terminal-browser shutdown.
Para que los números tengan contexto, esta es la máquina donde los medí. Una laptop de trabajo común y corriente, ni potente ni vieja, sin GPU dedicada, y sin tmux ni Zellij corriendo en ese momento. Si funciona aquí, te va a funcionar.

Dónde no lo uso
Es una herramienta joven, v0.7.x al momento de escribir esto, y se nota: depende de que tu terminal reporte bien sus colores y de que el multiplexor coopere con los splits (para eso está terminal-browser setup).
No lo abro para navegar en serio. Nada de leer correo, redes ni sesiones largas con muchas pestañas porque para eso tengo Qutebrowser, y con el consumo de RAM que ya vimos no tiene sentido pelear. Tampoco lo uso para páginas pesadas de JS, ahí el render dentro de la celda se arrastra. Lo que sí: documentación, dashboards internos, localhost de algo que estoy levantando, y HTML que genera el agente. Casos cortos, con un objetivo, donde el valor es que el agente y yo veamos lo mismo sin cambiar de ventana.
Conclusión
Lo que me llevo no es "descubrí un navegador nuevo". Es que cerré la brecha entre lo que el agente entiende de una página y lo que yo veo. Durante meses trabajé asumiendo que esa diferencia era parte del trato: el agente lee tokens, yo miro píxeles, y en el medio hay una traducción que siempre pierde algo. Terminal Browser mete a los dos en la misma pestaña.
Sigo pensando que la persona lleva el timón y la IA ejecuta bajo dirección. Pero es más fácil dirigir a alguien cuando los dos miran el mismo mapa.
Referencias

