Der Export der Einstellungen scheiterte mit "HTTP 500" — dahinter steckt
UPnP-Fehler 866: die Box will die Aktion zusaetzlich am Geraet bestaetigt.
- _tr064 meldet jetzt den UPnP-Fehlercode statt nur "HTTP 500".
- 866 → ohne button_wait sofort zurueck mit needs_button (ARIA fragt Stefan,
ob er an der Box steht). Mit button_wait=true: X_AVM-DE_Auth SetConfig
(start), GetState alle 2 s bis FB_BUTTON_WAIT_SEC (120 s); "authenticated"
→ Aktion erneut, sonst Timeout "Taste nicht gedrueckt, nichts ausgefuehrt"
(Bestaetigung wird gestoppt).
- fritzbox.backup: X_AVM-DE_GetConfigFile mit Kennwort (Standard: Login-
Kennwort), Download mit Digest-Auth, Kopie auf dem Satelliten (die
letzten 10 je Box) und Datei zurueck an ARIA.
- Brain: Datei aus dem Ergebnis landet in /shared/uploads/, ARIA legt sie
mit [FILE: …] in den Chat; Timeout 200 s bei button_wait; Beschreibung
erklaert den Tasten-Ablauf.
Getestet gegen nachgebaute Box: ohne Bestaetigung → needs_button, Taste
nach 3 s → Sicherung geladen, keine Taste → Timeout. Gegen eine echte Box
(X_AVM-DE_Auth-Ablauf) noch nicht.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Auf ARIAs VM fand der neue Satellit 58 Geraete, darunter die Container der
Docker-Netze (docker0/br-*/veth) — die sind keine Geraete und fallen jetzt
aus der ARP-Liste. Die FRITZ!Box 5590 kam per SSDP als 'media-renderer';
InternetGatewayDevice / FRITZ!Box heisst jetzt type 'router'.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Statt einzelner fest programmierter Befehle nutzt der Satellit die
Selbstbeschreibung der Box (tr64desc.xml + SCPD je Dienst, ohne Anmeldung
lesbar): was DIESE Firmware kann, steht dort — keine Tabellen pro Modell.
- fritzbox.describe: alle TR-064-Aktionen der Box, je mit [liest]/
[aendert]/[GEFAEHRLICH]; filter grenzt ein (WLAN, Dect, Hosts …).
- fritzbox.call: beliebige Aktion (service kurz "WLANConfiguration:3",
args ohne "New"-Praefix moeglich). Alles ausser Get… braucht
confirmed=true, sonst needs_confirmation — ARIA muss vorher fragen.
- fritzbox.wlan: alle WLANs inkl. Gast (index/ssid/an), schalten mit
index + enable (+ confirmed).
- FritzBox per Geraetename ("Fritzbox Keller") statt IP ansprechbar.
- Allowlist kennt Platzhalter "fritzbox.*" (Default + .env.example).
- Brain: Tool-Beschreibung mit Ablauf (describe → call) und Freigabe-Regel,
fritzbox.* mit 60 s Timeout.
Getestet gegen eine nachgebaute TR-064-Box: describe/filter, lesen,
schreiben ohne/mit Freigabe (ohne kommt nichts an der Box an), WLAN
schalten, Namensaufloesung, Allowlist.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ARIA konnte "an welchem Port der FritzBox Keller haengt X" nicht
beantworten: fritzbox.hosts warf alles ausser Name/IP/MAC/aktiv weg. Die
Host-Liste der Box (TR-064 X_AVM-DE_GetHostListPath) enthaelt je nach
FRITZ!OS auch InterfaceType, X_AVM-DE_Port, X_AVM-DE_Speed und
X_AVM-DE_Guest — die gehen jetzt als interface, lan_port, speed_mbit,
guest mit. params.find filtert nach Name/IP/MAC. Hinweis im Ergebnis:
lan_port ist die Buchse DIESER Box (hinter Switch/Repeater dessen Port).
Tool-Beschreibung im Brain nennt die neuen Felder.
Getestet mit nachgebauter AVM-Host-Liste; gegen eine echte Box noch nicht.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Das Zugangsdaten-Formular war beim erneuten Oeffnen leer, obwohl der
Satellit alles gespeichert hatte.
Satellit:
- sat_creds_list mit ip liefert je Typ die Felder ohne Geheimnisse
(Benutzer, Port, SNMP-Version/v3-Stufe) und has_<feld> fuer Passwoerter;
mit reveal (nur zusammen mit ip) auch die Geheimnisse dieses Geraets.
- sat_creds_set behaelt ein gespeichertes Geheimnis, wenn das Feld nicht
mitgeschickt wird — Benutzer aendern, ohne das Passwort neu zu tippen.
Diagnostic-Server: Antworten mit Klartext (revealed) gehen nur an den
Browser, der gefragt hat, nicht an alle offenen Tabs.
Formular: Benutzer/Port/Version stehen beim Oeffnen drin, Passwoerter als
"•••••• gespeichert"; 👁 holt sie im Klartext bzw. schaltet um. Leeres
Passwortfeld = gespeichertes behalten. FritzBox: "Benutzer ermitteln"
(nur bei als FritzBox erkannten Geraeten) liest login_sid.lua?version=2 —
die Box nennt ihre Benutzer ohne Anmeldung; eingetragen wird der zuletzt
angemeldete.
Getestet: Satelliten-Logik per Unit-Test, Formular in headless Chromium
(Anzeige, Speichern ohne Passwort, Auge, Benutzer ermitteln).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Kam sat_discover, waehrend schon ein Scan lief (z.B. der erste nach dem
Start, ~25 s), wartete der Satellit nur 6 s und lieferte die bisherige
Liste — nach einem Neustart leer → "Keine Geraete gefunden". Jetzt wartet
er, bis der laufende Scan fertig ist (hoechstens SCAN_MAX_SEC).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Jeder ServiceBrowser ist ein eigener Thread; zc.close() beendet ihn nicht
(zeroconf 0.151.5, lokal nachgestellt: +1 Thread pro Browser und Scan,
mit cancel() keiner). Bei 14 Diensttypen und einem Scan alle 5 Minuten
hatte der Satellit HomeOffice nach ~5 Tagen 18.841 Threads = Thread-Limit
des Containers. Seit 30.10. 12:19 scheiterte jeder Scan mit "[Errno 11]
Resource temporarily unavailable", auf sat_discover kam keine Antwort mehr
(auch die RVS-Verbindung brach zeitweise mit Errno 11 ab).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Der Satellit HomeOffice war verbunden (Heartbeat lief), beantwortete
sat_discover aber nicht mehr — auch ein zweiter Scan blieb ohne Antwort.
Ursache: Nachrichten werden nacheinander abgearbeitet (async for … await
_handle), und der Scan lief im Loop. Haengt ein Schritt (mDNS/SSDP/ARP/SNMP/
ADB), steht der ganze Satellit — Tunnel und Befehle eingeschlossen.
- sat_discover laeuft als eigener Task, der Loop bleibt frei.
- Ein Scan ist auf SCAN_MAX_SEC (90 s) begrenzt; danach kommt die letzte
bekannte Liste zurueck, und das Log nennt den haengenden Schritt.
- Diagnostic: "Scanne Netz …" endet nach 2 Minuten mit einem Hinweis statt
fuer immer.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Das Info-Zeichen ℹ erschien je nach Schrift als nacktes "i" und gelb wie
eine Warnung. Jetzt grau mit "Hinweis:". Prozent, GB und MB/s mit Komma
wie im Rest der Seite.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Seit "erst waehlen, dann Laden" zeigte die Kontext-Liste fuer ein noch
nicht geladenes Modell nur feste Stufen — ohne Maximum und ohne
Speicherbedarf. Jetzt:
- llm-adapter: disk.models[].profiles — pro heruntergeladener
Quantisierung Maximum (context_length) und GB je Stufe aus dem Kopf der
GGUF (gleiche Rechnung wie fuer die geladene Karte, Annahme: alles auf
der Karte). Gesplittete Modelle ausgenommen.
- Diagnostic (Karte + Katalog-Spalte): Stufen bis zum Maximum, "(Maximum)"
markiert, GB je Stufe, "⚠ passt nicht" bzw. bei MoE "⚠ nur mit
Aufteilen". Nicht heruntergeladen: feste Stufen + Hinweis im Tooltip.
Katalog rechnet mit der gewaehlten Ziel-Karte.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Katalog: "Laden" heisst jetzt "Download + Laden", daneben "Nur downloaden":
das Modell kommt auf die Platte der Box (aus der Ziel-Karten-Auswahl), in
keine Karte. Liegt es schon dort, ein Hinweis statt Download.
llm-adapter: llm_provision_model mit downloadOnly → _download_only:
Dateiliste, Plattenpruefung, paralleler Download (strict: ohne Fallback auf
llama.cpp, jeder Fehler kommt als Grund zurueck), keine Karte, keine
Registry. Download-Fenster: "Heruntergeladen — liegt auf der Box".
Karten-Modellwahl: Haken "nur heruntergeladene" in der Liste, Standard an.
Zeigt nur, was schon auf dieser Box liegt; "— leer —" und die aktuelle
Auswahl bleiben immer sichtbar. Meldet die Box keine Platte (alter
Adapter), ist der Haken aus und gesperrt.
Getestet: download-only gegen HuggingFace (tiny-llamas) und mit falschem
Repo; Haken/Suche/Knoepfe in headless Chromium mit der echten Seite.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
LLM-Karten: Modell-Auswahl und Kontext-Dropdown laden nicht mehr sofort.
Die Zeile zeigt die Auswahl, daneben "Laden" (bzw. "Leeren") und "✕" zum
Verwerfen; erst "Laden" fragt nach (MoE-Aufteilung, Ersetzen) und laedt
mit genau diesem Kontext — vorher lud man zweimal (Modell, dann neuer
Kontext). Fuer ein noch nicht geladenes Modell zeigt der Kontext feste
Stufen ohne GB, die Schaetzung kennt die Box erst nach dem ersten Laden.
Die Auswahl ueberlebt das Neuzeichnen durch worker_update.
Modell-Katalog: neue Spalte "Kontext" hinter der Ziel-Karte; Ziel und
Kontext bleiben beim Neuzeichnen erhalten. Neuzeichnen nach Fokusverlust
300 ms spaeter, damit ein Klick auf "Laden" nicht ins Leere geht.
Getestet in headless Chromium mit der echten Seite: waehlen → kein Senden,
Kontext waehlen, Neuzeichnen, Laden → genau ein provision mit dem Kontext,
Verwerfen, Katalog mit Kontext.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Die Box meldet bei jedem Download-Fortschritt ihre Netzwerkkarten (echte
Karten, die "up" sind) mit Tempo. Der Container sieht nur sein eigenes
eth0, darum liest er das /sys des Rechners (neu: /sys:/hostsys:ro im
llm-adapter). Das Download-Fenster zeigt pro Download z.B.
"🔌 enp5s0 100 Mbit/s (max. ~12 MB/s — Kabel/Port prüfen)" — orange unter
1 Gbit/s. Anlass: ki-box hing an einem 100-Mbit-Port, 8 Verbindungen
brachten darum nichts.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Alle 43 confirm(), 7 prompt() und 71 alert() der Diagnostic laufen jetzt
ueber uiConfirm/uiPrompt/uiAlert — gleicher Stil wie der Aufteilen-Dialog:
erster Absatz als Ueberschrift, Rest als Erklaerung, Esc/Klick daneben =
Abbrechen, Enter = OK. Rueckfragen zu Loeschen/Entfernen/Zuruecksetzen
bekommen einen roten "Ja, ausfuehren"-Knopf. Nebenbei faellt die Browser-
Sperre "weitere Dialoge verhindern" weg, an der runDiskCleanup frueher hing.
Die 16 Funktionen, die noch nicht async waren, sind es jetzt (alles
onclick/onchange-Handler, kein Aufrufer nutzt einen Rueckgabewert).
Getestet in headless Chromium: OK/Abbrechen/Esc/Enter, Eingabe, Hinweis.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
llm-adapter:
- Paralleler Download: llama.cpp zieht ueber EINE Verbindung (oft 1-50 MB/s,
auch bei 1 Gbit). Die Box holt fehlende Dateien jetzt vorher selbst in
64-MB-Stuecken ueber LLM_DOWNLOAD_CONNECTIONS (Standard 8) Verbindungen,
prueft die sha256 und legt sie im HF-Cache-Layout ab, das llama.cpp selbst
benutzt (blobs/<sha256>, snapshots/<commit>/<datei>, refs/main). Die Karte
bleibt waehrenddessen beim alten Modell. Scheitert es, laedt llama.cpp wie
bisher selbst. Fortschritt zaehlt bei sparse-Dateien nur geschriebene Bytes.
- Abbrechen: llm_remove_model mit cancel=true (kein neuer Typ → RVS-Allow-List
unveraendert). Waehrend des Downloads: Stopp + halbe Datei weg, Karte
unveraendert. Waehrend llama.cpp laedt: wie ein Fehlschlag → Karte zurueck.
Laeuft nichts mehr, schliesst die Antwort den haengenden Eintrag.
- Loeschen: llm_remove_model mit deleteFiles=true entfernt das Repo aus dem
Cache — nicht, solange es auf einer Karte liegt oder geladen wird.
- worker_hello meldet "disk": freier Platz + heruntergeladene Modelle je Repo.
Diagnostic: Abbrechen-Knopf je laufendem Download; im Katalog "auf ki-box ·
18,6 GB" mit Loeschen-Knopf und eine Zeile mit dem freien Platz je Box.
Getestet gegen HuggingFace (ggml-org/tiny-llamas, 4 Verbindungen, 2-MB-
Stuecke: Layout + Pruefsumme + Abbruch) und Loeschen inkl. Sperren.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
llm-adapter: Vor jeder Aenderung an Registry/Belegung rechnet die Box aus,
was vom Modell noch fehlt (fertige Blobs zaehlen nicht), und vergleicht es
mit dem freien Platz minus Puffer (LLM_DISK_RESERVE_GB, Standard 2). Reicht
es nicht, werden halbe Downloads, an denen seit 30 min niemand schreibt,
geloescht und neu gerechnet; reicht es dann immer noch nicht, bricht das
Laden mit klarer Meldung im Download-Fenster ab ("braucht ca. X GB, frei
sind Y GB"). Frueher brach llama.cpp mitten im Download ab, und der Grund
kam ueber llama-swap nicht an.
Diagnostic: Die MoE-Frage war ein confirm(), bei dem "Abbrechen" "ganz auf
die Karte laden" hiess. Jetzt ein Dialog mit drei Knoepfen: Aufteilen
(empfohlen) / Ganz auf die Karte / Abbrechen (laedt nichts). Esc und Klick
daneben brechen ab.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Statt Suchfeld neben einem normalen Dropdown (Tippen → Liste oeffnen →
passt nicht → zurueck ins Feld) oeffnet ein Klick jetzt eine Liste mit dem
Suchfeld oben. Tippen filtert sofort, Auswahl per Klick oder Pfeiltasten +
Enter, Esc / Klick daneben / Scrollen schliesst. Das versteckte <select>
haelt weiter Wert und onchange (onLlmCardSelect unveraendert).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Modell-Katalog: Suchfeld (erscheint, sobald die Liste geladen ist),
Teilsuche ueber Name, Beschreibung, Repo und Quantisierung; mehrere
Woerter muessen alle vorkommen.
- LLM-Karten: Suchfeld ueber jedem Modell-Dropdown blendet nicht passende
Modelle aus; "— leer —" und das geladene Modell bleiben sichtbar.
- Fix: Ein offenes Karten-Dropdown klappte nach ein paar Sekunden zu, weil
jedes worker_update die Liste neu zeichnete. Solange ein Dropdown oder
Suchfeld darin den Fokus hat, wird das Neuzeichnen aufgeschoben und beim
Verlassen nachgeholt (gilt auch fuer die Ziel-Karte im Katalog).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
29.10., 06:40: Claudes Anmeldung war kurz abgelaufen; die CLI lieferte
"Failed to authenticate: OAuth session expired …" mit is_error=true als
Text. Das Brain hat das als ARIAs Antwort gespeichert (nur der
Sicherheitsfilter wurde bisher abgefangen) — dieselbe Klasse Fehler, die
schon einmal einen Chat vergiftet hat.
Jetzt: is_error ohne Sicherheitsfilter wird wie eine Ausnahme behandelt —
klar markierter [Fehler: …]-Eintrag statt einer scheinbaren Antwort.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude Code liefert in result.result nur den LETZTEN Textblock eines Turns.
Am 28.10. hat ARIA in einem 2-Stunden-Turn ihren Bericht geschrieben, danach
noch auf Laeufe gewartet und mit einer kurzen Notiz geendet — beim Brain kam
nur die Notiz an ("…steht im Bericht oben"), der Bericht war weg.
- Nicht-Streaming: alle Textbloecke des Turns sammeln; laengere fruehere
(>= 300 Zeichen, z.B. Berichte) kommen vor die letzte Antwort. Kurze
Zwischensaetze bleiben weg, <voice> nur aus der letzten Antwort.
- Belegprotokoll speichert jetzt auch Texte (geschwaerzt, max. 20k je
Block), damit so etwas wiederherstellbar ist.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
28.10., 17:51:42: alle Clients verloren gleichzeitig die RVS-Verbindung
(RVS/Proxy kurz weg) — waehrend Gemma 31 s an einer Anfrage von Marina
rechnete. Nach 2 s war alles wieder verbunden, aber die fertige Antwort ging
ueber die tote Verbindung raus und wurde verworfen ("Send fehlgeschlagen
(llm_response)"); Marina wartete bis zu ihrer Frist (660 s) ins Leere.
llm-adapter: llm_response wird ueber die aktuelle Verbindung geschickt, ist
gerade keine offen, aufgehoben (5 min) und nach dem Wiederverbinden
nachgeschickt.
RVS: gezielte Antwort, deren Fragender nur neu verbunden ist (alte
Verbindung weg), geht bis 2 MB an den Raum statt verworfen zu werden — der
Fragende erkennt sie an der requestId. Dateien bleiben gezielt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Bei MoE-Modellen (z.B. Qwen3-Coder-30B-A3B: 18,6 GB, davon 16,35 GB
Experten) rechnet pro Wort nur ein kleiner Teil. llama.cpp kann die
Experten in den RAM legen (--cpu-moe / --n-cpu-moe N), der Rest bleibt auf
der Karte.
Adapter:
- Registry-Feld cpuMoe: 0 = Karte, -1 = alle Experten in den RAM,
N = die der ersten N Schichten; -2 beim Laden = automatisch aufteilen.
- Automatisch: liest nur den Kopf der GGUF bei HuggingFace (HTTP-Range,
Tensor-Verzeichnis), rechnet Experten je Schicht + KV-Cache gegen den
VRAM der Karte und legt so viele Experten auf die Karte wie passen
(12 GB/32k: 16 von 48 Schichten auf der Karte, 32 im RAM).
- Kontext-Auswahl: GB-Schaetzung fuer die Karte ohne ausgelagerte Experten;
slot meldet moe, cpuMoe, ramMB. KV-Rechnung als _kv_bytes() geteilt.
Diagnostic: MoE-Modell zu gross fuer die Karte → Rueckfrage "Experten
automatisch aufteilen?"; pro Karte Auswahl Experten: Karte / automatisch /
Arbeitsspeicher. Kontextwechsel rechnet die Aufteilung neu.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Was ARIA selbst im Proxy ausfuehrt (Bash/ssh, Read, Edit …), war nur live
sichtbar — ob sie fuer "auf Prod nachgesehen" wirklich nachgesehen hat (und
wo), liess sich hinterher nicht pruefen. Das Befehlslog gab es nur fuer die
Host-Agenten.
Proxy (proxy-patches/routes.js): start/tool_use/tool_result/end zusaetzlich
dauerhaft nach /shared/logs/aria-tools/<tag>.jsonl (30 Tage), Passwoerter,
Tokens, API-Keys, private Schluessel und Zugangsdaten in URLs geschwaerzt.
Diagnostic: 🔍 an jeder ARIA-Bubble → alle Werkzeug-Aufrufe zwischen Stefans
Frage und dieser Antwort (Befehl + Ausgabe). Hat sie nichts ausgefuehrt,
sagt das Fenster es deutlich (Stand kommt dann aus Verlauf/Gedaechtnis).
GET /api/aria-proof?ts=&project=.
Deploy: proxy --force-recreate (Patch wirkt nur beim Start), diagnostic --build.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Anlass: Im Projekt Software Bude hat ARIA Test- (aria-wohnung) und
Prod-Schmiede (172.0.2.46) verwechselt, richtige Berichte fuer erfunden
erklaert und auf der Testumgebung ein Projekt angelegt. Ihr Wissen dazu lag
ungepinnt und veraltet ("ALTE Testinstanz") im kalten Gedaechtnis.
- Systemprompt: neuer Abschnitt "DEIN GEDAECHTNIS — so pflegst du es":
von sich aus speichern, was nicht live nachsehbar ist; was NICHT rein
gehoert (laufende Staende, eigene ungepruefte Berichte); Schubladen
(tool = Infrastruktur, angepinnt); vor dem Speichern suchen, aktualisieren
statt doppeln, Falsches loeschen; Erinnern != Wissen; jeder Stand-Bericht
nennt Quelle (wo/womit/wann).
- Verzeichnis: Titel + Merkzeile + Datum statt nur Titel; Cold-Treffer mit Datum.
- memory_save: identity/rule/preference/tool/skill werden angepinnt wie
beschrieben (vorher nur mit explizitem pinned=true — Infrastruktur landete
kalt). memory_update kann die Schublade aendern. Neu: memory_delete.
- Destillat: Fakten nur aus dem, was Stefan sagt/entscheidet/bestaetigt;
keine live nachsehbaren Staende (Ticket-Nummern, Status, Commit-IDs).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
32k als Zeichen-Spanne (Text vs. Code, ~2,3 Zeichen je Token bei HTML/JS)
statt pauschal 20–25 Seiten. Neu: in sehr langen Verlaeufen uebersehen
Modelle eher etwas (Mitte) und jede Anfrage wird langsamer.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Lokal bekam ARIA starr die letzten 8 Nachrichten — alles davor war fuer das
lokale Modell weg. Neu (local_compact.py):
- Fenster nach Tokens: so viele der letzten Nachrichten, wie in ~75 % des
Kontextfensters der Karte passen (Systemprompt + Antwort abgezogen), max.
LOCAL_MAX_TURNS (12). Kontextfenster vom Cluster (Bridge /internal/llm-models).
- Was herausfaellt, fasst das lokale Modell im Hintergrund zum laufenden
Notizzettel zusammen (pro Projekt, /data/local_summaries.json); er geht als
"Bisheriger Verlauf" in den lokalen Systemprompt. Destillat ins Gedaechtnis
laeuft unveraendert weiter. Reset des Gespraechs loescht auch den Zettel.
- Bridge/local_llm: optionale laengere Frist fuer Hintergrund-Aufrufe
(Compacting 180 s statt der 30 s fuer schnelle Antworten).
Diagnostic: Info-Box zum Kontext erklaert Kuerzen / Compacting / Gedaechtnis
und was ARIA davon nutzt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Bisher kam context_exceeded als 502 an — OpenAI-Clients (litellm/OpenHands)
hielten das fuer einen Serverfehler statt zu kuerzen/verdichten. Jetzt 400
mit code context_length_exceeded und dem OpenAI-ueblichen Text inkl. Zahlen.
Doku: Abschnitt "Den Verlauf verwaltet das Programm" (Kuerzen, Verdichten,
Gedaechtnis) fuer Drittprogramme.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Modell-Katalog → "🏆 Bestenlisten": Fenster mit laufend gepflegten
Ranglisten nach Kategorie (Allgemein, Programmieren, Bilder erzeugen,
Lokal/Community — Arena, Artificial Analysis, LiveBench, Aider, SWE-bench,
Vellum, r/LocalLLaMA, HF), darunter "Gerade im Trend auf HuggingFace" pro
Kategorie (Allgemein / Programmieren / Bilder verstehen): nur Repos mit
ladbarem GGUF, echte Groesse + Quantisierung, "passt / zu gross" gegen die
groesste LLM-Karte, standardmaessig nur bekannte Anbieter (Trend != gut).
"In Katalog" uebernimmt das Repo; geladen wird wie gewohnt im Katalog.
Server: GET /api/llm-discover (HF trendingScore, 30 min Cache),
POST /api/llm-catalog/add.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Hinter jeder Token-Auswahl bei den LLM-Karten ein kleines i: oeffnet eine
Erklaerung — Arbeitsgedaechtnis pro Anfrage statt Sitzungsgedaechtnis, was
beim Ueberlauf passiert, Bild Schreibtisch/Aktenordner/Archiv, Speicherbedarf.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Neben "Auslastung" bei jeder Box ein "📊 Karten"-Button: dasselbe Fenster,
nur fuer diese Box (Titel zeigt den Namen).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
LLM-Karten → "📊 Auslastung": Fenster mit jeder Box und jeder Karte, live
jede Sekunde — Rechenlast, Speicher (belegt/gesamt), Temperatur, Strom,
Verlauf der letzten 2 min und was auf der Karte laeuft (LLM-Modell mit
Kontext, Whisper, F5-TTS, Voxtral).
node_stats (alle GPU-Dienste, identische Kopie) meldet im Live-Stream jetzt
zusaetzlich die Werte PRO Karte (mit uuid). Pro Box streamt bevorzugt der
LLM-Adapter (sieht alle Karten mit echter Nummer); Boxen ohne ihn: jeder
GPU-Dienst seine Karte, Nummer aus worker.gpus. Streams werden erneuert,
solange das Fenster offen ist, und beim Schliessen beendet.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Der Adapter liest den Kopf der GGUF-Datei (nur Metadaten): trainiertes
Maximum (context_length) und KV-Cache pro Token — bei Sliding-Window-Modellen
(Gemma) waechst nur der globale Teil mit dem Kontext. Daraus pro Stufe eine
Schaetzung Modell + mmproj + KV (f16) + 1,4 GB Aufschlag (gemessen: Gemma 4
12B @32k geschaetzt 8,8 GB, belegt 8,77 GB).
Diagnostic: Liste kommt von der Box (statt fest 4k..128k), bis zum Maximum
des Modells (auch krumme wie 40960), mit "ca. X GB" und "passt nicht",
wenn es die Karte sprengt. Alte Box ohne Angaben: feste Liste wie bisher.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Statt der nackten Binary haengt release_agent.sh jetzt
aria-host-agent-linux-x64-v<version>.zip an: Binary, install-service.sh,
aria-host-agent.service, .env.example und LIESMICH.txt (Start direkt oder
als systemd-Dienst). Ausfuehrbar-Rechte bleiben beim Entpacken erhalten.
install-service.sh startet den Dienst neu statt nur "enable --now" — so
laedt ein Update die neue Binary auch, wenn der Dienst schon laeuft.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
nssm.cc lieferte 503 → Windows-Build im Release fehlgeschlagen, und das
Skript hat die Ursache verschluckt (>/dev/null). Jetzt: 3 Versuche je Quelle,
Ersatz aus dem Internet Archive, feste SHA-256-Pruefsumme (beide Quellen
liefern dieselbe Datei). release_agent.sh schreibt das Build-Log nach
dist/build-win.log und zeigt bei Fehlern die letzten Zeilen.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Hintere Stellen laufen 0..9 und uebertragen nach vorne (0.2.6.9 → 0.2.7.0,
0.2.9.9 → 0.3.0.0), die vorderste zaehlt einfach weiter (9.9.9.9 → 10.0.0.0).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
./release.sh und host-agent/release_agent.sh ohne Argument nehmen die hoechste
Version aus Datei (package.json bzw. build.gradle) und letztem Git-Tag und
zaehlen die letzte Stelle hoch (0.2.6.1 → 0.2.6.2). Mit Argument wie bisher.
Vor dem Bauen: Anzeige alt → neu und Rueckfrage; existiert der Tag schon oder
ist die Version ungueltig, bricht das Skript vorher ab.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Keine neue Version: Meldung mit installierter Version, neuester Version auf
dem Server und ob Update-Server und Download-Weg erreichbar sind (HEAD auf
/update/latest.apk). Keine Verbindung: Meldung mit Server-Adresse, Zustand
und letztem Verbindungsfehler. Keine Antwort in 10 s: Hinweis auf alten RVS.
Neue Version: wie bisher der Update-Dialog (nur einmal, nicht doppelt ueber
den ChatScreen-Listener).
RVS antwortet auf update_check jetzt auch ohne neue Version (update_none
mit latest/current).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Agent fragt beim Verbinden und alle ~6 h per agent_update_check nach; der
RVS antwortet mit agent_update_available, wenn in rvs/updates/agent/ eine
neuere APK liegt (eigener Ordner — die Cockpit-App bekommt sie so nicht
angeboten). Download im Hintergrund per HTTP (/update/agent/latest.apk,
Raum-Token im Header, 3 Versuche, Groessen-Check), dann Benachrichtigung
"Tippen zum Installieren" + Knopf in der App. Installieren per FileProvider
und Android-Installer (REQUEST_INSTALL_PACKAGES; ein Tippen bleibt Pflicht).
host_hello meldet jetzt die Version. release_agent.sh kopiert die APK auf den
RVS, wenn RVS_UPDATE_HOST gesetzt ist.
RVS: APK-Auslieferung als serveApk() fuer beide Apps zusammengefasst.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Bisher kam die APK als EINE WebSocket-Nachricht (~65 MB Base64) mit starrem
60-s-Timeout — ueber den externen Proxy (Heim-Upload → Hetzner → Handy) zu
knapp, Abbruch ohne Fortschritt.
RVS: GET/HEAD /update/latest.apk — nur mit gueltigem Raum-Token im Header
X-RVS-Token (sonst 403), Content-Length, Range/206 zum Fortsetzen. Version
im Dateinamen wird ohne angehaengten Punkt erkannt.
App: Download per HTTP (react-native-fs) mit Fortschritt in % und MB,
Abbrechen-Knopf, Abbruch nur bei 30 s ohne Daten statt fester Gesamtzeit,
3 Versuche, Groessen-Check gegen Content-Length. Alter RVS (404): Fallback
auf den WebSocket-Weg mit 5 min Timeout.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
RVS: die ARIA-App wird auch ohne client_hello erkannt, sobald sie eine
Nachricht schickt, die nur sie sendet (app_log mit platform android/ios,
location_update, stt_lease_request, update_download, vnc_open).
Bridge: "Voice-Config geladen" und "Voice-Config gespeichert" schrieben
den huggingfaceToken noch im Klartext ins Log — jetzt ***.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Das NVIDIA-Container-Toolkit ersetzt NVIDIA_VISIBLE_DEVICES im Prozess durch
"void" — whisper/f5tts/voxtral meldeten das als GPU. Die Compose gibt die
Karte jetzt zusaetzlich als ARIA_GPU mit (nur Anzeige).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Einstellungen, zwischen Runtime-Konfiguration und App-Onboarding: alle
Verbindungen im Raum des konfigurierten Tokens — Art, Name, Details,
Adresse, verbunden seit, zuletzt aktiv.
RVS merkt sich pro Verbindung, wer sie ist: aus Nachrichten, die ohnehin
fliessen (sat_hello, host_hello, worker_hello, update_check der App,
llm_cluster_*), oder aus dem neuen client_hello (Bridge, Diagnostic, App
mit Geraetename). Adresse aus X-Forwarded-For hinter einem Reverse-Proxy.
room_clients_query liefert NUR den eigenen Raum; room_clients von Clients
wird nicht weitergereicht. Typen in der Allow-List ergaenzt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Mit RVS_HTTP_TLS=true spricht der RVS auf RVS_HTTP_PORT HTTPS/WSS statt
Klartext — damit ist auch die Strecke externer Proxy → RVS verschluesselt.
Das oeffentliche Zertifikat hat der Proxy; hier reicht ein selbstsigniertes,
das beim ersten Start in data/rvs-tls/ erzeugt wird (eigenes darf dort
liegen). Image bekommt dafuer openssl. Nur ohne den Caddy im Stack.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Neu in rvs/.env: COMPOSE_PROFILES=caddy (wie bisher, Caddy macht TLS) oder
leer (ohne Caddy). Der RVS bietet dafuer immer einen unverschluesselten Port
an (RVS_HTTP_BIND:RVS_HTTP_PORT, Default 127.0.0.1:3000), auf den ein
vorhandener nginx/Traefik zeigt — statt nginx → Caddy → RVS mit doppeltem TLS.
Caddys HTTPS-Port ist jetzt CADDY_HTTPS_PORT (Default 444 wie bisher).
README: beide Modi, nginx-Vorlage mit WebSocket-Headern und IPv6, Hinweis
dass Caddy fuer die Zertifikats-Erneuerung Port 80 von aussen braucht.
Bestehende Installationen mit Caddy muessen COMPOSE_PROFILES=caddy eintragen.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Neben dem Zahnrad zeigt ein Schloss, wie sicher die Verbindung zu ARIA ist:
Schloss = verschluesselt und in Ordnung, Schloss mit ! = Zertifikat-Problem
(abgelaufen oder abgelehnt), durchgestrichen = unverschluesselt (TLS-Fallback
oder so eingestellt). Antippen erklaert es in einfachen Worten; einmal pro
App-Start kommt ein Hinweis, wenn das Zertifikat abgelaufen ist.
Einstellungen → Verbindung: "Abgelaufenes Zertifikat akzeptieren". Toleriert
GENAU das Ablaufdatum: die Kette wird zum Zeitpunkt kurz vor dem Ablauf gegen
die System-CAs geprueft, der Hostname weiter von OkHttp. Selbstsignierte oder
fremde Zertifikate kommen auch mit Schalter nicht durch (gegen das echte,
abgelaufene RVS-Zertifikat und badssl.com getestet). Gilt fuer WebSocket und
fetch (z.B. App-Update vom RVS).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Die Bridge schrieb beim Config-Broadcast den kompletten Payload ins Log,
inklusive huggingfaceToken. Jetzt werden Werte von Schluesseln wie token,
secret, passw, apikey, credential als *** ausgegeben (Zaehler wie maxTokens
bleiben sichtbar). Dasselbe fuer das Debug-Log der RVS-Nachrichten in der
Diagnostic.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Anlass: die Software-Schmiede bekam "request (8274 tokens) exceeds the
available context size (8192 tokens)". Sie holt ctx vom Cluster zwar ab,
kuerzt aber nach einem eigenen, von Hand eingetragenen Wert (32768).
ARIA-Seite:
- Neue Fehlerart context_exceeded (statt model_error) mit promptTokens und ctx
— Programme koennen automatisch kuerzen und nochmal senden, statt Text
auszuwerten. llm-adapter liest es aus llama.cpps exceed_context_size_error,
der Cluster-Router reicht es durch und wiederholt es nicht anderswo.
- Diagnostic → LLM-Karten: Kontextfenster pro Karte (4k … 128k). Laedt das
Modell mit neuem -c; Programme sehen den neuen Wert ueber ctx. Passt es
nicht in den Grafikspeicher, setzt die Box zurueck — jetzt inkl. Registry
(vorher blieb bei einem Fehlschlag der zu grosse ctx in aria_models.json
stehen und waere beim naechsten Start wieder gescheitert).
- Doku: context_exceeded, ctx kann sich aendern, "danach kuerzen, nicht nur
anzeigen".
Getestet gegen llama-swap: Kontext 512 → 1024 (gleiche Karte), Fehlschlag
bei 65536 → Registry + Config wieder 1024, zu langer Verlauf →
context_exceeded mit promptTokens=6030, ctx=1024.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Zwischendurch kam bei Programmen (Software-Schmiede) "model_error: Server
error '500 …'" — nach "nochmal versuchen" lief es weiter. Ursache, auf der
Box nachgestellt: steht im Verlauf ein frueherer Werkzeugaufruf, dessen
arguments kein gueltiges JSON sind (typisch bei Code: Dateiinhalt mit
Anfuehrungszeichen/Umbruechen), lehnt llama.cpp (Stand der Box, Aug. 2026)
die GANZE Anfrage mit 500 ab — und jede weitere mit demselben Verlauf.
Neuere llama.cpp-Versionen nehmen es an.
llm-adapter:
- _sanitize_messages: solche arguments werden als {"_raw": "…"} verpackt,
dict-arguments zu JSON, fehlende zu "{}". Nur Kopien; gueltige bleiben
unangetastet. Auf der Box: kaputt → 500, eingepackt → 200.
- _llama_error_text: bei HTTP-Fehlern kommt der GRUND von llama.cpp mit
(z.B. "request (9017 tokens) exceeds the available context size (8192)")
statt nur "Server error '500'". Volle Antwort ins Box-Log — falls es noch
einen anderen Ausloeser gibt, steht er dort.
Hinweis: ob das der einzige Ausloeser ist, ist offen — die urspruengliche
Fehlerantwort war 4,6 KB gross, diese Ablehnung nur 265 Byte. Mit dem
durchgereichten Grund ist der naechste Fall sofort zu sehen.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Zwei Ursachen, beide auf der KI-Box nachgewiesen:
1. llama.cpp fand auch mit Treiber 615 keine Karte ("unsupported display
driver / cuda driver combination"). Das llama-swap-Image traegt in seiner
ld.so.conf die eigene CUDA-Kompatibilitaets-libcuda (575) VOR dem vom
Container-Toolkit eingehaengten Host-Treiber (615) ein. Die Kompatibilitaets-
bibliothek hilft nur Rechenzentrumskarten; bei GeForce scheitert llama.cpp
damit — mit aelterem Treiber ("forward compatibility …") wie mit neuerem —
und rechnet still auf der CPU. Jetzt LD_LIBRARY_PATH mit dem Host-Treiber
zuerst. Auf der Box getestet: llama.cpp sieht CUDA0 + CUDA1. Whisper und
F5-TTS (andere Images) sehen ihre Karte mit 615 ohnehin.
2. Nach dem Reboot erreichte kein Container den RVS ("Temporary failure in name
resolution"). Debian traegt die Netzwerkkarte als allow-hotplug ein; darauf
wartet network-online.target nicht. Docker startete die Container 2 s nach
"online", bevor DHCP den DNS-Server lieferte ("DNS resolver has no external
nameservers"), und die Container behalten diesen leeren Stand. Passiert bei
jedem Reboot. bootstrap.sh legt jetzt ein systemd-Drop-in an: Docker wartet
vor dem Start bis zu 90 s auf einen Nameserver in /etc/resolv.conf, dann
startet es trotzdem. Netzkonfiguration bleibt unangetastet. Escaping und
beide Pfade (DNS da / nicht da) in einer echten systemd-Unit getestet.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Nach "--upgrade-driver" + Reboot lud der freie nouveau-Treiber statt nvidia,
nvidia-smi fehlte, und Docker startete keinen GPU-Container mehr ("failed to
initialize NVML: Driver Not Loaded"). Zwei Stolperfallen, die in der
apt-Simulation vorher nicht sichtbar waren:
1. NVIDIAs Paket "nvidia-smi" ist nur noch Doku. Das Programm — und
Bibliotheken, die das Container-Toolkit braucht — steckt bei NVIDIA in
"nvidia-driver-cuda". Jetzt in der Paketliste.
2. /etc/modprobe.d/nvidia.conf (sperrt nouveau) war ein Verweis ueber das
Alternativen-System. Die entfernten Altpakete nehmen ihn mit, dpkg legt die
neue Datei nur als nvidia.conf.dpkg-new ab. Jetzt: tote Verweise weg,
.dpkg-new aktivieren (oder eigene Sperre schreiben), initramfs fuer alle
Kernel neu bauen.
nv_postfix laeuft nach der Installation UND, wenn der Treiber schon neu ist —
ein erneuter --upgrade-driver-Lauf repariert also eine Box, die schon in
diesem Zustand steckt. Idempotent; meldet nur Erfolg, wenn das Schreiben
geklappt hat. Getestet gegen den nachgestellten Zustand der Box (erst
Reparatur + Reboot-Hinweis, zweiter Lauf: nichts zu tun).
Dazu: die DKMS-Pruefung las den Kernelnamen als Regex — "6.12.101+deb13"
passte darum nie, die Warnung "nicht gebaut" war falsch. Jetzt -F, und fuer
jeden installierten Kernel (apt hatte nebenbei 6.12.113 mitgebracht, der dann
startete).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1. "Die LLM-Box meldet noch keine Karten": die Box schickte die Karten-
Belegung, aber workerList() im Diagnostic-Server gibt nur eine feste
Feldliste an den Browser — slots stand nicht drauf. Meine UI-Tests haben
die Flotte direkt im Browser gesetzt und sind an genau dieser Stelle
vorbeigelaufen. Jetzt Ende-zu-Ende getestet: echter Diagnostic-Server +
RVS + Box-Meldung → Browser (per DevTools-Protokoll gelesen).
2. Lokales Modell sprang auf "Qwen3 8B" zurueck: die Auswahl wurde gespeichert,
aber die Seite behielt intern das alte Modell und stellte das Dropdown beim
naechsten Lebenszeichen der Box (10 s) darauf zurueck. Dazu wie gewuenscht
umgebaut: nur Modelle, die im Cluster geladen sind, jedes einmal, ohne
Karte. Ist das gewaehlte gerade nirgends geladen: "(offline)" — geht
automatisch weiter, sobald eine Box es hat. Nichts da: "kein Modell
verfuegbar". Waehrend die Auswahl offen ist, wird nicht umgebaut.
3. "Bereit", aber Karte leer: der llm-adapter meldet pro Karte den belegten
VRAM. Laeuft ein Modell "ready" und die Karte bleibt unter 400 MB, rechnet
llama.cpp auf der CPU (Treiber zu alt fuer das CUDA im Image) — das sagt
llama.cpp nicht nach aussen. Diagnostic zeigt es jetzt in Flotte,
LLM-Karten und Modell-Auswahl ("laeuft auf der CPU").
4. bootstrap.sh: der normale Lauf meldete "✓ Treiber aktiv", auch wenn er fuer
das LLM zu alt ist. Jetzt Warnung mit Version und dem Befehl
(--upgrade-driver), wenn das LLM-Profil aktiv ist.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Das lokale LLM rechnete auf der KI-Box die ganze Zeit auf der CPU: Treiber
550 (Debian, auch trixie-backports — mehr gibt es dort nicht) kann CUDA 12.4,
die llama.cpp-/llama-swap-Images brauchen 12.8/12.9. llama.cpp meldet dann
"failed to initialize CUDA … forward compatibility …", findet keine Karte
und laeuft still auf der CPU weiter — "ready" meldet es trotzdem. Whisper und
F5-TTS (CUDA 12.2) waren nicht betroffen.
--upgrade-driver installierte bisher "nvidia-driver" aus den Backports und
meldete Erfolg — es kam aber derselbe 550er. Jetzt: NVIDIAs Paketquelle fuer
Debian 13 (Treiber 615), Upgrade an Ort und Stelle.
Vorher auf der Box simuliert (apt -s in einem Temp-Verzeichnis, nichts
veraendert): ALLE installierten NVIDIA-Pakete mit hochzuziehen scheitert an
Konflikten — NVIDIA hat Debians Teilpakete (nvidia-driver-bin,
nvidia-alternative, …) zusammengefasst. Nur nvidia-driver, nvidia-kernel-dkms,
nvidia-smi, libcuda1 (+ persistenced/modprobe, wenn installiert) anfordern →
apt loest es sauber: 30 aktualisiert, 8 neu, 10 Altpakete entfernt,
Container-Toolkit unberuehrt.
Sicherungen: spielt erst durch (apt -s); bricht OHNE Aenderung ab und nimmt
die Paketquelle wieder raus, wenn apt keinen Weg findet oder das
Container-Toolkit anfassen wuerde. Zeigt den Plan und fragt nach (--yes zum
Ueberspringen). Prueft danach Version und DKMS-Build. Ablauf in einem
frischen Debian-13-Container getestet (Installation abgefangen).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Programme sollen nicht Box und Karte aussuchen muessen. Die ARIA-Bridge kennt
alle Boxen samt Karten-Belegung und verteilt (bridge/llm_cluster.py):
- Auswahl: unter allen online Boxen mit dem Modell die mit den wenigsten
laufenden Anfragen, bei Gleichstand reihum. Eine Karte / alles frei →
alles dorthin ("verteilen, wenn noetig").
- Ausfall: geht eine Box waehrend der Anfrage offline (kein Ping mehr), wird
sie EINMAL an eine andere Box mit demselben Modell gegeben. Modell-Fehler
(z.B. Kontext zu lang) werden nicht wiederholt — waeren ueberall gleich.
- Fehler kommen als Fehler (ok=false + errorCode), nie als Antwort-Text: ein
Programm wuerde ihn sonst als Aussage der KI in seinen Verlauf schreiben —
so ist bei ARIA schon mal ein ganzer Chat kaputtgegangen.
RVS: llm_cluster_models_request → llm_cluster_models (jedes Modell EINMAL,
ctx = kleinstes Kontextfenster unter seinen Karten), llm_cluster_request →
llm_cluster_response. In der RVS-Allow-List freigegeben.
ARIA nutzt denselben Router (mit ihrer 30-s-Frist fuer den lokalen
Schnellweg) — vorher Round-Robin ohne Ausfall-Ersatz, und errorCode ging
verloren.
xtts/openai_rvs_wrapper: fuer Programme, die nur "OpenAI-kompatibel" koennen
(OpenHands & Co.). Kleiner Container NEBEN dem Programm, fuer das der Cluster
dann http://127.0.0.1:8099/v1 ist; braucht nur eine ausgehende Verbindung zum
RVS. /v1/models (jedes Modell einmal, context_length), /v1/chat/completions
(auch stream und tools), Fehler als HTTP mit OpenAI-Fehlerobjekt. Hilfsseite
auf / zeigt Status, Base URL und Modelle. Fuer Programme in Docker: Netz
aria-llm, Name openai-rvs-wrapper. .env.example mit RVS_HOST/PORT/TOKEN.
(Ein OpenAI-Endpunkt direkt auf der VM war kurz drin und ist wieder raus —
der Wrapper braucht keinen offenen Port auf der VM.)
docs/LLM-SCHNITTSTELLE.md neu gegliedert: A) Cluster ueber RVS (empfohlen),
B) Wrapper, C) direkt an eine Box (Sonderfall), plus "Umstellen" fuer
bestehende Clients (Software-Schmiede).
Tests: mit echtem RVS und zwei echten llm-adaptern als zwei Boxen —
Modell einmal gelistet, 6 parallele Anfragen 3/3 verteilt, Box friert
mitten in der Anfrage ein → nach 15 s von der anderen beantwortet
(attempts=2), danach direkt die gesunde, nicht geladenes Modell →
model_unavailable ohne content. Wrapper als Docker-Container gegen das
offizielle OpenAI-SDK: models.list, create mit/ohne stream, NotFoundError,
AuthenticationError. Das Doku-Beispiel lief unveraendert (nur Adresse).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Einstellungen → Modelle & KI → "LLM-Karten": fuer jede Karte, die auf einer
Box fuers LLM vorgesehen ist, ein Dropdown mit den Katalog-Modellen und
"— leer —" (entlaedt die Karte). Nur echte LLM-Karten erscheinen. Modelle,
die auf derselben Box schon auf einer anderen Karte liegen, werden nicht
angeboten; zu grosse (Katalog-Groesse > VRAM der Karte) sind als "passt
nicht" markiert. Waehrend eines Ladevorgangs ist das Dropdown gesperrt und
zeigt den Fortschritt.
Box meldet dafuer pro Karte den VRAM (nvidia-smi memory.total) und das
Kontextfenster, mit dem llama-server das Modell startet (-c).
Kontext an Clients: llm_models enthaelt jetzt "ctx". Anlass: die Software-
Schmiede rechnete mit 32768 Tokens, die Box startet die Modelle mit 8192 —
lange Auftraege waeren gescheitert oder falsch gekuerzt worden, und der Client
konnte es nicht wissen. Doku entsprechend ergaenzt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Das X war absichtlich versteckt, sobald ein Dienst einen Fehler meldete — es
erschien nur, wenn alles gruen war. Gerade eine Fehlermeldung blieb also
stehen. Jetzt ist das X immer da; Wegklicken vergisst Fehler- und
Fertig-Meldungen (sonst kaemen sie mit der naechsten Statusmeldung eines
anderen Dienstes wieder hoch), ein laufender Ladevorgang darf wiederkommen.
Dazu: httpx haengt an jeden Fehler "For more information check: <Mozilla-
Link>" — raus, in der Anzeige und im llm-adapter an der Quelle. Bei nur einer
Meldung stand das ❌ doppelt (grosses Symbol + Zeile) — jetzt einmal.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Laden von unsloth/gemma-4-12B-it-qat-GGUF scheiterte mit "500": der Katalog
trug pauschal Q4_K_M ein, das Repo hat aber nur UD-Q4_K_XL. llama-server fand
die Datei nicht und beendete sich sofort; llama-swap reicht den Grund nicht
weiter ("upstream command exited prematurely"), es kam nur "500" an.
llm-adapter: fragt vor dem Laden die Dateiliste des Repos ab. Gibt es die
gewuenschte Quantisierung nicht, nimmt er die naechstbeste aus einer festen
Reihenfolge (Q4_K_M, UD-Q4_K_XL, Q4_K_XL, Q4_K_S, IQ4_XS, …) und sagt das im
Download-Fenster an. Kein ladbares GGUF im Repo → sofortige Absage, die Karte
bleibt unberuehrt. Bild-Projektor (mmproj), MTP-Zusatzdateien und imatrix
zaehlen nicht als Modell. Endet llama-server trotzdem sofort, nennt die
Meldung die haeufigsten Gruende statt nur "500".
Diagnostic: "Von HuggingFace aktualisieren" traegt pro HF-Repo die tatsaechlich
vorhandene Quantisierung und die echte Groesse ein (bisher 0 GB) — auch bei
schon vorhandenen HF-Eintraegen. Repos ohne ladbares Modell kommen nicht mehr
in den Katalog bzw. werden als "nicht ladbar" markiert. Katalog zeigt die
Quantisierung pro Modell.
Gemma 4 selbst: llama.cpp kann es seit Juni (#24077), der Stand auf der Box ist
vom 14.08. — es lag nur an der Datei.
Getestet gegen echte HF-Repos (Gemma → UD-Q4_K_XL 6,7 GB, Qwen/Mistral bleiben
Q4_K_M) in Adapter und Diagnostic identisch, und gegen llama-swap: Ausweichen
angesagt + geladen; Repo ohne GGUF → Absage ohne Download.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Bisher konnte jeder Client per Modellname llama-swap zum Wechseln bringen —
ein Fremdprogramm haette ARIA das Modell unter den Fuessen weggetauscht.
Jetzt:
- Jede LLM-Karte einer Box (LLM_GPUS=1,2, alt LLM_GPU=1) haelt GENAU ein
Modell, dauerhaft. Welches, legt nur die Diagnostic fest. Karten, die nicht
fuers LLM vorgesehen sind, tauchen beim LLM nicht auf und werden als Ziel
abgelehnt.
- Clients (ARIA, Fremdprogramme ueber RVS, OpenHands ueber den OpenAI-Port)
sehen nur die geladenen Modelle und laden nie: Anfrage fuer ein anderes →
model_not_loaded mit Liste des Geladenen (RVS) bzw. HTTP 404 (OpenAI-Port).
Nichts wird verdraengt.
- Mehrere Clients koennen dasselbe Modell gleichzeitig nutzen.
llm-adapter: Belegung in /models/aria_slots.json. Die llama-swap-Config
enthaelt nur belegte Karten: pro Modell CUDA_VISIBLE_DEVICES=<Karte>, ttl 0,
groups.swap=false, hooks.on_startup.preload. Alles gegen llama-swap
ausprobiert (zwei Modelle gleichzeitig ready, keins verdraengt, Unbekanntes
404, env kommt beim jeweiligen llama-server an). llama-swap laeuft mit
--watch-config; die frueher aufgerufenen Reload-Endpunkte (/reload,
/api/config/reload) gibt es nicht (404). Neu: llm_unload_model (Karte leeren),
llm_models_request → llm_models (Erkundung, jede Box antwortet einzeln).
Fehlgeschlagenes Laden setzt die Karte auf ihr vorheriges Modell zurueck,
sonst risse jedes Neuladen die anderen Karten mit. Uebernahme: ohne
Belegungsdatei landet LLM_MODEL auf der ersten LLM-Karte.
Compose: llama-swap sieht alle Karten (NVIDIA_VISIBLE_DEVICES=all) und
zaehlt sie wie nvidia-smi (CUDA_DEVICE_ORDER=PCI_BUS_ID); das Pinnen pro
Modell macht der Adapter.
Bridge: uebernimmt models/slots auch aus worker_ping (nach "Entladen" sonst
30 s veraltet) und sagt sofort ab, wenn das Modell auf keiner Box liegt,
statt per Broadcast in den Timeout zu laufen.
Diagnostic: Flotte zeigt pro LLM-Karte Modell + Zustand + "Entladen";
Katalog waehlt eine Ziel-KARTE (leere vorausgewaehlt, Ersetzen mit
Rueckfrage); Download-Fenster nennt Karte und was ersetzt wird.
RVS: llm_unload_model, llm_models_request, llm_models freigegeben.
docs/LLM-SCHNITTSTELLE.md: Schnittstelle fuer Drittprogramme (RVS + OpenAI-
Port), Fehlercodes, Gleichzeitigkeit, Python-Beispiel.
Tests: 23 gegen llama-swap (Adapter direkt) + Ende-zu-Ende ueber den echten
RVS mit dem Adapter als Prozess: Laden per RVS mit Fortschritt, das
Doku-Beispiel unveraendert (nur Adresse) findet beide Karten und bekommt eine
Antwort, Absage/Schweigen wie dokumentiert, zwei Clients parallel.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Die Flotte listete "qwen3-4b, qwen3-8b" — das sind die Modelle, die die Box
fahren KANN (llama-swap /v1/models), nicht die geladenen. Ohne groups-Config
liegt immer nur eins in der Karte; ein anderes anzufragen entlaedt es
(gegen llama-swap ausprobiert: A laden, B anfragen → A unloaded).
Der Adapter fragt jetzt llama-swap /running und schickt das Ergebnis in jedem
worker_ping (10 s) und im worker_hello mit; nach einem Modellwechsel sofort.
None = llama-swap nicht erreichbar, [] = nichts geladen — die Anzeige
unterscheidet das ("geladen: ?" vs. "keins geladen").
Diagnostic: das geladene Modell gruen mit "● geladen", die anderen grau mit
Hinweis, dass sie beim ersten Aufruf laden und das geladene verdraengen.
"GPU void": die LLM-Zeile zeigt jetzt LLM_GPU (die Karte von llama-swap) statt
der NVIDIA_VISIBLE_DEVICES des Adapters, die mit der Modell-Karte nichts zu
tun hat.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Eigentlicher Fehler zuerst: llm_provision_model/_result und llm_remove_model
standen nie in der RVS-Allow-List. Der RVS verwirft unbekannte Typen mit einem
stillen return — jeder Klick auf "Laden" im Modell-Katalog ist seit Stage D
(19.09.) an dieser Liste gestorben, die Box hat nie davon erfahren. Laden
liessen sich nur die Modelle aus der Basis-Config der Box.
Gefunden, weil grep rvs/server.js fuer eine Binaerdatei hielt und still
uebersprang: in Zeile 164 stand seit a7998bcd ein ECHTES Nullbyte im
Template-String statt eines Escapes. Node stoert das nicht, aber git zeigte
fuer jede Aenderung am RVS nur noch "Binary files differ". Jetzt \u0000 —
zur Laufzeit derselbe String.
Fortschritt: llama.cpp zieht das GGUF per -hf selbst und meldet nichts. Der
llm-adapter fragt vorab bei Hugging Face, welche Dateien (Groesse, sha256)
kommen, und misst genau diese im HF-Cache-Layout, das llama.cpp verwendet:
/models/models--org--repo/blobs/<sha256>.downloadInProgress (waechst)
/models/models--org--repo/blobs/<sha256> (fertig)
Layout gegen den echten llama.cpp-Server ausprobiert, nicht angenommen. Geht
auch bei gesplitteten Modellen und zwei Downloads gleichzeitig; Fallback fuer
aeltere Layouts ueber alle *.downloadInProgress. Phasen: queued → start →
download (%, MB/s, Restzeit) → load ("laedt in die Karte") → ready ("in Karte
N geladen", Name + VRAM aus nvidia-smi) bzw. error.
Mitgefixt: der Warmup wartete LLM_TIMEOUT_SEC (Default 60 s). Ein Modell mit
mehreren GB meldete deshalb "Fehler", waehrend llama-swap weiterlud. Jetzt
LLM_WARMUP_TIMEOUT_S (1900 s, ueber llama-swaps healthCheckTimeout).
Diagnostic: Knopf "⬇ Downloads" neben "Von HuggingFace aktualisieren" mit
Zaehler fuer laufende; "Laden" oeffnet das Fenster direkt. Der Server merkt
sich den Stand pro (Box, Modell), ein spaeter geoeffneter Tab sieht laufende
Downloads. Antwortet die Box nicht, steht nach 30 s eine Warnung da statt
nichts.
Compose (KI-Box): llm-adapter bekommt LLM_GPU (Karte fuer die Meldung) und
HF_TOKEN (Dateiliste gesperrter Repos).
Test: Fortschritt gegen einen echten llama.cpp-Download (Qwen2.5-0.5B Q8,
676 MB): Prozent steigend 0 → 91.6, dann load; zweiter Lauf aus dem Cache
direkt load mit cached=true.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
IMAP/SMTP mit SSL/TLS, STARTTLS oder unverschluesselt. Senden mit Text, HTML,
Anhaengen und eingebetteten Bildern (cid:), Antworten mit In-Reply-To. Lesen,
Suchen, Ordner anlegen (auch Unterordner), Mails verschieben.
Tools: email_status/send/list/read/folders/folder_create/move.
Whitelist als harte Grenze im Sendepfad, nicht im Prompt: alles, was nicht
drinsteht, ist gesperrt, leer = nirgendwohin. Jeder Empfaenger zaehlt (An, Cc,
Bcc), ein fremder blockiert die ganze Mail. Genau eine Schreibweise:
name@domain, '*' nur als *@domain, *@*.domain oder *@*. '*hacker-net.de' liest
sich, als passte es auf 'evilhacker-net.de' — solche Kurzformen lehnt das
Speichern mit Korrekturvorschlag ab. Verglichen wird die Domain als Ganzes.
Zugangsdaten sieht ARIA nie:
- liegen im Brain unter /data. NICHT in /shared — das ist in ARIAs Container
eingehaengt, /data nicht.
- keine Schnittstelle gibt das Passwort zurueck, nur password_set.
- Brain-Export laesst email_secret.json + email_admin.key aus (GNU- und
busybox-tar geprueft, der Diagnostic-Container ist Alpine).
- Anhangspfade nach realpath geprueft: ein Symlink in /shared/uploads auf die
Geheimnis-Datei wuerde sonst im Brain aufgeloest und verschickt.
- Konfiguration nur mit Admin-Schluessel (X-Aria-Admin, liegt in /data). Die
Diagnostic haengt ihn an, weist aber Anfragen aus ARIAs Container ab —
sonst koennte eine eingehende Mail sie per curl die Whitelist oeffnen lassen.
Grenze: ARIAs Container hat SSH auf die VM. Gegen einen gezielten Einbruch
schuetzt das nicht, nur dagegen, dass Zugangsdaten von selbst auftauchen.
Eingehende Mails sind fuer ARIA als Daten markiert, nicht als Anweisungen.
Diagnostic: Einstellungen → Integrationen → ARIA E-Mail, plus
"📬 Postfach oeffnen" — ARIAs ganzes Postfach in eigenem Fenster, Unterordner
eingerueckt, Posteingang + Gesendet oben. Nur lesend, markiert nichts als
gelesen. Mail-HTML in einem Rahmen ohne Skripte und ohne Nachladen von aussen
(kein Tracking-Pixel); eingebettete Bilder kommen als data: mit. Jede
gesendete Mail landet als Kopie in "Gesendet" — fehlt der Ordner, wird er
angelegt, statt die Kopie still zu verlieren.
Tests: 65 Einheitstests (Whitelist inkl. evilhacker-net.de, MIME-Aufbau,
Header-Injection, Symlink-Ausbruch, Geheimnis nie in Ausgaben) + 50 gegen einen
echten Mailserver (GreenMail): TLS-Login, Senden mit Anhang + Bild, Flags,
Suche mit Umlaut, Gesendet-Kopie, In-Reply-To, Ordner mit Umlaut, MOVE und
der Fallback ohne MOVE (der keine fremden geloeschten Mails mitreisst).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Nach einem Sicherheitsfilter-Treffer fuhr ein Projekt still auf dem
Ausweich-Modell weiter, und nirgends war zu sehen, auf welchem. Zurueck ging
nur ueber "Liste leeren" im Filter-Panel, und das gleich fuer alle Chats.
Jetzt drei Ebenen (aria-brain/context_model.py):
Einstellung (brainModel) < pro Chat < Ausweich (Sicherheitsfilter)
- Pro Chat: Hauptchat und jedes Projekt koennen ein eigenes Modell haben, in
/shared/config/context_models.json. Bewusst kein Feld im Projekt-Manifest —
der Hauptchat ist kein Projekt und waere sonst aussen vor.
- "↩ zurueck" pro Chat: loescht nur die Filter-Vermerke DIESES Chats. Blockt
der Filter erneut, weicht das Brain eben wieder aus.
- Angezeigt wird, was wirklich laeuft: chat() gibt das Modell aus modelUsage
der CLI zurueck (aufgeloeste Version statt Alias) samt Grund; Brain → Bridge
→ chat_backup + Live-Payload → App und Diagnostic. Als Grundeinstellung
zaehlt das Modell, mit dem das Brain laeuft, nicht der Dateiwert — so faellt
ein ausstehender Neustart nach brainModel-Aenderung auf.
Diagnostic: 🧠-Auswahl neben "+ Projekt" fuer den fokussierten Chat, Modell im
Untertitel jeder Kontext-Karte, Modell statt "Claude" am Bubble-Badge (orange
mit ↪ bei Ausweich).
App: hinter der Quell-Anzeige (Einstellungen, Default aus — Kopfzeile bleibt
fuer Mama unveraendert) ein Modell-Chip in der Kopfzeile; Tippen oeffnet die
Auswahl fuer diesen Chat inkl. "Zurueck". Laeuft ueber den vorhandenen
brain_request-Kanal, also keine neuen RVS-Typen.
Tests: 47/47 (12 neue fuer die Aufloesungsreihenfolge gegen agent.chat()),
tsc ohne Fehler.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Anthropics Filter ("safeguards flagged this message", Details: [cyber]) trifft
genau unsere Themen — Ports, Tunnel, Zugangsdaten. Bisher war danach der
Projekt-Chat tot, und zwar aus einem Grund, den man der Meldung nicht ansieht:
Der Filter meldet sich NICHT als HTTP-Fehler. Die CLI liefert ein voellig
normales Ergebnis mit is_error=true und dem Fehlertext im content — also dort,
wo sonst ARIAs Antwort steht. proxy_client.py warf das Flag weg, der Agent
konnte Fehler und Antwort nicht unterscheiden und schrieb den Text per
conversation.add("assistant", ...) in den Verlauf. Weil der Verlauf bei jedem
Turn mitgeht, scheiterte ab da JEDE weitere Frage an derselben Stelle.
Zwei Stufen dagegen (aria-brain/safeguard.py):
1. Modellwechsel. Der Filter haengt am Modell ("Opus 5's safeguards ..."),
Anthropic raet selbst zu "change your model". Derselbe Turn wird automatisch
mit dem Ausweich-Modell neu gefragt; laeuft der Rest des Turns (Tool-Schritte)
gleich mit darauf weiter. Der ausloesende Turn wird vermerkt, damit die
naechsten Turns nicht erst wieder gegen die Wand laufen. Der Vermerk
verfaellt von selbst, sobald der Turn aus dem Rolling Window gerollt ist —
nichts muss aufgeraeumt werden, und das Projekt faellt von allein aufs
Hauptmodell zurueck.
2. Quarantaene. Blockt auch das Ausweich-Modell, liegt es am Verlauf selbst.
Dann faellt der ausloesende Turn aus dem Prompt-Fenster. NICHT geloescht: er
bleibt in conversation.jsonl, steht mit Text in der Diagnostic und ist per
Klick zurueckholbar. Der rohe Fehlertext wird nie persistiert — ARIA sagt in
eigenen Worten, was passiert ist.
Der Zustand liegt in /data/safeguard.json, bewusst nicht in conversation.jsonl:
ein Markieren dort erzwaenge ein Rewrite, und das schreibt nur das In-Memory-
Window zurueck — alles schon Destillierte waere weg.
Erkennung bewusst zweistufig: mit is_error genuegt ein Marker, ohne muss der
Text mit "API Error" beginnen. Sonst wuerde eine Antwort, in der ARIA ueber den
Filter *spricht*, einen Modellwechsel ausloesen.
Mitgenommen:
- Das Memory-Destillat schickt denselben Verlauf nochmal durch und wurde
genauso blockiert — nur fiel es dort als "unparsbares JSON" auf und
wiederholte sich bei jedem Lauf. Weicht jetzt ebenfalls aus.
- clean_poisoned_turns.py raeumt die Altlasten: Fehlertexte, die vor diesem Fix
schon im Verlauf stehen. Neu auch in Projekten (dort sterben sie ja), mit dem
ausloesenden User-Turn desselben Kontexts, Dry-Run per Default.
- Diagnostic: Ausweich-Modell einstellbar (runtime.json, ohne Neustart, weil
safeguard.py erst im Ernstfall liest) und ein Panel, das zeigt was blockiert
wurde und ob es NOCH wirkt.
Tests: 35/35 fuer die Rettungskette gegen den echten agent.chat(), 16/16 fuer
das Aufraeum-Script.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Im Kontext-Streifen gab es keinen Weg, ein Projekt anzulegen — das ging nur
unten in den Einstellungen. Der Knopf steht bewusst AUSSERHALB des scrollenden
Streifens: bei mehreren Projekten waere er dort nach rechts rausgerutscht.
Anlegen zieht jetzt beide Projekt-Oberflaechen nach (Einstellungs-Liste UND
Streifen) und setzt den Fokus aufs neue Projekt. Vorher aktualisierte nur die
Liste, das neue Projekt blieb im Streifen bis zum 15s-Poll unsichtbar — und der
Fokus blieb im Hauptchat, obwohl create_project() serverseitig umschaltet. Man
legte also ein Projekt an und schrieb weiter in den Hauptchat.
Dazu ein Fehlerpfad: ein fehlgeschlagenes Anlegen (z.B. leerer Name, 400 vom
Brain) wurde stillschweigend verschluckt — das Modal schloss, als waere alles
gut. Jetzt kommt die Begruendung des Brains als Meldung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Beide hiessen bisher so, wie es in IHRER .env steht. Umbenennen hiess also: auf
den Rechner, Datei aendern, Dienst neu starten — beim Fire TV sogar neu
provisionieren. In der Oberflaeche gab es dafuer gar keinen Weg.
Jetzt ein ✎ pro Eintrag. Der Alias liegt zentral in
/shared/config/display_names.json ({"host": {...}, "satellite": {...}}) und
wirkt sofort fuer JEDEN schon ausgerollten Agenten, ohne ihn anzufassen.
Der entscheidende Teil ist die Rueckrichtung: die Bridge loest den Alias beim
ADRESSIEREN wieder auf (_resolve_host / _resolve_satellite). Ohne das haette man
etwas umbenennen koennen und es danach nicht mehr ansprechen — der Agent
vergleicht die Adresse gegen seine EIGENE Kennung und kennt den Alias nicht.
Angesprochen werden kann weiterhin alles: Alias, Eigenname oder technische ID.
Der Eigenname bleibt in der Liste klein daneben sichtbar, damit man den Bezug
zum Geraet nicht verliert. Leerer Name entfernt den Alias.
Diagnostic und Bridge teilen sich die Datei ueber /shared — kein neuer
Nachrichtentyp, keine Allow-List-Aenderung, eine Wahrheit.
Nebenbei behoben: _display_name_set legte fest "/shared/config" an, obwohl der
Dateipfad konfigurierbar ist. Damit scheiterte das Schreiben stillschweigend,
sobald der Pfad abwich. Verzeichnis wird jetzt aus dem Pfad abgeleitet.
17 Pruefungen: Aliasvergabe, Liste, Aufloesung in beide Richtungen,
Gross/Kleinschreibung, alter Name bleibt gueltig, anderer Agent unberuehrt,
beide Bereiche in einer Datei ohne sich zu stoeren, Entfernen, unbekanntes Ziel
wird nicht still umgebogen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der Satellit laeuft auf einem ganz normalen Rechner — bei Stefan auf
duffy-desktop. Dort laufen typischerweise noch andere Dienste (FreeCAD-MCP,
Web-App, Dateiserver). Bisher war ausgerechnet dieser Rechner unsichtbar: man
findet sich nicht per mDNS/ARP selbst.
Er erscheint jetzt als normales Geraet — ansprechbar wie jedes andere, nur
zusaetzlich mit 🛰️ markiert und blau abgesetzt, damit klar ist, dass dort der
Satellit traegt. Abschaltbar ueber LIST_SELF=false, falls man den Traeger
bewusst heraushalten will.
Nebeneffekt, der ein echtes Problem loest: der eigene Rechner gilt damit als
"gefunden" und ist ohne Eintrag in TUNNEL_ALLOW tunnelbar. Genau der Fall, um
den es ging — der FreeCAD-MCP laeuft auf dem Satelliten-Host selbst.
Beim Zusammenfuehren bleibt die Markierung erhalten: findet mDNS denselben
Rechner nochmal, haette der Merge isSatellite sonst verschluckt. hostname kommt
aus demselben Grund mit in die erhaltenen Felder.
Dazu ein ✎-Knopf pro Geraet in der Diagnostic: Namen vergeben, damit ARIA
"duffy-desktop" ansprechen kann statt einer IP. Der Name haengt an der MAC und
ueberlebt einen DHCP-Wechsel.
8 Pruefungen: Selbst-Eintrag vollstaendig, Markierung ueberlebt den Merge,
mDNS-Infos bleiben erhalten, eigener Rechner ohne TUNNEL_ALLOW erlaubt, fremde
IP weiterhin blockiert.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ARIA sitzt woanders und kommt nicht ins Buero-Netz. Der Satellit kann beides:
er sieht das LAN und haelt eine ausgehende Verbindung zum RVS. Also reicht er
eine TCP-Verbindung durch — wie der VNC-Tunnel, nur fuer beliebige Ports.
Damit erreicht ARIA einen FreeCAD-MCP, eine Web-App, ein NAS-Interface.
Entscheidend fuer die Brauchbarkeit: die Bridge macht daraus einen GANZ
NORMALEN lokalen Port (aria-bridge:19000...). Dadurch funktioniert alles, was
sowieso TCP spricht — MCP-Client, curl, Browser — ohne Sonder-API. Jede
eingehende Verbindung bekommt einen eigenen Tunnel, parallele Verbindungen
sind also kein Problem (ein Browser oeffnet gern sechs).
Geraete-Namen: "duffy-desktop" ist ansprechbar, "192.168.1.47" nicht. Stefan
kann jedem gefundenen Geraet einen Namen geben, ARIA adressiert danach.
Schluessel ist die MAC, nicht die IP — per DHCP wandert die IP, die MAC bleibt.
Absicherung, weil das ein Weg in ein fremdes Netz ist:
- TUNNEL_ENABLED default AUS, pro Satellit.
- Ohne TUNNEL_ALLOW nur Ziele, die bei der Suche GEFUNDEN wurden. Der Tunnel
kann damit nichts ansteuern, was nicht ohnehin im LAN sichtbar ist — und
nichts im Internet.
- Obergrenze gleichzeitiger Tunnel + Reaper fuer ungenutzte (sonst bleibt eine
vergessene Verbindung offen, bis der Satellit neu startet).
- Faehigkeit 'tunnel' wird im sat_hello gemeldet, damit Diagnostic und ARIA
sehen, ob der Satellit das ueberhaupt erlaubt.
Neue RVS-Typen eingetragen (sat_tunnel_*, sat_name_*) — ohne das verwirft die
Allow-List sie still, und nichts funktioniert ohne Fehlermeldung.
16 Pruefungen gegen BEIDE echten Implementierungen (nur der RVS dazwischen ist
kurzgeschlossen): Namensaufloesung, Freigabe-Regeln, fremder Satellit
ignoriert, abgeschaltet blockt, echter Byte-Durchlauf (PONG:HALLO), unbekanntes
Ziel schliesst sauber statt zu haengen, Liste/Schliessen/Doppel-Schliessen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die README war vom Vormittag, danach kamen neun Commits. Keiner davon stand
drin.
Neu dokumentiert:
- Sprachmodell: Liste aus Anthropics Modell-Katalog, Tier vs. feste Version,
Test-Knopf samt seiner vier Ergebnisse (inkl. dem gelben Fall "nicht
erkannt", bei dem der Proxy still opus eingesetzt haette)
- Datenschutz-Schalter: die drei Sendekanaele, warum kein Neustart noetig ist,
und warum eine per docker-compose gesetzte Variable als gesperrt erscheint
- Warnung bei veralteten Proxy-Patches (die Falle hat zweimal Zeit gekostet)
- Anhang-Limit, Zeitstempel/Sortierung/Zeitraum bei den Gedanken
- Overlay: wie es ohne feste Dauer wieder weggeht, und warum der
Accessibility-Weg genommen wurde statt des naheliegenden
- flugwetter als Beispiel-Skill: Quellen mit Kosten, pc_met als dokumentierte
Kundenschnittstelle, Seitenwind gegen Pistenrichtung, Herkunft pro Zahl
Neuer Abschnitt "Secrets und was bei Anthropic landet" unter den
Sicherheitsprinzipien. Der gehoert dorthin und nicht in eine Fussnote: alles
was ARIA sieht, wird uebertragen und gespeichert, und ob daraus Trainingsdaten
werden, haengt an einer Konto-Einstellung. Dazu die drei Regeln (nie in den
Chat, Zugangsdaten in die Konfiguration, oauth_call statt Token-Herausgabe) und
ehrlich auch die Grenze: ARIA laeuft mit Root im Proxy-Container und kann
/shared/config lesen, wenn sie hinschaut.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Eine feste Anzeigedauer ist immer geraten: mal zu kurz zum Lesen, mal steht sie
laengst im Weg. `seconds=0` liess die Einblendung bisher einfach stehen.
Jetzt heisst seconds=0: bleibt, bis der Nutzer etwas tut.
- Fernbedienung: der Accessibility-Dienst bekommt onKeyEvent und raeumt die
Einblendung weg. Er gibt die Taste mit `return false` WEITER an den Film —
es geht also kein Tastendruck verloren und der Player bleibt bedienbar.
Dafuer brauchte der Dienst canRequestFilterKeyEvents + flagRequestFilterKeyEvents.
- Touch: FLAG_WATCH_OUTSIDE_TOUCH meldet eine Beruehrung ausserhalb. Die geht
dank FLAG_NOT_TOUCHABLE gleichzeitig an die App darunter durch.
- Notbremse: nach 10 Minuten verschwindet sie in jedem Fall.
Bewusst NICHT der naheliegende Weg (Overlay faengt Tasten selbst ab): dafuer
muessten FLAG_NOT_FOCUSABLE und FLAG_NOT_TOUCHABLE weg, und dann nimmt die
Einblendung dem laufenden Film JEDE Eingabe, solange sie steht. Genau das soll
sie nicht.
host_notify beschreibt seconds=0 jetzt als den richtigen Wert fuer alles zum
Lesen (Wetter, Listen, Zahlen) und die feste Dauer fuer kurze Hinweise.
APK baut durch.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der Proxy kopiert proxy-patches/*.js beim START ueber den npm-Code. Wer nach
einem git pull nur `restart` macht — oder neu startet, BEVOR der Pull durch ist
— laeuft still mit der alten Fassung weiter. Nichts deutet darauf hin: der
Container ist "Up", die Oberflaeche sieht normal aus, die Aenderung wirkt
einfach nicht.
Das hat heute zweimal Zeit gekostet: einmal wirkte ein Proxy-Fix nicht, einmal
blieb die Modell-Liste alt, obwohl der Code laengst gepullt war (Proxy
gestartet 08:51, Patches gepullt 09:28).
Die Einstellungen vergleichen jetzt die Zeitstempel der Quelldateien mit den
eingespielten und zeigen einen Hinweis samt fertigem Befehl — inklusive der
Angabe, welche Datei wann geaendert und wann eingespielt wurde. Toleranz 5s,
weil Quelle und Kopie beim Start kurz nacheinander entstehen. Ein Fehler beim
Pruefen loest bewusst KEINEN Alarm aus, sonst stuende dort eine Warnung, die
nichts ueber die Patches aussagt.
Dazu: der Datenschutz-Block sagt jetzt ausdruecklich, dass KEIN Neustart noetig
ist — die CLI liest ~/.claude/settings.json bei jedem Aufruf neu. Nur ein
gerade laufender Turn nutzt noch die alte Einstellung.
4 Pruefungen gegen den echten Container, in beide Richtungen: schweigt nach
frischem Start, erkennt eine veraltete Kopie samt Zeitstempeln, schweigt nach
Wiederherstellung.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Drei Kanaele, ueber die Claude Code zusaetzlich zur eigentlichen Anfrage Daten
verschickt — bisher nur per Hand in der docker-compose.yml abschaltbar, und
niemand konnte sehen, ob sie an sind:
DISABLE_ERROR_REPORTING Stacktraces an einen Fehler-Dienst. Bei Pro/Max ab
CLI 2.1.198 standardmaessig AN.
DISABLE_TELEMETRY Nutzungs-Metriken.
DISABLE_FEEDBACK_COMMAND /feedback sendet sonst die ganze Unterhaltung
inkl. Code — 5 Jahre Aufbewahrung.
Gesetzt wird in ~/.claude/settings.json unter "env". Die Datei ist in den
Proxy-Container gemountet, die Diagnostic erreicht sie ueber den vorhandenen
dockerExec — also kein Anfassen der docker-compose.yml und KEIN Neustart: die
CLI liest die Datei pro Aufruf.
Geprueft wird beides: was in settings.json steht UND was im Prozess wirklich
ankommt. Eine echte Container-Umgebungsvariable gewinnt gegen settings.json —
so ein Eintrag wird darum als "per docker-compose gesetzt" angezeigt und der
Haken gesperrt, statt eine Einstellung anzubieten, die nichts tut.
Geschrieben wird atomar (temp + mv) und nur der env-Block angefasst; bestehende
Einstellungen (tui, theme) bleiben. Sind alle drei abgewaehlt, verschwindet der
env-Block wieder ganz.
Der Hinweis im Panel sagt ausdruecklich, dass das NICHT die Trainings-
Einstellung ist — die steht im Anthropic-Konto und laesst sich hier nicht
umstellen. Link dorthin ist daneben.
12 Pruefungen gegen den echten Proxy-Container: lesen, setzen, Teilmengen,
JSON-Integritaet, Erhalt bestehender Werte, CLI laeuft damit, Abwaehlen raeumt
auf, Ausgangszustand wiederhergestellt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
oauth_get_token hat den access_token im Klartext als Tool-Ergebnis
zurueckgegeben. Tool-Ergebnisse sind Teil der Unterhaltung — der Token ging
damit an Anthropic und lag je nach Konto-Einstellung 30 Tage oder 5 Jahre dort.
Neu: das Brain fuehrt den API-Aufruf SELBST aus.
- `oauth_call(service, url, method, body)` haengt die Authorization an,
schickt den Request und gibt nur die Antwort zurueck. Der Token verlaesst
den Brain-Prozess nicht.
- `oauth_get_token` sagt nur noch, OB authentifiziert ist und wie lange noch.
Refresh laeuft weiter automatisch.
- Skills bleiben unveraendert: die holen den Token serverseitig ueber
{BRAIN_INTERNAL_URL}/oauth/<service>/token — der laeuft nie durch ein
Gespraech.
Host-Sperre als Sicherheitskern: die URL kommt vom Modell, also koennte ein
Aufruf den Token sonst an einen beliebigen Server schicken. Erlaubt sind nur
Hosts, die zum Provider gehoeren (aus auth_url/token_url, plus optionale
api_hosts). Verglichen wird auf den letzten zwei Labels, NICHT per endswith —
"boesespotify.com" endet sonst auch auf "spotify.com". Dazu: nur https (sonst
ginge der Token im Klartext ueber die Leitung) und nur die ueblichen Methoden.
19 Pruefungen, darunter die Angriffsvarianten: boesespotify.com,
spotify.com.angreifer.de, accounts.spotify.com.evil.io, spotify.co, leerer
Host — alle blockiert; api.spotify.com und abschliessender Punkt erlaubt.
System-Prompt und seed_rules nachgezogen, sonst erklaert ARIA sich das alte
Verhalten selbst. Beide sagen jetzt zusaetzlich ausdruecklich: Secrets gehoeren
nie in den Chat, und ein Secret nie in einer Antwort wiederholen. Genau so ist
hier naemlich ein client_secret abgeflossen — nicht ueber ein Tool, sondern
weil es eingetippt und dann zurueckzitiert wurde.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Bisher liess sich nicht nachsehen, ob eine Modell-Einstellung ueberhaupt
greift. Der Proxy hat die Information sogar aktiv weggeworfen:
normalizeModelName() nahm den echten Namen aus modelUsage (z.B.
"claude-opus-5-5") und schrieb ihn auf "claude-opus-4" um. Das `model`-Feld
der Antwort log also — und damit war jede Ueberpruefung unmoeglich.
- normalizeModelName gibt den echten Namen durch. Im OpenAI-Protokoll soll
`model` das Modell nennen, das geantwortet HAT; ein erfundener Name ist
schlechter als keiner.
- Zusatzfelder aria_model / aria_error / aria_context_window / aria_max_output
aus modelUsage.canonicalModel. Noetig, weil die CLI bei einem unbekannten
Modell gar nicht bis zum Call kommt und ihre Begruendung einfach in den
Antworttext legt — ohne Flag waere ein Fehlschlag nicht von einer Antwort
zu unterscheiden.
- Knopf "🔬 Testen" neben Dropdown und Freitextfeld. Er schickt eine echte
Mini-Anfrage durch den GANZEN Weg (Diagnostic → Proxy → extractModel →
claude CLI → Anthropic).
Ausdruecklich NICHT gemacht: das Modell nach seiner eigenen Version fragen.
Darauf ist kein Verlass — Modelle kennen ihren Versionsstring oft nicht und
raten. Und den Dropdown-Wert zurueckzugeben waere sinnlos. Die Wahrheit kommt
aus modelUsage der CLI.
Vier unterscheidbare Ergebnisse:
Tier-Alias gruen — zeigt die aufgeloeste Version ("opus" → Opus 5.5)
exakte Version gruen — angefragt == geantwortet
nicht erkannt GELB — der Proxy hat still "opus" eingesetzt; warnt
ausdruecklich davor, die ID so zu setzen
ungueltig ROT — CLI-Begruendung im Klartext
Der gelbe Fall war wichtig: ein Name, der nicht wie ein Claude-Modell aussieht,
faellt auf "opus" zurueck und haette sonst als Erfolg gegolten — man setzt dann
eine ID, die nie benutzt wird, und merkt es nie.
Geprueft gegen ECHTE CLI-Ausgaben aus dem Proxy-Container (9 Faelle: Alias,
exakte Version, Tippfehler) plus 7 Faelle fuer die Anzeige-Logik. Nebenbefund:
`--model opus` loest derzeit auf claude-opus-5-5 auf.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Zwei Fehler. Der zweite war der schlimmere.
1) Die Liste war handgepflegt und damit garantiert veraltet.
Sie kannte "Opus (aktuell: Opus 5)" — waehrend es laengst Opus 5.5,
Sonnet 5.5 und Fable 5.1 gab. Der Knopf "↻ Aktualisieren" las nur eine
lokale Datei neu und aktualisierte damit gar nichts.
Jetzt kommt die Liste aus Anthropics eigenem Modell-Katalog
(downloads.claude.ai/model-catalog/v1/catalog.json, Surface 'cc') —
dieselbe Quelle, aus der sich Claude Code selbst bedient. Oeffentlich,
ohne API-Key (die Models-API braucht einen; mit dem Max-Abo gibt es keinen).
6h-Cache plus Datei-Cache, der auch offline und bei abgelaufenem TTL
einspringt: eine etwas alte echte Liste ist besser als keine.
Die Tier-Aliase (opus/sonnet/haiku/fable) bleiben vorne und bleiben die
Empfehlung — sie folgen automatisch der neuesten Version. Darunter die
exakten Versionen, aeltere ausdruecklich als solche markiert.
2) Eine feste Version liess sich faktisch nicht waehlen.
extractModel() hatte eine MODEL_MAP und fiel fuer alles Unbekannte STILL
auf "opus" zurueck. Wer "claude-opus-5-5" setzte, bekam ohne jede Meldung
das Tier-Default. Schlimmer noch: claude-opus-5 und claude-fable-5 standen
selbst in der Map und wurden auf ihr Tier eingeschmolzen — eine bewusst
gewaehlte aeltere Version wurde also durch die neueste ersetzt.
Volle Modellnamen gehen jetzt unveraendert an die CLI. Die versteht sie
("--model: an alias for the latest model or a model's full name") und
meldet sich selbst klar, wenn sie einen Namen nicht kennt — ehrlicher als
ein stilles Downgrade. Nur echter Muell faellt noch auf "opus", und das
wird geloggt.
Nachgewiesen gegen den LIVE-Katalog und die echte CLI im Proxy-Container:
20 Pruefungen gruen, u.a. dass alle 12 gelieferten exakten Versionen den Proxy
unveraendert passieren. `claude --print --model claude-opus-5-5` antwortet.
Stefans aktive Einstellung ist der Alias "opus" — am laufenden Betrieb aendert
sich dadurch nichts.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der Android-Agent konnte schon immer ein Bild MIT Text einblenden
(OverlayView.show nimmt ein imageB64), aber ARIA kam nicht dran: in der
Parameter-Liste von host_notify fehlte das Feld einfach. Die Faehigkeit war
gebaut und unerreichbar.
ARIA gibt jetzt image_path an (ein Pfad unter /shared/uploads/, damit arbeitet
sie sowieso) und das Brain wandelt die Datei nach base64 — statt ARIA
megabyteweise base64 durch den Tool-Call schieben zu lassen. Pfad-Praefix wird
geprueft, und ueber 4 MB wird abgelehnt: fuer eine Einblendung auf einem
Fernseher ist mehr sinnlos und blaeht die WS-Nachricht auf.
Nur Android-Agenten koennen das; die Beschreibung sagt das ausdruecklich.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Zwei Dinge, die bisher nur im Code bzw. nur in der DB standen.
Anhang-Limit (Einstellungen → System & Wartung):
- Das Limit war eine Env-Variable mit 20 MB Default — zum Anheben musste man
die .env editieren und das Brain neu starten. Jetzt steht es in runtime.json
und das Brain liest es bei JEDEM Upload neu: Aenderung greift sofort.
- Reihenfolge: runtime.json > ENV > Default. Anders als beim OpenAI-Endpunkt
gewinnt hier NICHT die .env — dort erzwingt ein Docker-Port-Mapping das,
hier gibt es keinen solchen Zwang, und eine Einstellung die nichts tut waere
schlimmer als keine.
- Default von 20 auf 64 MB. Genau so viel holt die App auch auf ausdruecklichen
Tipp noch herunter (TAP_DL_MAX_BYTES); darueber warnt die UI, verbietet es
aber nicht — der Anhang liegt dann sauber auf dem Server, ist mobil nur nicht
mehr ladbar.
- Neuer Endpunkt GET /attachments/limit. Das fest eingetippte "max 20 MB pro
Datei" im HTML ist weg — es stimmte nach jeder Aenderung nicht mehr.
- Die Fehlermeldung nennt jetzt MB statt Bytes und sagt, wo die Einstellung ist.
Datum/Uhrzeit bei Gedanken:
- created_at/updated_at lagen schon immer in der DB und wurden ausgeliefert —
nur nie angezeigt. Jede Zeile zeigt jetzt "angelegt <Zeit>" und, falls
abweichend, "geaendert <Zeit>" plus ein relatives "(vor 3 Std)". Damit sieht
man auf den ersten Blick, was der letzte Eintrag war.
- Sortier-Dropdown: nach Typ gruppiert (wie bisher) oder nach Anlage/Aenderung
auf- und absteigend. Bei Zeit-Sortierung wird die Liste flach dargestellt —
man will sehen was zuletzt passiert ist, nicht in welche Schublade es gehoert.
- Zeitraum-Filter (🕒) mit von/bis, umschaltbar zwischen angelegt und geaendert,
plus Schnellwahl Heute / 7 / 30 Tage. Gilt auch fuer Such-Treffer, damit
"suche X, aber nur letzte Woche" geht. Zuklappen schaltet ihn aus, und das
✕-Zuruecksetzen raeumt ihn mit auf (sonst filtert er unsichtbar weiter).
Beides gegen den echten Code getestet: 7 Faelle fuers Limit (inkl. kaputter
runtime.json und einem 50-MB-PDF an beiden Grenzen), 10 fuer Sortierung und
Zeitraum.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die README war auf dem Stand vom 24.09. Seitdem sind ~60 Commits dazugekommen,
von denen ganze Baustellen gar nicht auftauchten.
Neu dokumentiert:
- Android-Agent 📱📺 (eigener Abschnitt): eine APK fuer Handy und Fire TV —
sehen, steuern, ausgeben (Overlay + ARIAs echte Stimme), Audio-Fokus,
Sprachdialog, Turn-Ownership im Broadcast-Relay, fester Signaturschluessel,
Ausrollen per Satellit via ADB inkl. Fern-Provisionierung
- GUI-Steuerung der Desktop-Host-Agenten (capability-gated)
- Jellyfin-Integration (mehrere Server, API statt Klick-Weg)
- OpenAI-Endpunkt fuers lokale LLM + openhands-Profil, inkl. der Regel
".env gewinnt immer -> Diagnostic-Felder nur lesend"
- Agent-Historie und Auslastungs-Monitor in der Diagnostic
- App: Teilen-Ziel, Sprachnachricht zu Anhaengen, Zwischenruf per Sprache
- Trigger: Projekt-Kontext + ehrlicher Zustand in trigger_list
- Roadmap "Phase C" samt der fuenfteiligen Ursachenkette hinter den verlorenen
Sprachnachrichten — jede Ursache sah fuer sich plausibel aus, das ist
dokumentationswuerdig
Korrigiert (waren schlicht falsch):
- "Bildanalyse eingeschraenkt, ARIA sieht den Dateipfad, nicht das Bild" —
widersprach der eigenen Roadmap; Vision laeuft
- "Grosse Dateien >5MB koennen WebSocket-Limits ueberschreiten" — die echten
Grenzen sind jetzt 1500 MB Transport, 25 MB Auto-Download, 64 MB auf Tipp
- Audio-Format: Live-PCM-Streaming ist der Normalweg, AAC/MP4 nur noch Fallback
Neu als Limitierung benannt, weil heute gefragt: die Sprachaufnahme ist NICHT
wiederaufsetzbar — ein Verbindungsabbruch mitten in der Aufnahme verliert das
Stueck, es wird nicht gepuffert. Gleiches gilt fuer die TTS-Richtung.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der Endpointer hat seine EIGENE Rechenzeit als Stille gezaehlt.
Der Tick-Loop laeuft alle 200ms und ist die einzige Stelle, die akustische
Sprach-Energie misst (last_voice_at). Er hat aber auf die Zwischen-
Transkription gewartet — und die laeuft jedes Mal ueber den KOMPLETTEN Buffer.
Bei 10s Audio harmlos, bei zwei Minuten dauert sie mehrere Sekunden. In dieser
Zeit tickte nichts, danach war `now - last_voice_at` um die ganze Rechenzeit
groesser als endpoint_ms (5s) — Endpoint mitten im Satz, obwohl durchgehend
gesprochen wurde. Deshalb traf es genau die LANGEN Nachrichten, und zwar immer
spaeter werdend je laenger die Aufnahme.
Nachgewiesen: die Nachricht vom 02.10. 21:28 (1231 Zeichen) war die einzige mit
reason=endpoint statt stream_end und endet mitten im Satz ("...weil ich
weiss..."). Alle vollstaendigen Nachrichten im Thread haben reason=stream_end,
also den Stop-Knopf.
Fix:
- Zwischen-Transkription laeuft als eigener Task. Der Tick bleibt frei und
misst weiter alle 200ms — die Rechenzeit kann nicht mehr als Stille gelten.
Laeuft noch eine, wird keine zweite gestartet.
- Zwischen-Transkriptionen sehen nur noch die letzten 30s an. Damit bleibt ihre
Kosten konstant statt mit der Aufnahmelaenge zu wachsen. Der FINALE Text
entsteht unveraendert aus dem gesamten Buffer mit beam_size=5 — es geht kein
Wort verloren. stt_partial bekommt dafuer ein Feld 'windowed'.
- _finalize und drop brechen eine laufende Zwischen-Transkription ab, damit der
finale Text nicht hinter ihr auf den GPU-Lock warten muss.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der Agent meldete "gesprochen", sobald die TTS-Anfrage im Socket lag. Ob sie
ueberhaupt rausging, ob der Server antwortete oder ob ein einziger Ton kam,
hat nie jemand geprueft. Auf dem Fire TV blieb es damit still, waehrend ARIA
"erledigt" sagte — ein Fehler, der sich nicht melden kann.
Drei Ursachen:
- OkHttps send() WIRFT NICHT, sondern gibt false zurueck, wenn die Verbindung
zu ist. Der Rueckgabewert wurde verworfen: Senden ins Leere sah aus wie
Erfolg. send() gibt das jetzt durch, requestTts wirft bei abgelehntem Senden.
- Niemand wartete auf Audio. Neu: awaitSpeechStart() wartet, bis fuer diese
messageId wirklich Ton laeuft, sonst Fehler mit Grund.
- Warten darf NICHT im WS-Lese-Thread passieren: handle() laeuft dort, und das
erwartete audio_pcm kommt ueber genau diese Verbindung — wir haetten uns
selbst ausgehungert. speak/notify laufen jetzt in einem eigenen Thread und
schicken ihr host_result von dort.
Brain-seitig haben speak/notify 40s statt 20s Zeit, damit die ehrliche Antwort
(TTS-Render + Uebertragung) nicht in den Timeout laeuft.
APK baut durch (Gradle, nur die zwei bekannten Deprecation-Warnungen).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Zwei Fehler, die zusammen wie "der Timer hat nicht gefeuert" aussahen.
1) Trigger hatten KEIN Projekt. Beim Feuern ging die Antwort ohne projectId
durch _process_core_response — also immer in den Hauptchat, auch wenn der
Timer mitten in einem Projekt-Thread gestellt wurde. Im Projekt blieb es
still, und es sah aus wie "nicht gefeuert". Jetzt wird das Projekt des
Requests mit angelegt, der getriggerte Turn laeuft darin, und die Antwort
kommt dort zurueck.
2) trigger_list zeigte nur "aktiv" / "DEAKTIVIERT" und verschwieg fire_count
und last_fired_at. Ein One-Shot-Timer wird NACH dem Feuern automatisch
deaktiviert — "hat sauber gefeuert" und "war nie an" sahen damit identisch
aus. ARIA hat genau das falsch gelesen und berichtet, sie habe vergessen den
Timer zu aktivieren, obwohl er puenktlich gefeuert hatte. Die Ausgabe nennt
jetzt ausdruecklich "SCHON GEFEUERT (Nx, zuletzt <Zeit>)" plus den Kontext,
in dem die Antwort landet.
Nachgewiesen am Fall flugwetter-whv-freitag-0900: gefeuert 07:00:05 UTC
(= 09:00 lokal), Antwort 46s spaeter, fire_count=1 — aber active=false im
Manifest und die Antwort im Hauptchat statt im Projekt-Thread.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Bisher war die Eingabeleiste ein Entweder-oder: sobald Text im Feld stand oder
ein Anhang dranhing, verschwand das Mikro. Damit ging genau das nicht, was man
eigentlich will — ein Bild anhaengen und den Auftrag dazu SPRECHEN. Und ein
Zwischenruf ging nur getippt.
Das Mikro ist jetzt immer da; Senden-Pfeil und Mund-/Ohr-Knoepfe weichen je
nach Lage, damit die Zeile nicht ueberlaeuft.
Anhang + Sprachnachricht:
- Mikro antippen mit wartenden Anhaengen laedt sie SOFORT hoch (parallel zum
Reden) und markiert sie mit awaitVoice + clientMsgId.
- Die Bridge schickt solche Anhaenge nicht nach 0.8s alleine ans Brain, sondern
wartet auf den stt_endpoint und fuehrt Anhang + gesprochenen Satz zu EINEM
Turn zusammen. Ohne das sah ARIA ein Bild ohne Auftrag und danach einen Satz
ohne Bild.
- Der Merge ist strikt an die clientMsgId gebunden (require_match): eine
Sprachnachricht, die zufaellig waehrend eines fremden Uploads fertig wird,
reisst dessen Anhaenge nicht an sich. Der Text-Pfad behaelt seinen Fallback.
- Bild und gesprochener Text landen in EINER Bubble (gemeinsame audioRequestId).
- Klappt das Mikro nicht, bleibt die Bubble mit den Bildern stehen statt zu
verschwinden — die Dateien sind ja schon auf dem Server.
- Das Notfall-Fenster (420s) liegt ueber dem Aufnahme-Hard-Cap von 5 Minuten,
sonst waeren die Anhaenge bei einer langen Aufnahme vorher alleine raus.
Zwischenruf per Sprache:
- Der 📣-Knopf erscheint jetzt immer, wenn ARIA im Kontext arbeitet. Mit Text
schickt er sofort (wie bisher), ohne Text schaltet er die naechste Aufnahme
scharf (sichtbar hervorgehoben, gilt fuer genau eine Aufnahme).
- Eine so markierte Aufnahme geht per stt_stream_start als interject raus; die
Bridge schiebt sie in den laufenden Turn statt sie anzustellen.
- Dabei wird der laufende Turn NICHT abgebrochen (das war der Sinn) — nur die
Wiedergabe stoppt, damit ARIA nicht ins offene Mikro redet.
- Die Bubble zeigt 📣 Zwischenruf statt 🎤, damit man nicht auf eine eigene
Antwort wartet.
Merge-Logik gegen den echten Bridge-Code getestet (6 Faelle), tsc sauber.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die Absturzschleife (alle ~70s, stundenlang) war selbsttragend:
App startet → Auto-Re-Download fordert 2s spaeter ALLE fehlenden Anhaenge an,
ohne Groessen-Grenze → Bridge schickt das 150-MB-Video als ~200 MB base64 in
EINER WebSocket-Nachricht → die App muss das puffern und durch JSON.parse
schicken → nativer OOM (kein JS-Fehler, darum nie ein Stacktrace) → Android
startet den Vordergrund-Dienst neu → App startet → von vorn.
Dieselbe Nachricht hat parallel whisper/f5tts/voxtral mit Code 1009 umgebracht
— darum lag der Absturz immer direkt hinter dem Audio-Abbau, und darum kam
jede gerade laufende Sprachaufnahme nie an.
Drei Bremsen:
- Auto-Re-Download ueberspringt alles ueber 25 MB. Bleibt als "150 MB —
tippen zum Laden" stehen; der User entscheidet.
- Ausdrueckliches Antippen bremst bei 64 MB mit einer ehrlichen Meldung samt
Server-Pfad, statt die App zu killen.
- Der Brotkrumen wird von der Crash-Meldung nicht mehr ueberschrieben. Bisher
merkte sich der zweite Absturz nur noch "letzte Aktivitaet: Crash-Meldung" —
in einer Schleife war nach dem ersten Durchlauf jede Spur weg.
Diagnose kam aus /shared/logs/app.log (app_log via RVS), kein ADB noetig.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
sat_hello und worker_hello kommen im Takt von ~25-30s erneut und wurden jedes
Mal mit "online" geloggt. Dadurch war das Bridge-Log praktisch unlesbar: die
interessanten Zeilen (Fehler, STT, Turns) gingen zwischen hunderten
identischen Meldungen unter.
Jetzt wird nur geloggt, wenn eine Box/ein Satellit NEU ist oder sich etwas
Echtes geaendert hat (Modell, GPUs, Standort, caps, control) — so wie es
host_hello schon vorher gemacht hat.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der RVS ist ein Broadcast-Relay — bisher bekam jeder Client im Raum jede
Nachricht. Bei einem Datei-Re-Download war das fatal: ein 150-MB-Video wird
als base64 ~200 MB gross und ging an ALLE Clients, auch an die STT/TTS-Worker.
Die sind daran mit Code 1009 (message too big) gestorben und haben die gerade
laufende Sprachaufnahme mitgerissen — die Ursache von "erste Sprachnachricht
kommt nicht durch".
Wer eine Anfrage mit requestId stellt, wird jetzt gemerkt; die Antwort geht
nur an ihn zurueck (file_response, file_zip_response,
file_version_download_response, brain_response). Unbekannte requestId wird
wie bisher gebroadcastet, ein weggefallener Fragender verworfen statt an alle
geschickt.
Verifiziert mit drei WS-Clients gegen einen lokalen RVS: der Fragende bekommt
seine Antwort, der Unbeteiligte nicht, chat bleibt Broadcast.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
duffyduckandClaude Opus 5.5