Root Cause fuer 'Empty response (no content or reasoning)'-Retries im
hermes-agent-Log noch nicht zweifelsfrei geklaert -- der bisherige Code
konnte einen Subprocess-Abschluss ohne 'result'-Event (code===0, kein
Fehler-Chunk) still mit nur [DONE] beenden, was beim Client exakt wie eine
leere Antwort aussieht. Jetzt: immer ein sichtbarer Fehler-Chunk + Log-Zeile
bei fehlendem result-Event, und ein Debug-Log bei jedem result-Event mit
subtype/is_error/Textlaenge. Naechster Repro-Versuch mit docker logs
hermes-proxy zeigt damit die echte Ursache.
Root Cause (verifiziert am echten npm-Paket claude-max-api-proxy@dist):
handleStreamingResponse() in server/routes.js baut SSE-Chunks komplett
inline aus den rohen content_delta-Tokens und ruft dabei NIE den
<tool_call name="X">{json}</tool_call>-Parser aus adapter/cli-to-openai.js
auf (_parseToolCalls / cliResultToOpenai) -- der laeuft bisher nur im
Non-Streaming-Pfad (handleNonStreamingResponse). Hermes fragt aber immer
mit stream:true an. Folge: Claude gibt die Tool-Call-Tags korrekt als Text
aus (das hatten wir zuletzt gefixt), aber sie kommen nie als echtes OpenAI
tool_calls[]-Array bei Hermes an -- kein Tool wird ausgefuehrt, kein
Ergebnis geht zurueck in die Session, Claude haeuft neue <tool_call>-
Bloecke an weil nie eine Antwort kommt ("es passiert nicht viel", vier
Tags in einer Antwort).
Bisher gab's fuer routes.js nur einen minimalen sed-Patch (systemPrompt
durchreichen), bewusst ohne ARIAs vollen routes.js-Patch (der haengt an
ARIA-Bridge-spezifischen Extras wie Killswitch/Live-Stream). Der Fehler
sitzt aber strukturell in handleStreamingResponse selbst, sed reicht nicht
mehr.
Fix: proxy-patches/routes.js -- eigene schlanke Variante ohne Bridge-
Extras, komplett per cp ersetzt statt sed. handleStreamingResponse
streamt keine rohen Tokens mehr live, sondern wartet auf das volle
"result"-Event und baut daraus per cliResultToOpenai() (dieselbe Logik
wie Non-Streaming) den finalen Chunk inkl. tool_calls[]/finish_reason.
Kostet den Live-Tipp-Effekt, aber Tool-Calls funktionieren jetzt
ueberhaupt erst. systemPrompt-Fix ist in der neuen Datei bereits
enthalten (ersetzt den alten sed dafuer).
Lokal verifiziert: node --check auf der neuen Datei, und
cliResultToOpenai() gegen Stefans exakten Beispiel-Text (vier
zusammenhaengende <tool_call>-Tags) getestet -- liefert korrekt 4
tool_calls + finish_reason=tool_calls.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
"No such tool available" + Session-Neustart-Vorschlag trotz aktivem Toolset
(Verbindungstest komplett gruen). Ursache: Claude Code CLI versucht die im
System-Prompt nur als TEXT beschriebenen Tools (spotify_*, ...) ueber sein
eigenes natives Funktionsaufruf-/ToolSearch-System zu finden/aufzurufen,
weil das "# Verfuegbare Tools"-Listenformat wie eine echte Tool-Registrierung
aussieht. Da nichts davon ueber die Anthropic-API als tools-Parameter
registriert ist (nur Prompt-Text), schlaegt das immer fehl -> Claude
interpretiert den Fehler faelschlich als "nicht verbunden/nicht geladen".
Fix: expliziter Warnabsatz im Tool-Block, der genau das verbietet und klar
macht dass "No such tool available" ein Bedienfehler (falsches Aufrufmuster)
ist, kein Verbindungsproblem. Analog zu ARIAs eigenem System-Prompt, der
diese Klarstellung schon enthaelt.
Live-Test (spotify_test_connection.py) bestaetigte: Login, Toolset und
API-Erreichbarkeit sind alle OK. Trotzdem antwortete Claude im Chat
'Tools in Werkzeugliste beschrieben, aber nicht verbunden/aktiv' - eine
frei erfundene Einschraenkung, die nirgends im injizierten System-Prompt
stand (der beschreibt nur Namen/Schema der Tools, nichts zum Verbindungs-
status). Klassisches Modell-Hedging bei Unsicherheit ueber Backend-Status.
Ergaenzt im Tool-Block: expliziter Hinweis dass alle gelisteten Tools
bereits authentifiziert/einsatzbereit sind und ohne Rueckfrage zur
Verbindung genutzt werden sollen, Fehler nur anhand echter Tool-Antworten
(z.B. 401/403) melden.
Verifiziert (lokal): claude --system-prompt "" faellt komplett auf die eigene
Default-Identitaet zurueck (eigene native Tools, eigene Account-Connectors) statt
mit leerem Prompt zu laufen. Das erklaert exakt das beobachtete Symptom bei Hermes
(Claude nennt Gmail/Calendar/Drive + Cron/Task, kennt aber keinerlei Spotify-Tool).
Hypothese: extractSystemPrompt(request.messages, request.tools) liefert fuer
Hermes' Requests einen leeren/zu duennen String -- entweder weil Hermes gar kein
tools-Feld mitschickt (Spotify-Toolset in hermes tools nie aktiviert?) oder weil
keine system-Message im erwarteten Format ankommt. Logging zeigt messageRoles,
toolsCount, toolNames und systemPromptLen/-Preview in docker logs hermes-proxy --
damit klaeren wir das anhand echter Daten statt weiter zu raten.
ARIA
