Le pides a Hermes que mire la página que acabas de capturar y responde “el botón de la derecha está cortado”. Quieres volver a señalarlo y comprobarlo, así que levantas la vista y no hay ninguna imagen en pantalla. Solo una ruta: /tmp/screenshot-2026-11-05.png. Abres el gestor de archivos, doble clic, esperas al visor, vuelves al terminal. Dos viajes de ida y vuelta después, el hilo de lo que estabas pensando ya se perdió.

Ese bucle se cerró. Un cambio fusionado el 4 de noviembre hace que Hermes dibuje las imágenes directamente en la CLI clásica y en la TUI: las imágenes que adjuntas aparecen debajo de tu mensaje, y las que produjo una tool aparecen debajo de la línea de esa tool.

Antes era una ruta; ahora es la imagen

Se cubren dos casos:

• Imágenes que adjuntas — vía /paste, /image o arrastrando un archivo al terminal — se dibujan debajo de la fila de tu mensaje.
• Imágenes locales que una tool produjo o miró — una entrada de vision_analyze, un resultado de image_generate, una captura del navegador o de computer-use — se dibujan debajo de la línea de esa tool.

Hay dos cosas que deliberadamente no aparecen, y saberlo te ahorra una búsqueda en soporte: read_file no puede leer imágenes, así que no dibuja nada; y las URL de imágenes remotas nunca se descargan — solo se renderizan archivos locales.

Un ajuste, cinco niveles

Vive en config.yaml bajo display, y por defecto es auto:

display:
  inline_images: auto   # auto | kitty | iterm | unicode | off

Qué significa cada nivel:

• auto dibuja imágenes a resolución completa en kitty y Ghostty (protocolo gráfico de kitty con placeholders Unicode) tanto en la CLI como en la TUI, y en la CLI clásica además usa el protocolo de imagen inline de iTerm2 para pintar sobre filas reservadas en iTerm2, WezTerm y Konsole. Todo lo demás — tmux, GNU screen, sesiones SSH dentro de VS Code y la TUI en cualquier sitio fuera de kitty/Ghostty — recibe medio bloques en truecolor: dos caracteres de media altura por cada celda de píxel coloreada.
• kitty fuerza el protocolo de kitty. La razón habitual es la CLI clásica dentro de tmux con set -g allow-passthrough on.
• iterm fuerza el protocolo de iTerm2 en la CLI clásica; la TUI vuelve a auto en este nivel.
• unicode usa siempre medio bloques.
• off muestra solo rutas de archivo, exactamente como antes.

Una tabla se escanea más rápido:

Terminal	Qué te da auto
kitty / Ghostty	resolución completa (CLI y TUI)
iTerm2 / WezTerm / Konsole	resolución completa (solo CLI clásica)
terminal de VS Code (soporte de imágenes activado)	resolución completa (solo CLI clásica)
tmux / GNU screen / SSH dentro de VS Code	medio bloques en truecolor
cualquier otra cosa, terminales sixel incluidas	medio bloques en truecolor

A VS Code se le pregunta una vez, al arrancar

El terminal integrado de VS Code puede mostrar imágenes reales, pero solo cuando terminal.integrated.enableImages está activado. Hermes no tenía forma de saberlo, así que siempre iba sobre seguro con bloques.

Ahora la CLI clásica sondea VS Code exactamente una vez por arranque: envía una consulta XTSMGRAPHICS delimitada por DA1, en la ventana previa a que prompt_toolkit se haga con el tty. Solo el addon de imágenes de VS Code responde a esa consulta, así que una respuesta significa que las imágenes están activadas. La respuesta se cachea; el sondeo se omite sobre Remote-SSH, en Windows y cuando no hay tty. Si resulta que las imágenes están desactivadas, más o menos uno de cada cinco arranques Hermes cambia su tip aleatorio por una línea que nombra el ajuste — no en todos los arranques.

Por qué tantos terminales solo reciben bloques de color

La razón es mecánica. Un renderer que compone línea a línea puede medir de forma fiable dos formas de imagen: los placeholders Unicode de kitty, donde la imagen ocupa celdas de la rejilla y el número de filas es conocido, y los medio bloques en truecolor, donde dos caracteres forman una celda de píxel. El protocolo de iTerm2 pinta sobre un número de filas reservadas que nadie contó, y por eso aparece en la CLI clásica y no en la TUI.

La misma restricción explica que tmux y GNU screen acaben en medio bloques: pueden tragarse o reescribir los escapes de gráficos en passthrough salvo que permitas el passthrough explícitamente y fijes el nivel kitty.

Qué pasa cuando redimensionas

La CLI redibuja su transcripción cuando cambia el tamaño del terminal. Las imágenes de kitty y los medio bloques vuelven en ese redibujado. Las imágenes dibujadas con el protocolo de iTerm2 dejan filas en blanco en la pantalla redibujada y solo siguen visibles en el scrollback de arriba. Es una diferencia de protocolo, no una función rota — vale la pena saberlo antes de abrir un bug.

Qué imágenes se dibujan y cuáles se quedan calladas

La ruta de imágenes de tools solo mira campos con nombre: image_url, url, path, image_path, screenshot_path, leyendo el resultado antes que los argumentos. Así que un listado de search_files lleno de rutas PNG no va a convertir tu terminal en un álbum de fotos.

Las previsualizaciones PNG demasiado grandes se rechazan antes de que nada las decodifique — una frontera deliberada para que una sola imagen enorme no pueda atascar el terminal.

Dibujar es renderizado local. La imagen iba a llegar al modelo de todas formas como adjunto o como resultado de una tool; esta capa añade píxeles a tu pantalla, no tokens a la petición.

¿Se puede usar ya?

El trabajo se fusionó en main el 4 de noviembre, después del punto de release v0.22.7 (3 de noviembre), así que todavía no está en una release — a día de hoy vive solo en main. Ejecuta desde el código fuente si lo quieres ahora, o espera a la próxima versión.

Si te interesa la otra mitad de la imagen — cómo se entiende una imagen y cuánto cuesta en contexto — el post sobre el presupuesto de contexto de imágenes y la guía de enrutado de visión de imágenes lo cubren. Este cambio va de verla. Si vives en el teclado, la guía de la paleta de comandos es la lectura vecina, y una instalación nueva empieza en la página de instalación.