Pulsas enviar y te vas al navegador a buscar algo. La ventana de Hermes se queda en segundo plano, haciendo streaming de su respuesta carácter a carácter. Veinte minutos después cierras la tapa, desenchufas y te vas. Cuando vuelves, la batería ha caído más de lo que debería y el ventilador estaba claramente trabajando mientras no estabas.

Una ventana oculta no debería funcionar así. Nadie la está mirando, y aun así repintaba cada carácter a velocidad de primer plano.

El comportamiento anterior: una conversación en streaming, todas las ventanas despiertas

En la implementación anterior, el estado “una conversación está en streaming” mantenía despierta por completo a cada ventana del desktop: el bucle de pintado seguía corriendo, y las páginas de preview también se mantenían despiertas, para que la captura de automatización y anotación estuviera siempre lista.

Con una ventana era invisible. Con varias ventanas, turnos largos y la batería de un portátil, era un coste constante en segundo plano.

La mitad de las previews era más sutil: incluso una página completamente inactiva nunca entraba en el throttling de fondo de Chromium, porque la anotación o la automatización podían necesitarla en cualquier momento.

Ahora: el pintado sigue a la visibilidad

El pintado del streaming se acota a dos ventanas: las visibles y la única ventana que tiene su propia conversación de voz en vivo (esa sigue despierta aunque esté oculta, porque la voz la necesita). Todo lo demás — incluidas las ventanas hermanas minimizadas — puede hacer throttling.

Fíjate en lo que esto no es: “Leer las respuestas en voz alta” ya no le compra a cada ventana una exención de vigilia. Antes implicaba que cada ventana tenía que quedarse despierta para leer su contenido; ahora las ventanas minimizadas siguen con throttling y el progreso completado más la respuesta final se leen en voz alta exactamente una vez.

Al mismo tiempo, las cosas que no deben depender del dibujado se desacoplaron de los frames de animación: la entrega del stream, Stop, el journaling de turnos y la recuperación de crashes funcionan sin ellos. Restaurar una ventana muestra el último estado en vez de reproducir una cola de pintados.

Las actualizaciones de texto parcial se agrupan. El progreso completado y las respuestas finales se publican sin esperar al siguiente frame — por eso una ventana oculta puede seguir leyendo en voz alta, una vez. Cuando dos ventanas tienen respuestas a la vez, comparten la propiedad del turno pendiente, así que la narración ni se pierde ni se dice dos veces.

Páginas de preview: inactivo significa inactivo

El segundo cambio va de la preview integrada: una página inactiva ahora puede usar el throttling de fondo propio de Chromium en lugar de mantener una vigilia para sí misma.

La página invitada y la ventana que la posee se despiertan solo para trabajo real, y la vigilia se mantiene por operación. Las operaciones solapadas conservan cada una su propia retención, así que terminar una no puede suspender otra. Después de una navegación la vigilia se vuelve a aplicar incluso cuando una operación existente aún no ha despachado otro script.

Varios bordes afilados se cerraron al mismo tiempo:

• El trabajo abandonado por una navegación confirmada se cancela, mientras que los valores de retorno de scripts, el consentimiento de plugins, la entrada confiable, el sandboxing y la CSP se mantienen intactos.
• La espera del pintado de anotación y la captura de imagen comparten un único plazo cancelable de ocho segundos. Esperar la siguiente anotación del usuario no mantiene nada despierto.
• Las instalaciones de anotación en cola y el teardown se delimitan por sesión, así que una cancelación no puede dejar atrás un bloqueador de clics invisible ni quitar un overlay de reemplazo.
• Los scripts de plugins conservan su semántica de finalización existente: su retención de vigilia dura hasta el asentamiento o la cancelación, incluso para una promesa que nunca se resuelve. Los scripts de plugins y las acciones de escritura largas no heredan el plazo de captura.

Sin dependencias nuevas, sin permisos nuevos ni cambios de CSP, y no se truncó nada en la transcripción ni en el scrollback.

Cómo verlo tú mismo

La ruta de aceptación es deliberadamente manual:

1. Abre la misma conversación en dos ventanas, minimiza una, haz streaming de una respuesta larga. Escribe en la ventana visible y luego restaura la otra — ambas deberían mostrar la respuesta completa.
2. Pulsa Stop en la ventana visible. La salida cancelada no debe reanudarse al restaurar la otra.
3. Activa “Leer las respuestas en voz alta” en ambas ventanas: las minimizadas siguen con throttling, pero el progreso completado y la respuesta final se leen igualmente una vez.
4. Empieza una conversación de voz en una sola ventana: el streaming en la otra no debe interrumpir su captura ni su reproducción.
5. Recarga durante el streaming: la recuperación conserva el último texto, incluida la cola silenciosa después de que el proveedor deje de enviar.

Cuándo lo vas a notar de verdad

Tres situaciones: un portátil dejado vigilando una tarea larga, quien mantiene la misma conversación abierta en dos o tres ventanas para comparar, y quien lee documentación en la preview integrada mientras la anota.

No hará tu modelo más rápido ni tus respuestas más cortas. Solo deja callarse a las ventanas que nadie está mirando.

¿Se puede usar ya?

Ambos cambios se fusionaron en main el 4 de noviembre, después del punto de release v0.22.7 — así que a día de hoy no están en una release; el post de v0.22.7 cubre lo que sí salió. La latencia de escritura del desktop tiene su propio análisis, y si lo que de verdad te importa es que te avisen cuando algo te necesita, la guía de atención y notificaciones es el extremo receptor.