DeepSeek Harness Desktop: análisis de su app

Contexto en ArceApps: ya expliqué la arquitectura de DeepSeek Harness y publiqué una comparativa con OpenCode, Codex y Claude Code. Este artículo no repite esos análisis: estudia la experiencia Desktop, sus decisiones operativas, la seguridad y cuándo merece la pena utilizarla.

Una aplicación no convierte automáticamente un harness en producto

Un harness de agentes puede ser técnicamente magnífico y seguir siendo una herramienta que no apetece abrir un martes cualquiera. Instalar dependencias, elegir perfiles, comprobar el sandbox, buscar la sesión correcta, recuperar una ejecución interrumpida y recordar qué plugin añadimos son tareas pequeñas, pero repetidas. Para quien desarrolla sus propias aplicaciones en ratos libres, esa fricción cuenta tanto como el rendimiento del modelo.

La aparición del cliente de escritorio oficial de DeepSeek Harness cambia la pregunta. Ya no basta con saber si la arquitectura «everything is a plugin» es elegante. Hay que preguntar qué ocurre al abrir una app, elegir un proyecto, entregar una tarea y volver después a comprobar el trabajo. ¿El runtime se mantiene vivo? ¿La ventana controla realmente los procesos? ¿Qué sale de nuestro ordenador? ¿Puede cambiar un plugin de confianza sin que nos demos cuenta?

El anuncio de finales de septiembre provocó precisamente esas conversaciones en r/LocalLLaMA. Algunos usuarios apreciaban la interfaz; otros reclamaban un paquete oficial para Linux y varios advertían de la velocidad de cambios incompatibles. Son testimonios interesantes, no un benchmark ni una auditoría. Mi objetivo aquí es separar lo que declara el código público, lo que cuentan sus usuarios y lo que todavía deberíamos medir nosotros.

Qué es Desktop y qué conserva de la versión web

DeepSeek Harness, conocido como dsh, es un runtime abierto construido alrededor de Cordis: las capacidades se registran como plugins y el agente se compone con esos servicios. El modelo, las herramientas, la persistencia, el bucle de ejecución y partes de la interfaz pueden evolucionar por separado. Es una idea distinta de instalar una colección de extensiones encima de un asistente monolítico; en este caso la extensibilidad afecta al esqueleto del sistema.

El cliente Desktop no es otro motor de agentes. Según su README oficial, es una envoltura Electron de la aplicación Web completa. Inicia un proceso hijo de Node que levanta el Host, carga la interfaz empaquetada y coordina su estado mediante IPC. El Host escucha por defecto en un puerto asignado por el sistema, ligado a la dirección local 127.0.0.1. Eso evita competir directamente con el puerto habitual de la variante web, el 3080.

Este detalle tiene dos consecuencias prácticas. Primera: la interfaz puede parecer una aplicación normal y seguir dependiendo de un servicio local vivo. Segunda: «tener una app» no significa que todos los datos permanezcan aislados de servicios externos. La inferencia depende del proveedor de modelos elegido, los plugins pueden comunicarse por red y el propio cliente tiene mecanismos de telemetría. La frontera de privacidad se define en la configuración y en el comportamiento de las herramientas, no en el icono del escritorio.

Lo que sí cambió con la distribución de escritorio

La página oficial ofrece descargas para macOS en Apple Silicon y Windows de 64 bits. Linux no figura entre las descargas oficiales de Desktop de esa página; eso no impide utilizar la interfaz web ni compilar y experimentar con el código, pero conviene no confundir ambas vías. El producto continúa presentándose como public preview y el repositorio advierte expresamente de posibles cambios incompatibles.

En un agente, distribuir una aplicación supone resolver bastantes asuntos poco vistosos: iniciar el Host, ofrecer un selector nativo de directorios, localizar el runtime empaquetado, gestionar las actualizaciones, proteger credenciales entre procesos y decidir qué significa cerrar la ventana. El README de Desktop dedica secciones enteras a esas decisiones. No es necesariamente una garantía de ausencia de errores, pero sí indica que el equipo está abordando problemas de producto y no solo añadiendo un botón bonito delante de un terminal.

Hay un riesgo habitual al evaluar software tan reciente: mezclar versiones del cliente, del runtime y de los plugins. Dos capturas realizadas en semanas distintas pueden corresponder a combinaciones diferentes. Por eso evitaría afirmar que «la versión 0.x soporta exactamente…» sin congelar versión y fecha del binario evaluado. Las funcionalidades que menciono son las documentadas a 10 de octubre de 2026; para instalar o diagnosticar problemas, hay que comprobar el estado real del repositorio en ese momento.

