ZeroClaw setzt einen unterbrochenen Stream nie fort. Ob die Runde erneut gesendet wird, hängt davon ab, wie viele Kandidaten dein Profil hat; und in der einzigen aktuellen Version entspricht das nicht ganz dem, was die Dokumentation verspricht. ZeroClaws Dokumentation für v0.8.5 (veröffentlicht am 5. September 2026) sagt, dass ein Stream, der vor jeglicher Ausgabe fehlschlägt, ohne Streaming erneut versucht wird und einer, der nach der Ausgabe fehlschlägt, nie erneut abgespielt wird. Bei einem Lauf am 1. Oktober 2026 gegen einen Endpunkt, der den Stream mitten in der Antwort abbrach, tat der Terminal-Client von v0.8.5 etwas Einfacheres: Mit einem Kandidaten sendete er weder vor noch nach dem Erscheinen von Text einen erneuten Versuch; mit einem zweiten Kandidaten sendete er die Runde ohne Streaming erneut an dieses zweite Modell — sogar nachdem ein Teil der Antwort bereits auf dem Bildschirm stand. Die geführte Wiederherstellung nach teilweiser Ausgabe ist eine offene Feature-Anfrage, die noch keine Designfreigabe erhalten hat. Die nützliche Frage lautet daher nicht, wie du ZeroClaw zum Wiederholen bringst, sondern ob deine Runde für dich sicher erneut gesendet werden kann und was der abgebrochene Versuch bereits gekostet hat.
Zwei Hinweise zum Geltungsbereich, bevor irgendetwas davon praktisch nutzbar ist. Der ausgeführte Test ist eng begrenzt: das Release-Binary v0.8.5 im interaktiven Terminalmodus, ein OpenAI-kompatibler Endpunkt und ein lokaler Testserver, der den Stream absichtlich schloss — die Ergebnisse folgen unten. Channels, das Gateway-WebSocket, RPC, ACP, der Anthropic-Slot und echte Ausfälle von Anbietern wurden nicht ausgeführt. Jede andere Aussage stammt aus dem Repository am Release-Tag v0.8.5, aus der versionsgebundenen Dokumentation unter docs.zeroclaw.com/v0.8.5/ oder aus datierten Upstream-Issue-Berichten, alles am 21. September 2026. Pinne diese URL außerdem selbst: Die README verweist auf den Pfad /master/, dessen HEAD sechzehn Tage neuer als das Release ist und ihm genau bei diesem Thema widerspricht, während /latest/ 404 zurückgibt. ZeroClaw bezeichnet hier die Laufzeit zeroclaw-labs/zeroclaw; wenn du nicht sicher bist, dass du diese verwendest, grenzt ZeroClaw vs OpenClaw sie von den Projekten und Forks ab, die denselben Namen tragen.
Vier Marker in v0.8.5, und nur einer davon ist das Netzwerk
Bevor du etwas entscheidest, lies, welchen Marker du tatsächlich erhalten hast. ZeroClaws englische Locale-Datei in v0.8.5 definiert diese als unterschiedliche Fluent-Schlüssel unter einem Header-Kommentar, der besagt, dass sie bei einer vorzeitig beendeten Runde an die Assistant-Ausgabe angehängt oder als solche gespeichert werden und Endbenutzern über jeden Transport hinweg angezeigt werden — Channels, WS, RPC, ACP und CLI.
| Marker | Fluent-Schlüssel | Was er dir sagt |
|---|---|---|
[stream interrupted] | turn-stream-interrupted | Der Transportstream ist mitten in der Runde abgebrochen. Niemand hat auf Stopp gedrückt. |
[interrupted by user] | turn-interrupted-by-user | Eine Unterbrechung durch einen Menschen. |
[turn cancelled via client] | turn-cancelled-client-rpc | Der Channel, nicht der Akteur. Der eigene Codekommentar besagt, dass sowohl Unterbrechungen durch Menschen als auch programmatische Abbrüche durch Clients über diesen Pfad eintreffen; die Formulierung benennt daher den Channel. |
[interrupted by user before this tool produced a result] | turn-tool-interrupted-before-result | Ein Tool wurde beendet, bevor es eine Antwort zurückgab. |
Ein fünfter Schlüssel, turn-failed = [turn failed], existiert in derselben Datei auf master, aber nicht in der Locale-Datei von v0.8.5; ein veröffentlichtes Build gibt ihn daher nicht aus. Ein Verhalten ist wichtig, weil es verändert, was du anschließend lesen kannst: Die Runden-Engine speichert den Teiltext mit angehängtem Marker nur dann, wenn dieser Teiltext nicht leer ist. Eine Runde, die Reasoning oder vom Anbieter vorab ausgeführte Tool-Ereignisse, aber keinen sichtbaren Text erzeugt hat, speichert überhaupt nichts — der Codekommentar beschreibt die Speicherung als Festschreiben dessen, was der Verbraucher bereits gesehen hat. Andere Locales enthalten dieselben Schlüssel mit übersetzten Werten; die wörtliche englische Zeichenfolge in eckigen Klammern wird daher in einer nicht-englischen Installation nicht angezeigt.
Wo die Wiederholungsgrenze tatsächlich liegt
Die gesamte Entscheidung läuft auf eine Frage hinaus: Hatte bereits etwas einen unveränderlichen Ereignissenken erreicht?
| Was passiert ist | Dokumentiertes Verhalten in v0.8.5 | Hinweis |
|---|---|---|
| Der Stream schlägt vor jeglicher sichtbaren Ausgabe fehl | Die Laufzeit versucht den gesamten Aufruf über den Nicht-Streaming-Pfad erneut und durchläuft erneut den vollständigen Zuverlässigkeitsablauf | Dokumentiert, aber nicht das, was bei einer Einrichtung mit einem einzigen Kandidaten im veröffentlichten Build beobachtet wurde — siehe unten |
| Der Stream endet ohne abschließenden Text und ohne Tool-Aufrufe | Eine semantisch leere Antwort, keine Antwort. Wenn das Ergebnis als sicher zum erneuten Abspielen markiert ist und provider_retries ungleich null ist, wird ein Nicht-Streaming-Wiederherstellungsaufruf an denselben Anbieter und dasselbe Modell gesendet und einmal verarbeitet | In v0.8.5 über Pull Request #10602 ausgeliefert, am 4. September 2026 zusammengeführt. Gilt für leere Streams, nicht für Streams, die mitten in der Ausgabe abbrechen |
| Text, Reasoning oder vorab ausgeführte Tool-Ereignisse haben bereits einen unveränderlichen Ereignissenken erreicht | StreamInterruptedAfterOutput. Die Laufzeit spielt die Anfrage nicht erneut ab, und bereits an den Verbraucher weitergeleiteter Text ist alles, was als gespeicherter Teiltext der Assistant-Nachricht bestehen bleibt | Absichtlich und auf master identisch. Durch einen Regressionstest abgesichert, der festlegt, dass ein Streamfehler nach sichtbarer Ausgabe die Runde ohne Fallback-Wiederholung fehlschlagen lassen muss |
| Jedes der oben genannten Ereignisse | Der Stream wird einmal geöffnet, und Einträge werden nach seinem Start nicht mehr gewechselt | Die Wiederherstellung ist immer eine neue Anfrage. Keine Anbieterfamilie, auch nicht der benutzerdefinierte Slot, verfügt über einen Fortsetzungspfad |
Die vorhandenen Stellschrauben gelten global, nicht pro Endpunkt. [reliability] enthält provider_retries, dokumentierter Standardwert 2, sowie provider_backoff_ms, Standardwert 500; die Lifecycle-Dokumentation besagt, dass jeder materialisierte Eintrag bis zu provider_retries + 1-mal versucht wird. Die Konfigurationsreferenz von v0.8.5 dokumentiert daneben keine Wiederholungsüberschreibung pro Anbieter oder Alias. Verlass dich auch nicht auf den Schlüssel-Pool: Die Dokumentation von v0.8.5 sagt, dass reliability.api_keys heute kein funktionierendes Failover ist, weil der Wrapper nach einem wiederholbaren Rate-Limit einen alternativen Schlüssel auswählt und protokolliert, ihn aber nicht auf den erstellten Anbieter anwenden kann; der Wiederholungsversuch verwendet daher weiterhin die ursprünglichen Zugangsdaten. Ein zweiter Schlüssel, den du in Erwartung einer Rettung hinzugefügt hast, bietet keine.
Auf einen Endpunkt zu zeigen ist die Konfiguration, die am stärksten betroffen ist
Dies ist die schärfste Grenze für alle, die ZeroClaw gegen ein einzelnes Gateway oder den Endpunkt eines einzelnen Anbieters betreiben, denn ein Endpunkt ist per Definition eine Zuverlässigkeitskonfiguration mit einem einzigen Kandidaten. Issue #10736 berichtet, dass ein Streamfehler vor der Ausgabe in dieser Konstellation im veröffentlichten Build einen Fallback auf Nicht-Streaming-Chat protokolliert und ihn anschließend nie sendet; die Runde wird mit All model providers/models failed after 0 failure event(s) beendet. Das Issue wurde am 18. September 2026 geschlossen — nachdem v0.8.5 veröffentlicht worden war —, daher befindet sich die Korrektur nur auf master. Bei einem Lauf am 1. Oktober 2026 verhielt sich die veröffentlichte v0.8.5 genau wie im Issue beschrieben: eine Anfrage, dann dieser Fehler, unabhängig davon, ob der Stream vor oder nach dem Erscheinen von Text abbrach.
Hier widersprechen sich zwei offizielle Darstellungen, und beide sollten berücksichtigt werden. Das Architektur-Dokument von v0.8.5 verspricht den Nicht-Streaming-Wiederholungsversuch; das Issue zeigt, dass der veröffentlichte Build ihn nicht ausführt, und sein Abschnitt zum erwarteten Verhalten fordert, dass das Log einen Fallback nur dann behauptet, wenn tatsächlich einer versucht wird. Master fügt dann eine Wiederherstellungserlaubnis für einen einzigen Kandidaten hinzu, die das Release nicht besitzt — und Issue #10787 sagte, diese Erlaubnis werde unabhängig von provider_retries mit RetryDecision::Admit(0) gewährt und ohne Backoff; ein überlasteter Upstream wurde daher sofort erneut in dasselbe Überlastungsfenster gesendet. Das Issue wurde am 26. September 2026 als abgeschlossen geschlossen — auf master, nach v0.8.5, also ebenfalls in keinem Release. Masters Verhalten ändert sich weiterhin; plane nicht darauf.
Die dokumentierte Form einer Abhilfe ist eine Konfiguration statt einer Einstellung: Gib dem Profil einen zweiten Kandidaten, damit der Zuverlässigkeitsablauf einen Ausweichpunkt hat. Am 1. Oktober 2026 funktionierte das in v0.8.5 im Terminal — mit einem wichtigen Vorbehalt: Die Wiederherstellungsanfrage ging an das zweite Modell, nicht an das erste; die Antwort nach einem Abbruch stammt also aus deinem Fallback. Der ZeroClaw-Leitfaden zu API-Kosten und Einrichtung behandelt die Konfigurationsstruktur, in der diese Einträge vorgenommen werden.
Was v0.8.5 tat, als der Stream abgebrochen wurde
Am 1. Oktober 2026 lief das Release-Binary v0.8.5, dessen Prüfsumme anhand von SHA256SUMS aus dem Release verifiziert worden war, in einem Wegwerfcontainer im interaktiven Terminalmodus — dem Modus, der streamt; der Einzelnachrichtenmodus -m sendet eine Nicht-Streaming-Anfrage und erreicht diesen Pfad nie. Ein OpenAI-kompatibles Profil mit benutzerdefiniertem Slot, provider_retries = 2, zeigte auf einen lokalen Testserver, der mit einem normalen Stream antwortete und anschließend die Verbindung ohne [DONE] schloss, entweder vor dem ersten Ereignis oder nach einem Text-Chunk.
| Profil | Wo der Stream abbrach | Gesendete Anfragen | Was das Terminal anzeigte |
|---|---|---|---|
| Ein Kandidat | Vor jeglichem Text | Eine Streaming-Anfrage, keine Wiederholung | Fehler: Der ausgewählte Modellanbieter ist fehlgeschlagen. Überprüfe die Anbieterkonfiguration oder wähle einen anderen Anbieter. Das Log: All model providers/models failed after 0 failure event(s) |
| Ein Kandidat | Nachdem Text ausgegeben worden war | Eine Streaming-Anfrage, keine Wiederholung | Der Teiltext, dann derselbe Fehler. Kein [stream interrupted]-Marker wurde ausgegeben |
Zusätzlich fallback_models mit einem zweiten Modell | Vor jeglichem Text | Die Streaming-Anfrage, anschließend eine Nicht-Streaming-Anfrage an das zweite Modell | Die Antwort des zweiten Modells |
Zusätzlich fallback_models mit einem zweiten Modell | Nachdem Text ausgegeben worden war | Dieselben beiden Anfragen | Der Teiltext, anschließend die vollständige Antwort des zweiten Modells — die Antwort erscheint also zweimal |
Für alle, die ZeroClaw von einem Terminal aus mit v0.8.5 betreiben, folgen drei Dinge. Der Fehler mit einem einzigen Kandidaten ist #10736 und wurde reproduziert; provider_retries änderte daran nichts. Die dokumentierte Grenze „keine Wiederholung nach sichtbarer Ausgabe“ galt hier nicht: Bereits im Terminal ausgegebener Text verhinderte keine erneute Sendung, sodass eine Runde, deren Eintreffen du nur teilweise beobachtet hast, weiterhin erneut an ein anderes Modell gesendet werden kann. Außerdem protokollierte das Log der Runde das erste Modell als Modell der Runde, während der Text vom zweiten stammte — genau die Zuordnungslücke, vor der die eigene Dokumentation von v0.8.5 warnt. Nicht abgedeckt durch diesen Lauf sind Channels wie Telegram oder Slack, das Gateway-WebSocket, RPC- und ACP-Clients — die Transporte, für deren Ereignissenken die Regel gegen erneutes Abspielen geschrieben ist —, der Anthropic-Slot, echte Ausfälle von Anbietern und jede Anfrage über Kunavo.
Bevor du erneut sendest: Was wurde bereits ausgeführt und was bereits berechnet?
ZeroClaws eigene Tool-Schleife liest den Stream bis zum Ende, stellt Tool-Aufrufe nach dessen Ende wieder her, führt sie aus und öffnet dann für die nächste Assistant-Runde einen neuen Streaming-Aufruf. Die von der abgebrochenen Iteration angeforderten Tools wurden also nicht ausgeführt — doch das ist weniger beruhigend, als es klingt. Vorab vom Anbieter ausgeführte Tool-Aufrufe sind eine separate Ereignisklasse, die bereits Auswirkungen beim Upstream hatte; genau deshalb verhindern sie ein erneutes Abspielen. Außerdem brechen lange Runden spät ab: #10736 weist darauf hin, dass der vorherige Tool-Aufruf vor dem Fehler erfolgreich abgeschlossen wurde, und das Log von #10787 zeigt den Abbruch in Iteration 2 bei 126 Nachrichten in der Anfrage. Wenn du die ursprüngliche Eingabeaufforderung erneut sendest, werden sämtliche früheren Seiteneffekte wiederholt, die das Modell erneut ausführen würde.
Auch ein sauber wirkendes Transkript ist kein Beweis. Issue #9421, offen mit Priorität p1 für die Anbieterfamilien Anthropic und OpenAI-kompatibel, trägt den Titel, dass unvollständige Terminalantworten als erfolgreich gemeldet werden können. Auf der Code/ACP-Oberfläche beschreiben zwei weitere offene p1-Berichte, dass eine fehlgeschlagene Runde akzeptierte Eingabeaufforderungen und abgeschlossene Tool-Austausche aus dem dauerhaften Verlauf verwirft (#10788) und dass eine Runde, deren Budget überschritten wurde, sichtbaren Fortschritt nach der Sitzungswiederherstellung verliert (#10659); der Pull Request zur Speicherung des Fortschritts unterbrochener Runden ist weiterhin nicht zusammengeführt. Alle waren am 21. September 2026 offen, mehrere sind als in Bearbeitung markiert; prüfe daher erneut, statt diesen Snapshot zu zitieren.
Bei den Kosten widersprechen sich v0.8.5 und master tatsächlich, und Sie sollten die Version lesen, die Ihrem Build entspricht. Die Dokumentation des Releases bezeichnet den abschließenden Datensatz als Erfolgsbenachrichtigung und nicht als kanonisches Hauptbuch aller Versuche und weist darauf hin, dass daraus keine Genauigkeit der Kosten pro Versuch abgeleitet werden soll; master ersetzt diesen Absatz durch ein Pro-Versuch-usage_by_provider-Protokoll aus Pull Request #8966, der am 18. September 2026 gemergt wurde, in keinem Release enthalten ist und von master selbst auf ereignisinstrumentierte Turn-Pfade begrenzt wird. Derweil ist der Nutzungs-Snapshot eines unterbrochenen Streams ein optionales Feld, das fehlen kann, und ZeroClaw fordert bei OpenAI-kompatiblen Endpunkten die Nutzung in einem abschließenden SSE-Chunk an – jenem, den ein abgeschnittener Stream möglicherweise nie sendet. Betrachten Sie diesen letzten Punkt als einen Mechanismus, den Sie in Ihrer eigenen Kostenausgabe prüfen sollten, nicht als ein gemessenes Ergebnis. Stimmen Sie stattdessen mit dem eigenen Nutzungsdatensatz des Endpunkts ab; bei Kunavo ist das das Nutzungsprotokoll.
Warum ein Gateway vor einem Modell diese Markierung erzeugt
Die wahrscheinlichste Ursache bei einem Drittanbieter ist ein Abschluss-Signal, das nie eintrifft. Die Streaming-Dokumentation von ZeroClaw für v0.8.5 besagt, dass Transporte nicht auf das Schließen der Verbindung als Erfolgssignal angewiesen sind: OpenAI-kompatible Streams enden mit [DONE], OpenAI-Responses-Streams mit ihrem terminalen Response-Ereignis und Anthropic-Streams mit message_stop; Server können die HTTP-Verbindung nach diesen Ereignissen offen halten. Ein Stream, der ohne sein Signal geschlossen wird, wird als Fehler – SSE stream closed before {completion_signal}: response truncated – und nicht als kurzer Erfolg behandelt. Das ist ein Fehler des Endpunkts, nicht von ZeroClaw. Eine Ausnahme ist dokumentiert: Der Anthropic-Parser behandelt EOF nach einem nichtleeren message_delta.stop_reason derzeit ebenfalls als abgeschlossen, auch ohne message_stop, und der Pull Request, der dies voraussetzen soll, ist auf keinem der beiden Refs eingegangen.
Die zweite Ursache ist Stille auf einem offenen Socket. ZeroClaw verwendet Byte-Leerlauf-Timeouts statt einer Frist für die gesamte Anfrage; dokumentiert sind 300 Sekunden für OpenAI Responses und OpenAI-kompatible Anbieter sowie 90 Sekunden für Anthropic, wobei jeder Body-Read die Uhr zurücksetzt. Ein Endpunkt, der eine Upstream-Antwort puffert und anderthalb Minuten lang nichts weiterleitet, löst den Anthropic-Familien-Slot aus, während der OpenAI-kompatible Slot bestehen bleibt – wissenswert, weil ein Anthropic-Messages-Endpunkt in den anthropic-Slot mit einem uri-Override gehört, nicht in custom. Siehe die Dokumentation zur Messages-Basis-URL und OpenAI-kompatible API für die beiden Wire-Protokolle.
Was ein toter Turn kostet – beispielhafte Arithmetik
Trennen Sie die beiden Rechnungen. Die ZeroClaw-Laufzeit kostet 0 $ – zeroclaw.com erklärt, dass sie Open Source und doppelt unter MIT ODER Apache-2.0 lizenziert ist, ohne Abonnement und ohne gehosteten Sitz, und dass Sie nur die Kosten Ihres eigenen LLM-Anbieters zahlen oder bei Ausführung eines lokalen Modells mit Ollama überhaupt nichts. Kein Tarif schaltet Fortsetzungen, ein größeres Wiederholungsbudget oder geführte Wiederherstellung frei, weil es keinen Tarif gibt.
Die Modellrechnung ist diejenige, die von einer Unterbrechung betroffen ist. Diese Zahlen sind Token-Arithmetik auf Basis von Annahmen, keine gemessenen Aufgabenkosten und keine Rechnungshöchstgrenze. Nehmen Sie an, dass ein Turn 110.000 nicht zwischengespeicherte Eingabe-Tokens sendet – die Promptgröße im einzigen datierten Überlastungsereignis, das #10787 dokumentiert und bei dem der Upstream die Anfrage akzeptierte und Prefill ausführte, bevor er sie abwies – und 2.000 Ausgabe-Tokens empfängt, bevor der Stream stirbt. Die Spalte für drei Versuche ist provider_retries + 1 beim dokumentierten Standardwert 2. Die Preise sind aktuelle Preise des Kunavo-Katalogs pro Million Tokens.
| Modell | Eingabe / Ausgabe pro 1 Mio. | Ein fehlgeschlagener Versuch | Drei Versuche |
|---|---|---|---|
| Claude Haiku 4.5 | $0.70 / $3.50 | $0.084 | $0.252 |
| GPT-5.6 Terra | $0.70 / $4.20 | $0.085 | $0.256 |
| Claude Sonnet 4.6 | $2.10 / $10.50 | $0.252 | $0.756 |
| Claude Opus 5 | $3.50 / $17.50 | $0.420 | $1.260 |
Ob ein bestimmter Endpunkt eine von ihm abgewiesene Anfrage berechnet, ist seine eigene Abrechnungspolitik; weder der ZeroClaw-Quellcode noch die Dokumentation legen dies fest – diese Seite hat es für keinen Anbieter gemessen. Die Arithmetik soll die Frage quantifizieren, nicht beantworten. Der Katalogbetrag von Kunavo ist eine Abrechnungsuntergrenze, keine Obergrenze: Wenn der Upstream seine Kosten meldet, entspricht die Rechnung dem höheren Wert aus den Katalogkosten und den Upstream-Kosten multipliziert mit dem geltenden Aufschlag. Die minimale Aufladung beträgt $10 als vorausbezahltes Guthaben, eine Mindestfinanzierung und weder eine Aufgaben- noch eine Abonnementgebühr – siehe Abrechnungsdetails.
Welche Route diesem Fehler am besten standhält
| Weg | Verhalten bei einem Abbruch mitten im Stream | Worauf Sie verzichten |
|---|---|---|
| Ein Endpunkt, direkter Anbieter | Eine Zuverlässigkeitskonfiguration mit nur einem Kandidaten, daher gehört sie zur in #10736 gemeldeten Population auf v0.8.5 | Dass es sich um einen Erstanbieter handelt, ändert den Ablauf nicht; ein Kandidat bleibt ein Kandidat |
| Ein Endpunkt, Gateway | Identische Form mit nur einem Kandidaten. Was ein Gateway hier ermöglicht, ist der Wechsel zwischen Modellen über einen Schlüssel und ein Guthaben, nicht Stream-Resilienz | Ein zusätzlicher Hop, der selbst ohne Abschluss-Signal schließen kann, und den ZeroClaw nur dann bepreist, wenn Sie seine [cost.rates]-Einträge selbst schreiben |
| Zwei oder mehr Kandidaten im Profil | Der Zuverlässigkeitsablauf hat einen Ausweg. Beim terminalen Lauf am 1. Oktober 2026 wurde die Ausführung nach einem frühen und einem Abbruch mitten in der Antwort wiederhergestellt – über das zweite Modell | Ein zweites Modell oder Alias, das gepflegt werden muss, und eine wiederhergestellte Antwort, die von Ihrem Fallback statt von Ihrer ersten Wahl stammt |
| Lokales Modell über Ollama | Ein erneutes Senden kostet Zeit und Hardware statt Geld, daher ist ein konservativer Wiederholungsversuch günstig | Die Fähigkeitslücke gegenüber gehosteten Frontier-Modellen – und eine Maschine, auf der eines ausgeführt wird |
| Ein Agent mit Pauschalabonnement | Überhaupt keine ZeroClaw-Route – das Projekt hat kein Abonnement und keinen gehosteten Sitz | Sie würden den Client ändern, nicht das Wiederherstellungsverhalten von ZeroClaw |
Welche Option Sie auch wählen, die Betriebsregel ist die, die ZeroClaw bereits kodiert: Nach [stream interrupted] lesen Sie den persistent gespeicherten Teil, stellen fest, was bereits wirksam geworden ist, und senden dann erneut etwas, das enger gefasst ist als das Original. Die Konfigurationsreferenzen von Kunavo für OpenAI-kompatible und Messages-ähnliche Endpunkte sind Einrichtungsdokumentation und kein Kompatibilitätstest – der Lauf vom 1. Oktober oben verwendete einen lokalen Testserver, nicht Kunavo. Beginnen Sie mit der Fehlerreferenz, um zu entschlüsseln, was Ihr Endpunkt zurückgegeben hat, und erstellen Sie ein Kunavo-Konto, wenn Sie bereit sind, einen Schlüssel aufzuladen. OpenRouter vs. LiteLLM ist der nächstliegende Vergleich für die obige Entscheidung zwischen einem und mehreren Kandidaten.
Häufig gestellte Fragen
Wiederholt ZeroClaw einen unterbrochenen Stream?
Das hängt vollständig davon ab, ob bereits Ausgabe sichtbar war. ZeroClaws Dokumentation zum Anbieterrouting für die veröffentlichte v0.8.5 besagt, dass der Stream einmal geöffnet wird und Einträge nach dem Start nicht mehr gewechselt werden; daher wird nie etwas fortgesetzt — eine Wiederherstellung, sofern vorhanden, ist eine vollständig neue Anfrage. Wenn der Stream fehlschlägt, bevor irgendeine unveränderliche Ereignisausgabe sichtbar ist, besteht das dokumentierte Verhalten darin, den gesamten Aufruf über den Nicht-Streaming-Pfad erneut zu versuchen. Sobald Text, Reasoning oder vorab ausgeführte Tool-Ereignisse eine unveränderliche Ereignissenke erreicht haben, wird die Unterbrechung zu StreamInterruptedAfterOutput, und die Laufzeit spielt die Anfrage nicht erneut ab. Diese zweite Regel gilt auch auf master. Bei einem Lauf am 1. Oktober 2026 im interaktiven Terminal-Client von v0.8.5 trat jedoch keine der beiden Regeln wie beschrieben auf: Mit einem Kandidaten wurde weder vor noch nach dem Erscheinen von Text etwas erneut versucht, und mit einem zweiten Kandidaten in fallback_models wurde die Runde in beiden Fällen ohne Streaming erneut an dieses zweite Modell gesendet, auch nachdem ein Teil der Antwort ausgegeben worden war. Channels und das Gateway-WebSocket wurden nicht ausgeführt. Dokumentation geprüft am 21. September 2026.
Was bedeutet [stream interrupted] in ZeroClaw?
Es ist der für Benutzer sichtbare Marker für einen Transportstream, der mitten in einer Runde abgebrochen ist. In ZeroClaws englischer Locale-Datei ist er als Fluent-Schlüssel turn-stream-interrupted definiert und wird über jeden Transport hinweg angezeigt — Channels, WS, RPC, ACP und CLI. Er unterscheidet sich absichtlich von [interrupted by user] und [turn cancelled via client]; wenn du diesen Marker siehst, hat also niemand auf Stopp gedrückt. Wenn der Stream nach sichtbarer Ausgabe abbricht, wird der teilweise Text als Assistant-Nachricht gespeichert und der Marker angehängt, jedoch nur, wenn dieser Teiltext nicht leer ist: Eine Runde, die ausschließlich Reasoning oder ausschließlich vorab ausgeführte Tool-Ereignisse erzeugt hat, speichert nichts. Nicht-englische Installationen enthalten denselben Schlüssel mit übersetztem Text; suche daher nicht nach der englischen eckigen Klammerzeichenfolge. Gelesen am Release-Tag v0.8.5 am 21. September 2026. Im interaktiven Terminal-Client von v0.8.5 wurde bei einem am 1. Oktober 2026 mitten in der Antwort abgebrochenen Stream dieser Marker nicht ausgegeben; das Terminal zeigte stattdessen einen Anbieterfehler.
Ist es sicher, die Eingabeaufforderung nach einer ZeroClaw-Streamunterbrechung einfach erneut zu senden?
Nicht automatisch, und ZeroClaws eigene Maintainer behandeln es entsprechend. Die Laufzeit liest einen Stream bis zum Ende, stellt Tool-Aufrufe nach dessen Ende wieder her und führt sie anschließend aus — die Tools der abgebrochenen Iteration wurden also nicht ausgeführt. Eine lange Runde kann jedoch auch in späteren Iterationen abbrechen: Ein Upstream-Bericht weist darauf hin, dass der vorherige Tool-Aufruf vor dem Fehler erfolgreich abgeschlossen wurde, und ein anderer Log zeigt den Abbruch in Iteration 2 bei 126 Nachrichten in der Anfrage. Alles, was eine frühere Iteration bereits getan hat — eine Datei geschrieben, einen Befehl ausgeführt, eine Nachricht gesendet — geschieht erneut, wenn du dieselbe Eingabeaufforderung blind erneut sendest. Die offene Feature-Anfrage zur geführten Wiederherstellung nennt als eigene Nichtziele das blinde Wiedergeben einer tool- oder genehmigungstragenden Runde und die Behandlung jedes Anbieterfehlers als vorübergehend. Lies zuerst den gespeicherten Teiltext, prüfe, was bereits wirksam wurde, und sende dann eine eingegrenzte Eingabeaufforderung statt der ursprünglichen erneut.
Kann ich ZeroClaw so konfigurieren, dass der unterbrochene Stream fortgesetzt wird?
Nein. In keiner veröffentlichten Version gibt es dafür eine Einstellung und auch keine kostenpflichtige Stufe, die eine solche freischaltet — ZeroClaw ist kostenlos und Open Source, dual lizenziert unter MIT OR Apache-2.0, ohne Abonnement und ohne gehosteten Sitz; die Grenze ist daher technisch bedingt und keine Tarifgrenze. Die Regel, nach sichtbarer Ausgabe nicht erneut abzuspielen, steht im Quellcode und wird durch einen Regressionstest abgesichert, dessen Fehlermeldung besagt, dass ein Streamfehler nach sichtbarer Ausgabe die Runde ohne Fallback-Wiederholung fehlschlagen lassen muss — allerdings sendete der interaktive Terminal-Client von v0.8.5 am 1. Oktober 2026 bei einem Profil mit einem zweiten Kandidaten nach ausgegebenem Text erneut, sodass diese Regel nicht für jeden Transport garantiert ist. Die geführte Wiederherstellung nach einer unterbrochenen Runde ist Issue #10634 — offen, mit status:accepted und priority:p2 gekennzeichnet und am 21. September 2026 zunächst an needs design oder eine RFC-Diskussion weitergeleitet. Accepted bedeutet, dass die Triage die Problembeschreibung akzeptiert hat, nicht, dass Code geschrieben oder zusammengeführt wurde.
Mein Log sagt, dass auf Nicht-Streaming-Chat zurückgefallen wird, und dann stirbt die Runde. Warum?
In der veröffentlichten v0.8.5 kann diese Logzeile unwahr sein. Upstream Issue #10736, mit dem Titel, dass ein Streamfehler vor der Ausgabe den angekündigten Nicht-Streaming-Fallback überspringt, berichtet, dass die Laufzeit protokolliert, auf Nicht-Streaming-Chat zurückzufallen, aber die Nicht-Streaming-Anfrage nicht sendet; die Runde endet sofort mit All model providers/models failed after 0 failure event(s). Die eigene Auswirkungsbeschreibung nennt als betroffene Gruppe Benutzer mit einem einzigen Anbieter-Kandidaten, insbesondere Konfigurationen mit null Wiederholungen. Null Wiederholungen sind nicht der einzige Fall: Die Reproduktion setzt provider_retries = 0, aber das Folge-Issue #10787 reproduziert denselben sofortigen Fehler mit dem dokumentierten Standardwert 2 für provider_retries. Das Issue wurde am 18. September 2026 geschlossen, nachdem v0.8.5 am 5. September veröffentlicht worden war; keine veröffentlichte Version enthält daher die Korrektur. Es wurde am 1. Oktober 2026 in v0.8.5 reproduziert: eine Streaming-Anfrage, kein Nicht-Streaming-Folgeaufruf und dieser Fehler — mit provider_retries = 2 und unabhängig davon, ob der Stream vor oder nach dem Erscheinen von Text abbrach. Das Hinzufügen eines zweiten Modells unter fallback_models genügte, damit sich die Runde erholte. Wer dies in v0.8.5 anhand der Logs debuggt, liest einen Fallback, der nicht stattgefunden hat.
Wurde mir die unterbrochene Runde berechnet, und wie prüfe ich das?
Prüfe den eigenen Nutzungsdatensatz des Endpunkts statt den von ZeroClaw, da die Dokumentation von v0.8.5 dich anweist, der Zahl pro Versuch nicht zu vertrauen: Sie beschreibt den abschließenden Fallback-Hinweis als Erfolgsmeldung, nicht als kanonisches Verzeichnis jedes Versuchs, und sagt, dass daraus keine Genauigkeit der Kosten pro Versuch abgeleitet werden soll. Das usage_by_provider-Verzeichnis pro Versuch, das dies auflöst, gelangte über Pull Request #8966 auf master und wurde am 18. September 2026 zusammengeführt, nachdem v0.8.5 ausgeliefert worden war; es ist daher in keiner Version enthalten — und master beschränkt es auf ereignisinstrumentierte Rundenpfade. ZeroClaw erfasst bei einem unterbrochenen Stream zwar einen Nutzungs-Snapshot, aber das Feld ist optional und kann fehlen; außerdem fordert es von OpenAI-kompatiblen Endpunkten die Nutzung in einem abschließenden SSE-Chunk an — genau dem Chunk, den ein abgebrochener Stream möglicherweise nie liefert. Dieser letzte Punkt ist aus dem Quellcode abgeleitet, nicht zur Laufzeit beobachtet. Separat stammen ZeroClaws eigene Kostenangaben aus den vom Betreiber geschriebenen [cost.rates]-Preisblättern in deiner Konfiguration; ein Endpunkt, für den du dort keinen Preis festgelegt hast, ist auch für ZeroClaw nicht bepreist.
Ausgeführt am 1. Oktober 2026: das Release-Binary v0.8.5 im interaktiven Terminalmodus gegen einen lokalen Testserver, der den Stream abbrach – die vier Zeilen der Ergebnistabelle; nichts anderes wurde ausgeführt, und keine Anfrage ging an Kunavo. Die Issue-Status wurden am selben Tag erneut geprüft (#10787 ist inzwischen geschlossen; #10634 ist weiterhin offen). Der Repository-Quellcode wurde am Release-Tag v0.8.5 gelesen, die Dokumentation unter dem versionsgebundenen Pfad /v0.8.5/; Issue- und Pull-Request-Status wurden am 21. September 2026 gelesen. Mehrere dieser Issues waren als in Bearbeitung markiert und können sich ändern. Die Kunavo-Tokenpreise stammen aus dem aktuellen Katalog, und jeder Dollarbetrag hier ist beispielhafte Token-Arithmetik statt gemessener Aufgabenkosten.