Capital de Tokens
Hace apenas unos meses, Intelligent Terminal podía describirse de forma bastante sencilla:
Windows Terminal, pero con un agente de IA integrado en un panel lateral.
Esa descripción ya empieza a quedarse corta.
Microsoft está desarrollando el proyecto como un fork experimental y open source de Windows Terminal, pero durante julio y agosto de 2026 añadió suficientes piezas como para que el producto empiece a parecer menos un “terminal con chat” y más un host para agentes de desarrollo.
La diferencia no es semántica.
Un chat dentro de una terminal puede responder preguntas.
Un host agéntico necesita resolver problemas mucho más estructurales:
¿Qué agente ejecuta esta tarea?
¿Dónde corre?
¿Qué shell y filesystem ve?
¿Qué sesión debe reanudar?
¿Qué modelo usa?
¿Qué comandos puede proponer?
¿Cómo se mantiene aislado de otras pestañas?
¿Qué ocurre cuando cierro la ventana?En los últimos dos meses, Microsoft atacó precisamente esas capas.
El resultado es una dirección bastante clara:
Intelligent Terminal
↓
terminal multipane
+ agentes intercambiables
+ ACP
+ WSL
+ modelos locales
+ sesiones
+ tool / command surfacesY eso convierte al proyecto en uno de los experimentos más interesantes alrededor de la idea de una shell agent-first.
Primero: qué es Intelligent Terminal
Microsoft anunció Intelligent Terminal 0.1 el 2 de junio de 2026 como un fork experimental de Windows Terminal con integración nativa de agentes.
El proyecto hereda prácticamente toda la infraestructura de Windows Terminal —pestañas, panes, perfiles, shells, renderer, configuración— y añade una nueva capa alrededor del Agent Pane.
En vez de obligar al usuario a mantener un chatbot separado del entorno donde está trabajando, el agente vive junto al shell.
Conceptualmente:
┌───────────────────────────────────┐
│ Intelligent Terminal │
│ │
│ ┌──────────────┐ ┌─────────────┐ │
│ │ PowerShell │ │ Agent Pane │ │
│ │ / WSL / bash │ │ │ │
│ │ │ │ ACP agent │ │
│ └──────────────┘ └─────────────┘ │
└───────────────────────────────────┘La pieza arquitectónica importante es ACP — Agent Client Protocol.
En vez de codificar la integración de cada CLI de IA completamente dentro de la terminal, Intelligent Terminal puede hablar con agentes mediante una interfaz común.
Eso reduce el acoplamiento entre:
Terminal UI
↓
ACP
↓
Copilot / Claude / Codex / OpenCode / otros agentesLa evolución de julio y agosto se entiende mejor si la miramos como una expansión de esa abstracción.
Julio: las sesiones dejan de depender de cada CLI
El 10 de julio Microsoft publicó Intelligent Terminal v0.1.1841.
La mejora aparentemente más técnica fue también una de las más importantes a largo plazo: el historial de sesiones empezó a obtenerse directamente desde el agente mediante ACP session/list.
Antes, la terminal tenía que conocer detalles particulares de los distintos CLIs y reconstruir sus historiales.
La arquitectura era parecida a:
Intelligent Terminal
├── parser Copilot
├── parser Codex
├── parser otro CLI
└── lógica específicaEso escala mal.
Si cada nuevo agente necesita una integración especial, el terminal termina acumulando adapters y heurísticas.
Con session/list, la responsabilidad cambia:
Intelligent Terminal
↓
ACP session/list
↓
agente
↓
historial propioLa terminal pregunta.
El agente responde con sus sesiones.
Eso parece una optimización pequeña, pero es exactamente el tipo de desacoplamiento necesario para soportar muchos agentes sin convertir el host en una colección de excepciones.
La misma release añadió F5 para refrescar la lista de sesiones y detectar conversaciones creadas fuera de Intelligent Terminal sin reiniciar la aplicación.
Fuente: Intelligent Terminal v0.1.1841 — GitHub Discussion #402.
Pegar imágenes en el Agent Pane
La release de julio también añadió soporte para pegar imágenes con Alt+V.
Una captura de pantalla puede enviarse al agente como un bloque de imagen ACP.
Esto importa especialmente en debugging.
Un flujo que antes podía ser:
screenshot
↓
guardar archivo
↓
abrir chat externo
↓
subir imagen
↓
explicar contextopuede convertirse en:
terminal
↓
Alt+V
↓
agente recibe screenshotEl soporte final depende de que el agente y el modelo acepten imágenes, pero el terminal ya dispone de la superficie de transporte.
Shell context: el agente empieza a entender dónde está realmente
Otro cambio importante de julio fue mejorar la conciencia del shell activo.
Esto resuelve un problema muy común en asistentes de terminal.
Supongamos que hacemos:
PowerShell
↓
wsl
↓
bash
↓
exit
↓
PowerShellUn agente que sólo observa texto puede quedarse con una idea equivocada del entorno actual y recomendar comandos Bash dentro de PowerShell, o al revés.
Intelligent Terminal añadió mecanismos para reportar mejor la identidad real del shell y reforzó Autofix para inspeccionar el entorno antes de sugerir soluciones.
También empezó a comprobar:
- si un comando existe realmente en
PATH; - si hay scripts locales equivalentes;
- si el usuario simplemente cometió un typo;
- cuál es el working directory efectivo;
- qué shell está activo.
La idea es importante:
un agente de terminal no debería razonar sobre una terminal genérica; debería razonar sobre el proceso concreto que está ejecutándose delante de él.
Agosto: Intelligent Terminal 0.2 cambia de escala
El salto fuerte llegó el 10 de agosto de 2026 con Intelligent Terminal 0.2.
Microsoft lo describió como su mayor release hasta ese momento.
Las cuatro novedades principales fueron:
modelos locales
+ agente diferente por tab
+ OpenCode first-class
+ agentes ejecutándose dentro de WSLCada una resuelve una limitación distinta del modelo original.
Fuente oficial: Microsoft — Intelligent Terminal 0.2 is here with local model support.
Modelos locales: BYOM entra en la terminal
0.2 añadió Bring Your Own Model — BYOM.
El usuario puede configurar un endpoint compatible con la API de OpenAI indicando:
Base URL
+
Model IDEso permite conectar, por ejemplo, un servidor local basado en Ollama.
La arquitectura puede quedar así:
Intelligent Terminal
↓
Agent Pane
↓
Copilot u OpenCode
↓
OpenAI-compatible endpoint
↓
Ollama
↓
modelo localEl cambio tiene varias implicaciones.
Privacidad
El modelo puede ejecutarse en la propia máquina cuando el workflow y el agente lo permiten.
Offline
No todos los flujos necesitan depender permanentemente de un proveedor cloud.
Experimentación
El usuario puede probar modelos diferentes sin que Microsoft tenga que añadir soporte explícito para cada backend.
Coste
El coste deja de ser necesariamente una llamada remota por token y puede desplazarse al hardware local.
La idea encaja perfectamente con la filosofía de Intelligent Terminal: el terminal intenta ser el host; el modelo es intercambiable.
/agent: un agente diferente en cada pestaña
Probablemente la feature más representativa de 0.2 sea /agent.
Cada pestaña puede seleccionar su propio agente sin afectar a las demás.
Por ejemplo:
TAB 1
PowerShell
→ Copilot
TAB 2
Ubuntu / WSL
→ Codex
TAB 3
repo frontend
→ Claude
TAB 4
experimentos locales
→ OpenCode + OllamaEsto cambia la unidad de aislamiento.
Antes era fácil imaginar Intelligent Terminal como:
un terminal
+
un asistenteAhora la arquitectura se acerca a:
un workspace
├── tab → shell + agent
├── tab → shell + agent
├── tab → shell + agent
└── tab → shell + agentLas conversaciones permanecen aisladas por tab.
Eso permite mantener workflows simultáneos sin que cambiar de agente destruya el contexto de las otras pestañas.
La release oficial incluso pone un ejemplo muy explícito: Copilot en una pestaña, Claude en otra y Codex en una tercera.
Esto es exactamente lo que cabría esperar de un multi-agent host.
OpenCode se vuelve un backend de primera clase
OpenCode también entró en el lineup integrado.
Eso significa que ya no tiene que configurarse como un agente custom genérico para las operaciones principales.
Puede utilizarse para:
- chat en el Agent Pane;
- Autofix;
- reanudar sesiones previas;
- aparecer en session management;
- integrarse con tracking hooks.
Este cambio es importante por una razón estratégica.
Microsoft no está diseñando Intelligent Terminal exclusivamente como “la terminal de Copilot”.
Está dejando espacio explícito para otros agentes.
Eso aumenta muchísimo el valor potencial del producto.
Un host cerrado compite con cada agente nuevo.
Un host abierto puede volverse más útil a medida que aparecen agentes nuevos.
El agente puede vivir dentro de WSL
Para muchos desarrolladores de Windows, el entorno real de trabajo no está en Windows.
Está en WSL.
El repositorio puede estar bajo Linux.
Las dependencias están instaladas ahí.
Los paths son Linux.
Las herramientas son Linux.
La versión 0.2 permite configurar el Agent Pane y la delegación ?<prompt> por profile, incluyendo agentes instalados dentro de una distribución WSL.
Esto elimina una fuente enorme de fricción.
Comparemos dos arquitecturas.
Agente en Windows mirando WSL desde fuera
Windows agent
↓
traducción de paths
↓
WSL filesystem
↓
Linux toolsAgente ejecutándose dentro del mismo distro
Ubuntu / WSL
├── repo
├── git
├── python
├── node
├── toolchain
└── agentLa segunda es mucho más natural.
El agente comparte:
- filesystem;
PATH;- working directory;
- comandos;
- configuración;
- herramientas instaladas.
En agentic engineering, reducir esas diferencias de entorno evita una cantidad considerable de errores absurdos.
El Agent Pane deja de parecer una consola secundaria
0.2 también contiene muchas mejoras de UX que juntas son más importantes de lo que parecen.
Por ejemplo:
- mouse scroll y selección;
- doble click para palabra;
- triple click para línea;
- copy Unicode;
- historial de hasta 50 prompts por tab usando
↑y↓; - conservación de drafts y prompts multiline;
- tool calls con estados animados;
- visualización de paths y comandos tocados por el agente;
- status bar con tokens y coste;
- colores adaptados al pane;
- búsqueda dentro de
/sessions; /movepara colocar el Agent Pane arriba, abajo, izquierda o derecha.
Individualmente son detalles.
Colectivamente apuntan a otra cosa:
Microsoft espera que el usuario pase suficiente tiempo dentro del Agent Pane como para que necesite ergonomía de herramienta principal, no de demo.
Autofix también está madurando
Autofix empezó como una idea muy atractiva: detectar que un comando falló y permitir que un agente sugiera una solución.
Pero hacer eso de forma fiable exige interpretar errores de shells muy diferentes.
0.2 mejoró la detección de:
- errores runtime de Windows PowerShell 5.1;
- parser errors de PowerShell;
- ciclos de prompt en Bash;
- command-not-found;
- aliases definidos en profiles;
- scripts locales;
- working directory real;
- herramientas empaquetadas por Windows Terminal.
En otras palabras, Autofix se mueve de:
"vi un error; inventaré una solución plausible"hacia:
"vi un error;
primero inspecciono el entorno;
luego propongo una corrección"Esa diferencia es fundamental para reducir alucinaciones operativas.
Lo que todavía NO está entregado: Durable Sessions
Aquí conviene separar producto publicado de trabajo en desarrollo.
Microsoft ya anunció que quiere llevar Intelligent Terminal hacia Terminal Session Restore.
El PR más interesante ahora mismo es #628 — Durable sessions: save & restore shell sessions across close and crash, abierto el 19 de agosto.
A fecha de este artículo sigue abierto.
El objetivo es persistir en disco información como:
layout de tabs y panes
+ profiles
+ working directories
+ agent bindings
+ scrollback opcional
+ sesión ACP asociadaLa experiencia deseada es muy potente:
trabajo en una tab
↓
cierro ventana / crash
↓
reabro Intelligent Terminal
↓
misma tab
mismos panes
mismos cwd
mismo agente
misma conversaciónEl PR utiliza almacenamiento persistente administrado por wta-master, incluyendo SQLite para el estado de las sesiones y sidecars para buffers.
También introduce /tab-history para buscar, restaurar y eliminar sesiones antiguas.
Esto cambia mucho la naturaleza del producto.
Una terminal tradicional se siente efímera.
Una terminal durable empieza a comportarse como un workspace persistente.
Y cuando además conserva la conversación del agente, la unidad de persistencia deja de ser solamente el shell.
Pasa a ser:
shell + workspace + agent stateEl siguiente paso: mantener incluso los procesos vivos
El propio PR #628 aclara que todavía no incluye toda la ambición de Durable Sessions.
Persistir y reconstruir estado es una cosa.
Mantener el shell realmente ejecutándose después de cerrar la interfaz es otra.
La arquitectura completa que Microsoft está explorando separa ambas piezas:
fase 1
save & restore state
fase 2
keep-running / detachEso podría acercar Intelligent Terminal a experiencias que hoy asociamos con herramientas como tmux, sesiones remotas persistentes o terminal multiplexers, pero integradas con el estado del agente.
Markdown incremental dentro del Agent Pane
Otro PR activo es #639 — Render agent responses as Markdown.
La intención es renderizar las respuestas del agente con estructura Markdown mientras llegan por streaming:
- headings;
- listas;
- bloques de código;
- links;
- syntax highlighting.
Parece una mejora puramente visual.
No lo es del todo.
A medida que el agente devuelve planes, comandos, diffs, explicaciones y reportes más largos, el formato se vuelve parte de la legibilidad operacional.
Un host agéntico necesita representar bien contenido estructurado.
Slash commands anunciados por el propio agente
El PR #623 — Support ACP slash commands apunta a algo todavía más interesante.
Actualmente Intelligent Terminal conoce comandos propios como:
/help
/fix
/model
/agent
/sessionsPero un agente puede tener capacidades que el terminal no conoce de antemano.
Con slash commands anunciados mediante ACP, el agente podría exponer dinámicamente operaciones como:
/plan
/review
/usage
/compactsin que Intelligent Terminal tenga que implementar cada comando como feature propia.
Eso completa mejor la abstracción:
host
↓
ACP capabilities
↓
agente anuncia comandos
↓
UI los presentaEn vez de construir una UI fija para cada agente, el host descubre parte de su superficie de capacidades.
Ésa es una propiedad muy poderosa para un ecosistema abierto.
Acciones deterministas sobre panes
También está abierto #607 — Add deterministic source-pane slash commands.
Aquí el problema es otro.
Un agente puede sugerir un comando, pero ¿en qué pane debe ejecutarse?
Cuando existen múltiples shells simultáneos, confiar simplemente en el foco actual puede ser ambiguo.
El PR trabaja en comandos y acciones dirigidas a un pane concreto, con una identidad estable del pane y tarjetas de acción que pueden ofrecer opciones como:
Run
Insert
AdjustEso acerca el sistema a una separación más segura entre:
agente propone acción
↓
terminal sabe el target exacto
↓
usuario aprueba / modifica
↓
ejecuciónEn agentic systems, identificar explícitamente el target es mucho mejor que depender de contexto implícito.
La arquitectura que empieza a emerger
Si juntamos todas estas piezas, Intelligent Terminal empieza a dibujar una arquitectura bastante distinta a la de un terminal clásico.
┌────────────────────────────────────────┐
│ Intelligent Terminal │
│ │
│ Tab A │
│ ├── PowerShell │
│ └── Copilot │
│ │
│ Tab B │
│ ├── Ubuntu / WSL │
│ └── Codex │
│ │
│ Tab C │
│ ├── repo experimental │
│ └── OpenCode → Ollama local │
│ │
│ Shared capabilities │
│ ├── ACP │
│ ├── session management │
│ ├── terminal actions │
│ ├── pane targeting │
│ └── durable session store │
└────────────────────────────────────────┘Eso ya no es simplemente “IA integrada en Terminal”.
Es una plataforma que intenta coordinar agentes, shells, sesiones y entornos de ejecución.
Por qué ACP puede ser la parte más importante
Es fácil fijarse en las features visibles —Ollama, /agent, WSL— y perder de vista la pieza que las conecta.
ACP permite que Intelligent Terminal trate al agente como una capacidad externa con contratos definidos.
Eso habilita progresivamente cosas como:
session/list
session/load
slash commands
image content
model switching
agent-specific capabilitiesLa dirección es parecida a lo que MCP hizo para tools, pero aplicada al vínculo entre host y agente.
Y esa separación tiene una consecuencia estratégica.
Si el protocolo funciona bien, Microsoft no necesita ganar la carrera de “mejor agente”.
Intelligent Terminal puede ganar valor simplemente por ser un lugar excelente donde muchos agentes distintos pueden trabajar.
De shell a workspace agent-first
Durante décadas, una terminal tuvo una responsabilidad muy concreta:
usuario escribe comando
↓
shell ejecuta
↓
terminal muestra outputLos agentes añaden una nueva capa:
usuario expresa intención
↓
agente interpreta
↓
inspecciona shell / repo / contexto
↓
propone o ejecuta acciones
↓
terminal representa y controla
↓
shell ejecutaEso convierte a la terminal en algo más parecido a un control plane local para trabajo de desarrollo.
No significa que el shell desaparezca.
Ocurre lo contrario.
El shell se vuelve la superficie determinista debajo del agente.
El agente puede razonar.
Pero los comandos, procesos, paths y resultados continúan siendo reales y observables.
Esa combinación es particularmente atractiva para ingeniería de software:
LLM probabilístico
↓
acciones explícitas
↓
shell determinista
↓
resultado observableEl riesgo: demasiada autonomía demasiado pronto
La dirección también tiene riesgos.
Cuanto más cerca está el agente del shell, mayor es su radio potencial de acción.
Un chatbot equivocado produce una mala respuesta.
Un agente de terminal equivocado puede producir:
rm
checkout
push
install
kill
terraform apply
kubectl deletePor eso son importantes detalles como:
- tarjetas de acción;
- target de pane explícito;
- visibilidad de tool calls;
- paths y comandos visibles;
- aislamiento por tab;
- sesiones recuperables;
- separación entre sugerir e ejecutar.
La terminal puede convertirse en un gran host para agentes precisamente porque ya es un lugar donde las acciones son explícitas y auditables.
Pero esa ventaja desaparece si la UI oculta lo que realmente está ejecutándose.
En dos meses, el proyecto cambió de categoría
La evolución puede resumirse así.
Junio
Windows Terminal
+
Agent PaneJulio
Agent Pane
+
ACP session history
+
image paste
+
shell-aware context
+
PATH-aware AutofixAgosto — 0.2
multi-agent por tab
+
local models
+
OpenCode
+
WSL-native agents
+
richer agent UI
+
usage / cost visibilityTrabajo activo
durable sessions
+
agent session restore
+
Markdown streaming
+
ACP dynamic commands
+
deterministic pane actionsLa tendencia es bastante clara.
Microsoft no está limitándose a añadir más prompts al terminal.
Está construyendo infraestructura para que el terminal pueda alojar agentes diferentes, preservar su contexto y conectarlos de forma segura con shells reales.
Conclusión
Intelligent Terminal sigue siendo experimental.
No conviene confundir PRs abiertos con funcionalidades terminadas ni asumir que toda la arquitectura actual llegará intacta a una versión estable.
Pero la velocidad de iteración de julio y agosto de 2026 permite ver una dirección muy interesante.
La idea inicial era:
terminal + IALa arquitectura que empieza a aparecer es más rica:
workspace
↓
terminal panes
↓
agentes intercambiables
↓
ACP
↓
modelos cloud o locales
↓
acciones sobre entornos reales
↓
sesiones persistentesSi Durable Sessions y las superficies ACP siguen avanzando, Intelligent Terminal podría convertirse en algo más importante que una variante de Windows Terminal.
Podría convertirse en una shell diseñada desde el principio para una época donde el usuario ya no ejecuta todo el trabajo directamente, sino que coordina agentes que trabajan junto a él.
Y ahí está la señal más interesante del proyecto.
El futuro del terminal quizá no sea esconder la línea de comandos detrás de la IA.
Puede ser exactamente lo contrario:
usar la línea de comandos como el sustrato verificable donde múltiples agentes pueden trabajar sin perder de vista qué está ocurriendo realmente.
Fuentes
- Microsoft Windows Command Line — Intelligent Terminal 0.2 is here with local model support
- Microsoft / GitHub — Intelligent Terminal v0.2.2192, Discussion #590
- Microsoft / GitHub — Intelligent Terminal v0.1.1841, Discussion #402
- Microsoft / GitHub — microsoft/intelligent-terminal
- Microsoft / GitHub — PR #628: Durable sessions
- Microsoft / GitHub — PR #639: Render agent responses as Markdown
- Microsoft / GitHub — PR #623: Support ACP slash commands
- Microsoft / GitHub — PR #607: deterministic source-pane slash commands