Instalación: dos caminos razonables, no uno universal

Para una primera evaluación en Windows o macOS usaría los instaladores enlazados desde el sitio oficial. Antes de ejecutar nada, verificaría que el dominio y el fichero son los esperados, revisaría los permisos solicitados y reservaría un directorio de proyecto de prueba sin secretos. No desactivaría defensas del sistema solo porque una guía informal lo recomiende: una advertencia de firma o de reputación requiere verificar origen y versión.

Para Linux o para quien prefiera un proceso transparente, la documentación del repositorio muestra esta entrada web:

npx @deepseek-ai/dsh web

Con Node.js disponible, el comando inicia normalmente la UI en http://127.0.0.1:3080. Puede omitirse la apertura automática con la opción documentada —no-open. El repositorio también permite clonar el código, instalar dependencias con pnpm, compilar y ejecutar pnpm dsh web. Estas variantes son más fáciles de integrar en un host propio, pero trasladan al usuario la responsabilidad de mantener el proceso y sus dependencias.

Hay una distinción útil: la descarga de escritorio resuelve comodidad de entrada; la versión web aporta una separación explícita entre interfaz y Host. No afirmaría que una sea «más segura» en abstracto. La seguridad depende de dónde escucha el servicio, quién puede conectarse, qué autenticación existe, qué plugins se cargan y bajo qué permisos se ejecutan.

La primera sesión: configurar menos, observar más

Antes de poner el agente sobre un repositorio importante, haría una prueba mínima. Crear un proyecto temporal, abrirlo como workspace, configurar un modelo autorizado y pedir una tarea inocua: enumerar archivos, leer un README e indicar un plan sin modificar nada. Después pediría una edición pequeña en una copia desechable y revisaría el diff antes de aceptarla. Ese ritual mide cuatro cosas a la vez: acceso al directorio, comprensión del contexto, comportamiento de las herramientas y trazabilidad de resultados.

La elección del proveedor no es un detalle menor. El sistema distingue entre el runtime y la capa de modelos; conectar una API externa puede implicar costes y transferencia de contexto al proveedor. No daría por supuesto que instalar el cliente regala inferencia ilimitada ni que usar un modelo local elimina todos los canales de salida: los plugins de búsqueda, navegación, estadísticas o actualización tienen vida propia.

También comprobaría dónde almacena sesiones, preferencias y credenciales la versión instalada, y qué ocurre al cambiar el workspace. Un fallo frecuente de los agentes no es ejecutar mal un comando, sino ejecutarlo en el proyecto equivocado. Antes de habilitar cambios automáticos conviene hacer visible el directorio de trabajo, la identidad del proveedor, el modo activo y los permisos. Un botón de ejecutar que oculta esos cuatro datos es más una trampa de UX que una mejora de productividad.

Plugins: la característica poderosa también es la superficie de ataque

«Everything is a plugin» deja de ser un lema atractivo cuando un plugin tiene acceso al sistema de archivos, a la terminal o a la red. En la práctica, un plugin de un agente puede ser código ejecutable cargado dentro de su proceso. La interfaz de plugins permite instalar bundles, activarlos y desactivarlos y consultar su configuración, según la documentación del gestor.

Esto es mucho más flexible que una lista fija de herramientas, pero exige un modelo de confianza explícito. Un plugin puede contener instrucciones equivocadas, depender de paquetes comprometidos, registrar un gancho sobre la ejecución o cambiar de comportamiento tras actualizarse. La capacidad de habilitarlo no equivale a haberlo auditado. Tampoco basta con que el proyecto matriz tenga licencia abierta: hay que revisar el código y las dependencias del componente concreto.

Mi criterio para un proyecto personal sería conservador: comenzar con el conjunto oficial mínimo; documentar para qué sirve cada extensión adicional; fijar versiones cuando el ecosistema aún rompe compatibilidad; hacer un inventario de permisos y probar las actualizaciones primero en un repositorio desechable. Cuantas menos extensiones sean imprescindibles para una tarea, más fácil resultará reproducir un fallo. La libertad arquitectónica solo ayuda si todavía podemos explicar qué piezas estaban cargadas cuando el agente tomó una decisión.

