La semana pasada terminaste un módulo entero en un vuelo con un Qwen alojado en local, sin conexión todo el rato, y fue genial. El lunes abriste la Webapp para seguir y te recibió la pantalla de bienvenida de siempre: «Vamos a configurarte…», con dos botones debajo: Nous Portal y Tengo una clave de API.

Tu primer pensamiento fue «se me ha caducado la sesión», así que volviste a iniciar sesión, pegaste una clave y perdiste diez minutos. La verdad es que no había nada malo en tu cuenta. El servidor de modelos locales simplemente no estaba en marcha: la app de escritorio lo detiene al cerrarse, o todavía estaba cargando un modelo. La interfaz antigua trataba «no se pudo resolver el modelo» y «no hay nada configurado» como lo mismo, y te mandaba a iniciar sesión.

Eso ya está arreglado, y el arreglo merece un vistazo: no reescribió una frase, convirtió «¿qué fallo es este?» en un campo estructurado.

Un error disfrazado de otro error

Así se metió en un callejón sin salida la compilación antigua.

Cuando el modelo principal es el runtime local gestionado por Hermes (llama.cpp) y ese servidor está caído, el setup.runtime_check del gateway responde ok: false mientras setup.status sigue diciendo que hay un proveedor configurado. Ambas afirmaciones son ciertas, pero la compuerta de incorporación del renderer (refreshOnboarding) solo leía la primera: trataba cualquier ok: false como «nada configurado» y abría la capa de inicio de sesión del proveedor.

Luego venía la segunda mitad. Si ignorabas todo eso y enviabas un mensaje de todos modos, el gateway marcaba el fallo de resolución como auth_permanent (un fallo de autenticación permanente), así que el front end te mostraba una tarjeta de «Actualizar clave de API». Un problema puro de «el servidor no está en marcha» quedaba disfrazado de «tu clave está rota».

Una aclaración, porque es una lectura equivocada habitual: la autenticación de la Webapp estaba sana todo el tiempo; la ruta de reautenticación de browser-transport.ts nunca entró en juego. Lo que veías era la capa de incorporación de proveedores, que da la casualidad de que contiene una frase sobre el modelo local y por eso parece una pantalla de inicio de sesión.

El nuevo código de error: local_runtime_unavailable

El núcleo del arreglo es separar los dos fallos:

• Un runtime local no disponible lanza una nueva excepción con nombre, LocalRuntimeUnavailableError (subclase de ValueError, así que quienes ya la capturaban siguen capturándola), que lleva el código estructurado local_runtime_unavailable.
• La variante «encendido pero todavía no sirviendo» se marca como reintentable. Esa distinción importa: un modelo tarda un rato en cargar, y decirte que cambies de modelo durante esos segundos es un mal consejo.
• setup.runtime_check incluye error_code en su respuesta mediante un único ayudante compartido. Ojo: es un campo estructurado, no una cadena contra la que haga coincidencias el front end; los textos cambian, los campos no.

Los dos estados ahora dicen cosas distintas:

• Todavía arrancando: «El servidor de modelos locales no está en marcha. Puede que aún se esté iniciando: inténtalo de nuevo en un momento o cambia a otro modelo con /model.»
• Definitivamente apagado: «El servidor de modelos locales está apagado. Inícialo desde la app de escritorio de Hermes o desde hermes model → Modelos locales, o cambia a otro modelo con /model.»

Escritorio y Webapp reciben siguientes pasos distintos

Este detalle merece reconocimiento: el arreglo no se limitó a mostrar la misma pista en ambas superficies.

Dónde estás	Qué ves	Qué puedes hacer
Escritorio	La app se abre con normalidad (configured: true) con un aviso «Modelo local no disponible»	Abrir modelos locales, directamente en ese panel de ajustes
Webapp	La app se abre con normalidad, con un aviso de que el modelo local no está disponible	Elegir otro modelo (la Webapp no tiene panel de modelos locales: ese panel es solo de Electron)

¿Por qué no ofrecer «abrir el panel de modelos locales» en la Webapp? Porque ese panel no existe en un navegador, y un botón que no puede funcionar es peor que ningún botón. Así que el texto de la Webapp deliberadamente no lo menciona y ofrece un cambio de modelo en su lugar.

La tarjeta de fallo del chat también cambió

Un turno que falla así ahora lleva failure_reason=local_runtime_unavailable hasta la interfaz, y el título de la tarjeta pasa de «tu clave de API fue rechazada» a «No se puede conectar con tu servidor de modelos», con dos acciones:

• Reintentar: correcto mientras el servidor aún se está iniciando;
• Cambiar de proveedor: más rápido cuando simplemente no está en marcha.

También desapareció una frase que solo un ingeniero podría querer: la compilación antigua añadía «setup.status informa de credenciales configuradas, pero la resolución del runtime sigue fallando». La nueva compilación elimina esa jerga cuando hay un código que informar.

Cuándo te siguen mandando a iniciar sesión

El arreglo no culpa de todo al runtime local, y eso importa: de lo contrario ocultaría problemas reales de credenciales. Sigues llegando a la ruta de incorporación cuando:

• no hay credenciales utilizables en absoluto (no has iniciado sesión en Nous, no hay clave configurada);
• el proveedor es de nube y su clave realmente no es válida.

En otras palabras: solo te mantienen fuera del inicio de sesión cuando el fallo puede atribuirse al runtime local.

Depurarlo tú mismo

Si tu modelo local deja de funcionar de repente, ve en este orden:

1. Comprueba si el servidor está en marcha. Escritorio: Ajustes → Proveedores → Modelos locales, y mira si el modelo aparece como en ejecución; si está instalado pero detenido, inícialo. Desde un terminal: hermes model → Modelos locales lista el catálogo, arranca el servidor y convierte el modelo en tu predeterminado.
2. Distingue «no iniciado» de «aún cargando». En los primeros quince segundos después de pulsar iniciar, los pesos todavía están pasando a la VRAM, así que reintentar es lo correcto. Si pasa un minuto, mira los logs.
3. Cambia de modelo y sigue trabajando. /model cambia a otro proveedor configurado dentro de la sesión; ten en cuenta que un cambio a mitad de sesión invalida la caché de prompt, lo que no sale gratis en una conversación larga.
4. No busques un panel que no existe. Si no encuentras los ajustes de Modelos locales en la Webapp, es lo correcto: son solo de escritorio. Desde la Webapp, cambia de modelo o vuelve a la app de escritorio y arranca el servidor.

¿Puedes usarlo ya?

El arreglo llegó a main el 2026-10-30 (PR #146883, etiquetado type/bug, P2) y ya está en la v0.22.6 (2026-11-02): con esa versión, un servidor local detenido se reporta como no disponible en vez de mandarte a la pantalla de inicio de sesión.

En esa compilación, cuando Hermes te pida de repente iniciar sesión, no empieces a reautenticarte: comprueba primero si el servidor de modelos locales está en marcha. Esa comprobación te ahorra diez minutos y evita que intentes iniciar sesión una y otra vez en una máquina sin conexión.

Hemos cubierto otros dos rincones de los modelos locales: cómo aloja Hermes llama.cpp por ti y cómo saber qué puede ejecutar realmente tu GPU. Este artículo es el tercero: qué te está diciendo realmente la interfaz cuando algo se rompe.