Letzte Woche hast du auf einem Flug ein ganzes Modul mit einem lokal gehosteten Qwen fertiggestellt, durchgehend offline, und es fühlte sich großartig an. Am Montag öffnest du die Webapp, um weiterzumachen, und bekommst den vertrauten Willkommensbildschirm: „Let’s get you setup…“, mit zwei Schaltflächen darunter – Nous Portal und I have an API key.

Dein erster Gedanke war „meine Session ist abgelaufen“, also hast du dich neu angemeldet, einen Schlüssel eingefügt und zehn Minuten verbrannt. In Wahrheit war mit deinem Konto nichts falsch. Der lokale Modellserver lief einfach nicht – die Desktop-App stoppt ihn beim Beenden, oder er lud noch ein Modell. Die alte Oberfläche hielt „das Modell ließ sich nicht auflösen“ und „nichts ist konfiguriert“ für dasselbe und schickte dich zum Einloggen.

Das ist jetzt behoben, und der Fix lohnt einen Blick: Es wurde kein Satz umgeschrieben, sondern „welcher Fehler ist das“ in ein strukturiertes Feld verwandelt.

Ein Fehler im Gewand eines anderen

So hat sich der alte Build selbst in die Ecke manövriert.

Wenn das Hauptmodell die von Hermes verwaltete lokale Runtime (llama.cpp) ist und dieser Server aus ist, antwortet setup.runtime_check im Gateway mit ok: false, während setup.status weiterhin sagt, es sei ein Provider konfiguriert. Beide Aussagen stimmen, aber das Onboarding-Gate des Renderers (refreshOnboarding) las nur die erste: Es behandelte jedes ok: false als „nichts konfiguriert“ und öffnete das Provider-Anmelde-Overlay.

Dann kam die zweite Hälfte. Wenn du all das ignoriert und trotzdem eine Nachricht geschickt hast, stempelte das Gateway den Auflösungsfehler als auth_permanent (ein dauerhafter Authentifizierungsfehler) ab, und das Frontend zeigte dir eine Karte „API-Schlüssel aktualisieren“. Ein reines „Server läuft nicht“-Problem wurde als „dein Schlüssel ist kaputt“ verkleidet.

Eine Klarstellung, weil das oft falsch gelesen wird: Die Webapp-Authentifizierung war die ganze Zeit in Ordnung; der Reauth-Pfad in browser-transport.ts war nie beteiligt. Was du gesehen hast, war das Provider-Onboarding-Overlay, das zufällig einen Satz über das lokale Modell enthält und deshalb wie ein Login-Bildschirm aussieht.

Der neue Fehlercode: local_runtime_unavailable

Der Kern des Fixes ist die Trennung der beiden Fehler:

• Eine nicht verfügbare lokale Runtime wirft eine neue benannte Exception, LocalRuntimeUnavailableError (eine Unterklasse von ValueError, damit bestehende Aufrufer sie weiter fangen), mit dem strukturierten Code local_runtime_unavailable.
• Die Variante „eingeschaltet, aber noch nicht ausliefernd“ ist als retryable markiert. Diese Unterscheidung zählt: Ein Modell braucht eine Weile zum Laden, und dir in diesen Sekunden einen Modellwechsel zu empfehlen wäre ein schlechter Rat.
• setup.runtime_check legt error_code über einen gemeinsamen Helper in seine Antwort. Wichtig: Es ist ein strukturiertes Feld, kein String, auf den das Frontend matcht – Text ändert sich, Felder nicht.

Die beiden Zustände sagen jetzt Unterschiedliches:

• Startet noch: „Der lokale Modellserver läuft nicht. Möglicherweise startet er noch – versuch es gleich noch einmal oder wechsle mit /model zu einem anderen Modell.“
• Definitiv aus: „Der lokale Modellserver ist ausgeschaltet. Starte ihn in der Hermes-Desktop-App oder über hermes model → Local models, oder wechsle mit /model zu einem anderen Modell.“

Desktop und Webapp bekommen unterschiedliche nächste Schritte

Dieses Detail verdient Anerkennung: Der Fix zeigte nicht faul beiden Oberflächen denselben Hinweis.