Creator mode: construir herramientas sin convertir la conversación en autoridad

Creator mode permite pedir al agente que produzca y monte capacidades nuevas. En la página oficial aparece un ejemplo de un temporizador Pomodoro, con inspección de servicios del runtime y creación de archivos de plugin. El flujo es sugerente: describir un comportamiento, generar el componente, probarlo y conservarlo como parte del entorno. Para un indie dev puede reducir la barrera de entrada a pequeñas automatizaciones que antes no compensaba programar.

Pero conviene distinguir generar un plugin de validarlo. Un archivo JavaScript o TypeScript escrito por el propio agente no debería ganar privilegios elevados solo porque el mismo agente diga que funciona. La revisión humana sigue siendo el punto de control, especialmente si el plugin manipula credenciales, llamadas de red o comandos de shell.

Un experimento acotado sería desarrollar un plugin sin acceso a secretos que formatee un resumen de los cambios de Git. La especificación inicial debe indicar qué datos lee, qué produce, qué nunca modifica y cómo se prueba. El contrato puede ser tan sencillo como «lee el diff, genera Markdown, no hace push, no cambia archivos». Después se verifica el código generado, se prueba sobre un repositorio de juguete y se comprueba que desactivar el plugin realmente devuelve el sistema al estado previo. Esa secuencia encaja mejor con SDD ligero que con el clásico «hazlo todo y dime cuando acabes».

Automatización: cerrar la ventana no es apagar el agente

Uno de los comportamientos más relevantes está documentado en el ciclo de vida de Desktop. Cerrar la ventana principal puede ocultarla mientras el Host sigue funcionando, de modo que tareas activas continúen. En Windows interviene la bandeja del sistema; en macOS la aplicación puede permanecer accesible desde el Dock. Cerrar la ventana, minimizarla y salir de la aplicación no son operaciones idénticas.

El README distingue además las tareas de ejecución de los recordatorios programados. En el diseño descrito, las tareas de calendario requieren que la función esté activada y que las sesiones pertinentes sigan cargadas; un cierre completo de la aplicación puede impedir que esos recordatorios se ejecuten. Esa diferencia es decisiva si alguien piensa usar Desktop como sustituto de un servicio permanente.

Para un agente 24/7 en un mini PC Linux, seguiría prefiriendo un proceso supervisado por el sistema operativo y una interfaz cliente separada. Para automatizaciones personales que ejecutamos mientras trabajamos, Desktop puede ser suficiente. Pero habría que hacer una prueba controlada: iniciar una tarea inocua de duración conocida, ocultar la ventana, comprobar el resultado, repetir con salida explícita y documentar diferencias. No doy esa prueba por realizada aquí; describo el protocolo necesario para decidirlo con datos.

Observabilidad: el valor de poder explicar el camino

Los agentes no fallan solo devolviendo una respuesta equivocada. También pueden elegir una herramienta inapropiada, ejecutar pasos redundantes, crear un fichero válido en la ruta errónea o agotar presupuesto sin llegar a comprobar nada. La página oficial enseña una vista de trayectorias con llamadas a herramientas, tiempos y detalles de ejecución. Ese tipo de instrumentación es especialmente valioso cuando hay plugins que cambian el bucle del agente.

La primera pregunta ante un resultado extraño debería ser «¿qué observó y qué ejecutó?» y no «¿qué prompt mágico debo añadir?». Una traza útil permite reconstruir orden, entradas, herramientas, errores y revisiones del propio agente. Sin embargo, una pantalla de trazas no sustituye a logs exportables ni a contratos de prueba automatizados: si mañana cambia un plugin, necesitamos comparar el mismo escenario con dos versiones, no confiar en recuerdos de una sesión.

Un test reproducible puede consistir en corregir una prueba que falla deliberadamente. Conservamos un commit inicial, lanzamos la misma tarea con configuración documentada, registramos herramientas invocadas y diff final, y ejecutamos CI. Si el agente termina declarando «resuelto» pero los tests siguen rojos, la conclusión es clara. La observabilidad sirve para descubrir por qué llegó a esa conclusión, no para otorgarle credibilidad por defecto.

Seguridad: permisos, sandbox y riesgo de código de terceros

Un harness extensible obliga a delimitar tres niveles de confianza: el usuario que define el objetivo; el modelo que propone acciones a partir de información potencialmente no confiable; y los plugins que transforman esas propuestas en operaciones reales. Los documentos que lee el agente también pueden contener instrucciones maliciosas. Una cadena de texto procedente de una página web no debería poder ampliar permisos ni ordenar que se publique un secreto.

Mi recomendación para el primer uso es aislamiento práctico, no teatral: workspace sin secretos, API keys con alcance mínimo, git limpio, permisos de escritura concedidos solo cuando hagan falta y revisión antes de operaciones destructivas. No activaría ejecución desatendida sobre el repositorio principal hasta haber probado recuperación tras errores, política de confirmaciones y manejo de symlinks, archivos ignorados y rutas externas.

El riesgo no desaparece porque haya un modo de «autorrevisión». La propia extensibilidad de Cordis permite interponer código en el ciclo de ejecución; hay discusiones públicas sobre el alcance de las garantías de algunos mecanismos de revisión. Eso no demuestra que la distribución por defecto sea vulnerable a un ataque concreto, pero sí obliga a separar la seguridad del runtime, la del plugin y la del sistema operativo. El principio práctico es sencillo: un agente nunca debería tener más permisos que los estrictamente necesarios para su tarea.

Privacidad: «local» no significa automáticamente «sin telemetría»

Este es un apartado que echo de menos en muchas reseñas. El código de Desktop ejecuta su Host en el propio ordenador, pero el módulo oficial de product analytics explica que el cliente Desktop envía por defecto determinados eventos de producto mediante su exportador OTel, mientras que la interfaz Web ordinaria no monta esa misma recolección. El ajuste enabled existe en la configuración de Cordis y por defecto vale true; la documentación indica que no hay un control visible para el usuario en la interfaz.

El documento identifica campos habituales como ID de dispositivo, ID de usuario, versión del sistema operativo y versión de la aplicación. También afirma que claves API, tokens de cuenta, prompts y respuestas no forman parte de esos eventos. Eso es más preciso que decir «espía todo» o «no recoge nada». Desactivar la entrada de nuevos eventos tampoco borra necesariamente lo que ya estuviera en la cola del exportador.

Hay al menos otras dos vías de datos que evaluar por separado: las peticiones al proveedor de inferencia y las llamadas de herramientas a servicios externos. Si el artículo alimenta una decisión sobre privacidad, yo comprobaría versión, configuración efectiva, destinos de red y comportamiento real con consentimiento y herramientas de observación apropiadas. No he inspeccionado tráfico de una instalación real aquí y no sería honesto presentarlo como una auditoría independiente.

Costes y límites: qué conviene presupuestar

La descarga de una aplicación no revela el coste completo de un agente. Hay modelos de facturación por tokens, servicios de búsqueda, extensiones con suscripciones y, en el caso de modelos locales, hardware y energía. El harness también tiene coste propio: cada llamada de herramienta, cada relectura de un archivo y cada subagente pueden aumentar el número de tokens procesados o el tiempo hasta obtener una respuesta comprobable.

La comparación razonable utiliza un lote fijo de tareas, el mismo proveedor cuando sea posible y presupuestos equivalentes de permisos, herramientas y contexto. Si cambiamos simultáneamente de modelo, harness y prompt, un resultado mejor no permite atribuir la diferencia a Desktop. Tampoco extrapolaría el ahorro de una demo a una semana de mantenimiento de código sin registrar intentos fallidos, correcciones humanas y ejecuciones descartadas.

En un proyecto pequeño, mediría cinco cosas: tareas aceptadas sin retoques, minutos de revisión, llamadas de modelo, reintentos por error y cambios imprevistos fuera del alcance pedido. Incluiría el coste de evaluar plugins nuevos y reparar compatibilidades. Puede que una interfaz agradable ahorre varios minutos por sesión; puede también que una actualización rompa una extensión y consuma una tarde entera. Ambos forman parte del coste real.

Linux remoto y Windows como cliente: una alternativa concreta

Hay un escenario muy natural para quien tiene un mini PC Linux encendido y desarrolla desde un portátil Windows. La versión Web puede vivir en el servidor, mientras el navegador del portátil actúa como interfaz. La documentación muestra que dsh web escucha normalmente en localhost:3080. Un túnel SSH permite abrir ese servicio sin publicarlo directamente en la LAN ni en Internet:

# En el mini PC: iniciar la interfaz web
npx @deepseek-ai/dsh web --no-open