Wo du bist	Was du siehst	Was du tun kannst
Desktop	Die App öffnet normal (configured: true) mit einem Hinweis „Lokales Modell nicht verfügbar“	Local models öffnen, direkt in diesen Einstellungsbereich
Webapp	Die App öffnet normal, mit einem Hinweis, dass das lokale Modell nicht verfügbar ist	Anderes Modell wählen (die Webapp hat keinen Local-models-Bereich – der existiert nur in Electron)

Warum nicht auch in der Webapp „Local-models-Bereich öffnen“ anbieten? Weil dieser Bereich im Browser nicht existiert und eine Schaltfläche, die nicht funktionieren kann, schlechter ist als keine. Der Text der Webapp erwähnt ihn deshalb bewusst nicht und bietet stattdessen einen Modellwechsel an.

Auch die Fehlerkarte im Chat hat sich geändert

Ein Turn, der so scheitert, trägt jetzt failure_reason=local_runtime_unavailable bis in die Oberfläche, und der Titel der Karte wechselt von „dein API-Schlüssel wurde abgelehnt“ zu „Dein Modellserver ist nicht erreichbar“, mit zwei Aktionen:

• Erneut versuchen – richtig, solange der Server noch startet;
• Provider wechseln – schneller, wenn er schlicht nicht läuft.

Auch ein Satz, den nur ein Ingenieur lieben konnte, ist verschwunden: Der alte Build hängte „setup.status reports configured credentials, but runtime resolution still failed“ an. Der neue lässt diesen Jargon weg, wenn es einen Code zu melden gibt.

Wann du weiterhin zum Login geschickt wirst

Der Fix schiebt nicht alles auf die lokale Runtime, und das ist wichtig – sonst würde er echte Credential-Probleme verstecken. Den Onboarding-Pfad bekommst du weiterhin, wenn:

• es überhaupt keine brauchbaren Credentials gibt (nicht bei Nous angemeldet, kein Schlüssel konfiguriert);
• der Provider ein Cloud-Provider ist und sein Schlüssel tatsächlich ungültig ist.

Anders gesagt: Du bleibst nur dann vom Login fern, wenn der Fehler der lokalen Runtime zuzuordnen ist.

Selbst debuggen

Wenn dein lokales Modell plötzlich nicht mehr arbeitet, gehe in dieser Reihenfolge vor:

1. Prüfen, ob der Server läuft. Desktop: Einstellungen → Providers → Local Models und schauen, ob das Modell als laufend angezeigt wird; wenn es installiert, aber gestoppt ist, starten. Im Terminal: hermes model → Local models listet den Katalog, startet den Server und macht das Modell zu deinem Standard.
2. „Nicht gestartet“ von „lädt noch“ unterscheiden. In den ersten fünfzehn Sekunden nach dem Start wandern die Gewichte noch in den VRAM, ein erneuter Versuch ist also das Richtige. Wenn eine Minute vergeht, schau in die Logs.
3. Modell wechseln und weiterarbeiten. /model wechselt innerhalb der Session zu einem anderen konfigurierten Provider; beachte, dass ein Wechsel mitten in der Session den Prompt-Cache ungültig macht, was bei einem langen Gespräch nicht kostenlos ist.
4. Nicht nach einem Bereich suchen, den es nicht gibt. Wenn du in der Webapp keine Local-Models-Einstellungen findest, ist das korrekt – die gibt es nur im Desktop. Wechsle aus der Webapp das Modell oder geh zurück in die Desktop-App und starte den Server.

Kannst du es heute schon nutzen

Der Fix ist am 2026-10-30 auf main gelandet (PR #146883, Label type/bug, P2) und mit v0.22.6 (2026-11-02) in ein Release gekommen – danach wird ein gestoppter lokaler Server als nicht erreichbar gemeldet, statt dich zum Login-Bildschirm zu schicken.

Wenn Hermes dich auf diesem Build plötzlich bittet, dich anzumelden, fang nicht an, dich neu zu authentifizieren: Prüf zuerst, ob der lokale Modellserver läuft. Diese eine Prüfung spart zehn Minuten und verhindert, dass du auf einer Offline-Maschine wiederholt versuchst, dich anzumelden.

Zwei andere Ecken lokaler Modelle haben wir schon behandelt: wie Hermes llama.cpp für dich hostet und wie du erkennst, was deine GPU tatsächlich stemmt. Dieser Artikel ist der dritte: was die Oberfläche dir eigentlich sagt, wenn etwas kaputtgeht.