# En el portátil: túnel cifrado hacia el Host local
ssh -L 3080:127.0.0.1:3080 usuario@mini-pc

Después se abre http://127.0.0.1:3080 en el portátil. Este ejemplo presupone que SSH ya está configurado, que el puerto local está libre y que el proceso remoto permanece activo. No resuelve por sí solo el control de acceso a otras herramientas, la gestión de claves, el reinicio del servicio o las políticas de red; son decisiones adicionales.

La virtud de este enfoque es la claridad: el Host y sus permisos residen en Linux y la interfaz es un cliente. Desktop, en cambio, está pensado para iniciar su propio Host local y no lo describiría como un cliente remoto intercambiable sin comprobarlo. Para un entorno multiplataforma, la UI web probablemente sea la referencia más universal hoy, precisamente porque no obliga a equiparar las capacidades de todos los empaquetados.

Cómo lo integraría en un flujo SDD ligero

Imaginemos una feature de un juego indie: añadir un modo de alto contraste. No necesitamos veinte documentos ni un ejército de agentes. Necesitamos un objetivo observable, un límite de alcance, un plan corto y una definición de terminado. El agente puede ayudar a descubrir componentes reutilizables, pero antes debe leer la implementación existente y los workflows de CI. La secuencia es importante porque reduce la probabilidad de inventar una arquitectura paralela.

Un contrato mínimo podría ser: «el modo usa los tokens de color existentes; respeta preferencia del usuario; cubre navegación con teclado; añade test de persistencia; no cambia rutas públicas ni analítica». En Desktop abriríamos el workspace, pediríamos un inventario de los archivos relevantes, revisaríamos el plan, ejecutaríamos cambios por pasos y utilizaríamos Git para examinar el resultado. Los plugins de automatización no deberían saltarse las condiciones de revisión humana para un push o una publicación.

La diferencia entre SDD y delegación ciega se ve al terminar. No basta con que el agente haya editado CSS y declare completado. Hay que comprobar contraste, responsive, pruebas de regresión y diff. Si CI ya cubre parte de esas condiciones, se aprovecha; si no, se añade una comprobación recurrente solo cuando aporta valor real. El harness ejecuta, pero las garantías proceden del contrato de trabajo y de la verificación.

Protocolo de evaluación: cómo compararlo sin autoengañarnos

Si quisiera decidir entre Desktop, la Web UI y un agente de terminal, prepararía un repositorio pequeño reproducible con tres commits de partida y cinco tareas: localizar un bug, corregir una prueba, añadir una función acotada, refactorizar sin modificar comportamiento y documentar una decisión arquitectónica. Cada tarea tendría resultado esperado, tests de aceptación y archivos que no pueden cambiarse.

Congelaría versiones de runtime y plugins; registraría modelo, temperatura si es configurable, presupuesto, permisos y duración. Cada agente ejecutaría los mismos escenarios desde el mismo commit limpio. No compararía una ejecución privilegiada con otra que debe pedir permiso cada vez. Al final mediría resultado comprobado por tests, diff fuera de alcance, tiempo de revisión humana, coste y tasa de recuperación tras interrupciones.

El resultado se publicaría aunque el producto que más me guste perdiera alguna prueba. Esa es la única forma útil de hablar de «mejor harness». Las capturas bonitas, las estrellas de GitHub y los comentarios entusiasmados de Reddit indican interés, pero no dicen cuántos fallos evita una herramienta ni cuánta atención exige. Hoy no incluyo puntuaciones de esa batería porque no la he ejecutado; describir un benchmark imaginario como propio sería peor que no ofrecer ninguno.

Cinco puntos que conviene comprobar antes de adoptarlo

1. Versiones y compatibilidad. El repositorio avisa de cambios incompatibles durante la preview. Si dependes de un plugin comunitario, anota la versión con la que lo validaste y guarda un camino de vuelta. «Se actualiza solo» no es una ventaja cuando desconocemos qué contrato cambió.

2. Control de permisos. Asegura que el workspace no permite escribir o ejecutar fuera de las rutas necesarias. Lo que la interfaz llama «aprobación» merece una prueba práctica de denegación: pedir una acción no autorizada y observar que realmente se bloquea.

3. Estado persistente. Reinicia la aplicación, vuelve a abrir la sesión y comprueba qué recupera: mensajes, tarea pendiente, herramientas y archivos. Una sesión recuperada parcialmente puede llevar a decisiones equivocadas si el agente cree conservar contexto que ya no tiene.

4. Actualizaciones y cierre. Distingue ocultar la ventana, detener una tarea, cerrar el Host y apagar la máquina. Para automaciones con horario estricto, la semántica de procesos importa más que el aspecto del panel.

5. Modelo de datos. Decide qué proveedores recibirán contexto, qué plugins tienen red y cómo se configura la telemetría. Documenta esas elecciones junto con la lista de plugins. Una arquitectura «local-first» tiene valor solo si podemos demostrar sus límites.

Preguntas frecuentes

¿Es DeepSeek Harness Desktop un sustituto de OpenCode?

No de forma automática. Ambos pueden ayudar a programar, pero el modelo de extensibilidad, la interfaz, las superficies de autorización y la madurez operativa no son idénticos. Desktop puede resultar más cómodo para tareas mixtas de documentos, investigación y desarrollo; OpenCode conserva ventajas de un ecosistema familiar para muchos usuarios del terminal. La elección merece pruebas equivalentes, no una competición de eslóganes.

¿Hay aplicación oficial para Linux?

La página de descarga consultada lista macOS Apple Silicon y Windows 64-bit. Para Linux está documentada la UI web desde Node.js y la opción de trabajar desde el código. Eso no autoriza a llamar oficial a cualquier paquete comunitario de escritorio. Conviene identificar quién mantiene cada binario y su procedimiento de actualización.

¿Puedo dejar automatizaciones programadas mientras el equipo duerme?

No debería asumirse. Las tareas necesitan un proceso vivo y, según el tipo, una sesión cargada. El README distingue cerrar ventana de salir de la aplicación; si el ordenador se suspende o se apaga no hay garantía de ejecución puntual. Para tareas críticas, utiliza una infraestructura supervisada y monitorizada.

¿Todo permanece en mi ordenador?

No necesariamente. El Host puede ejecutarse localmente, pero un proveedor remoto procesa peticiones y determinados plugins acceden a la red. Además, la documentación de Desktop describe telemetría de producto activada por defecto. Hay que separar los datos de sesión, los datos enviados al modelo y los eventos del cliente antes de sacar conclusiones sobre privacidad.

Balance final: menos fricción, no menos responsabilidad

La aportación interesante de DeepSeek Harness Desktop no es que convierta un modelo en «autónomo» ni que garantice mejores resultados. Es que intenta hacer utilizable en el día a día una infraestructura de agentes muy flexible. Abrir un workspace, inspeccionar plugins, seguir una traza y crear herramientas propias desde una interfaz coherente puede ser una mejora tangible de experiencia.

También coloca bajo una luz más clara sus riesgos: plugins que ejecutan código, compatibilidad cambiante, automatizaciones dependientes del proceso, diferencias entre Web y Desktop y telemetría que merece configuración explícita. En una fase de preview prefiero una herramienta que exhiba sus límites a otra que promete resolverlo todo. Mi veredicto es probarlo en un proyecto acotado, registrar lo aprendido y no convertirlo todavía en pieza irremplazable de una publicación o entrega.

Al final, sigo volviendo a la misma regla: el mejor harness es el que permite reproducir lo que hizo, corregirlo cuando se equivoca y apagarlo sin perder el control del proyecto. Que ahora podamos hacerlo desde una ventana nativa es una noticia; que podamos confiar en ello será una conclusión que habrá que demostrar.

Bibliografía y referencias

• DeepSeek Harness: sitio oficial y descargas — disponibilidad del producto, preview y capacidades declaradas.
• Repositorio principal de DeepSeek Harness — arquitectura, licencia, acceso por Web UI y advertencia de compatibilidad.
• README oficial de Desktop — Electron, ciclo de vida del Host, ventanas, procesos y actualizaciones.
• Gestor de plugins — bundles y configuración.
• Product analytics del cliente — política documentada de telemetría Desktop.
• Debate sobre el lanzamiento en r/LocalLLaMA — experiencias y preguntas de usuarios, no pruebas independientes.
• Debate sobre cambios del runtime en octubre — contexto comunitario de evolución.
• Artículo anterior de arquitectura en ArceApps y comparativa de harnesses — antecedentes y diferencias de enfoque.

Fuentes consultadas el 10 de octubre de 2026. Este texto es un análisis de documentación y experiencias públicas, no una prueba empírica del cliente instalada en un equipo propio.