ZeroClaw never resumes a broken stream, and once any output has reached you it does not retry the request either — [stream interrupted] is the runtime stopping on purpose, not a transient glitch you can configure away. On the only current release, v0.8.5 (published September 5, 2026), retry exists solely before you have seen anything, and even that has a documented hole for a setup with one endpoint. Guided recovery after partial output is an open feature request that has not reached design sign-off. So the useful question is not how to make ZeroClaw retry. It is whether your turn is safe for you to re-send, and what the dead attempt already cost.
Two scope notes before any of this is actionable. Nothing here was reproduced on a running ZeroClaw: no install, no induced interruption. Every claim is read from the repository at release tag v0.8.5, from the version-pinned documentation at docs.zeroclaw.com/v0.8.5/, or from dated upstream issue reports, all on September 21, 2026. And pin that URL yourself: the README sends readers to the /master/ path, whose HEAD is sixteen days ahead of the release and which contradicts it on exactly this subject, while /latest/ returns 404. ZeroClaw here means the zeroclaw-labs/zeroclaw runtime; if you are not certain that is what you are running, ZeroClaw vs OpenClaw separates it from the projects and forks that share the name.
Four markers at v0.8.5, and only one of them is the network
Before deciding anything, read which marker you actually got. ZeroClaw's English locale file at v0.8.5 defines these as distinct Fluent keys under a header comment saying they are appended to, or persisted as, assistant output when a turn is cut short, and shown to end users across every transport — channels, WS, RPC, ACP and CLI.
| Marker | Fluent key | What it tells you |
|---|---|---|
[stream interrupted] | turn-stream-interrupted | The transport stream died mid-turn. Nobody pressed stop. |
[interrupted by user] | turn-interrupted-by-user | A human interrupt. |
[turn cancelled via client] | turn-cancelled-client-rpc | The channel, not the actor. Its own code comment says human interrupts and programmatic client cancels both arrive on this path, so the wording names the channel. |
[interrupted by user before this tool produced a result] | turn-tool-interrupted-before-result | A tool was cut off before returning. |
A fifth key, turn-failed = [turn failed], exists in the same file on master but is not in v0.8.5's locale file, so a released build does not emit it. One behavior worth knowing because it changes what you can read afterwards: the turn engine persists the partial text with the marker appended only when that partial text is non-empty. A turn that produced reasoning or provider-side pre-executed tool events but no visible text persists nothing at all — the code comment frames persistence as committing what the consumer already saw. Other locales carry the same keys with translated values, so the literal English bracket string is not what a non-English install shows.
Where the retry boundary actually sits
The whole decision reduces to one question: had anything reached an immutable event sink yet?
| What happened | Documented behavior at v0.8.5 | Caveat |
|---|---|---|
| Stream fails before any visible output | The runtime retries the whole call through the non-streaming path, re-entering the full reliability walk | Documented, but not what a single-candidate setup observed on the released build — see below |
| Stream completes with no final text and no tool calls | A semantic-empty response, not an answer. When the result is marked replay-safe and provider_retries is nonzero, one non-streaming recovery call to the exact same provider and model, consumed once | Shipped in v0.8.5 via pull request #10602, merged September 4, 2026. Applies to empty streams, not to streams that broke mid-output |
| Text, reasoning or pre-executed tool events already reached an immutable event sink | StreamInterruptedAfterOutput. The runtime does not replay the request, and text already forwarded to the consumer is all that becomes persisted partial assistant text | Deliberate and identical on master. Locked by a regression test asserting a stream error after visible output must fail the turn with no fallback retry |
| Any of the above | The stream is opened once and entries are not switched after it has started | Recovery is always a new request. No provider family, including the custom slot, gets a resume path |
The knobs that do exist are global, not per endpoint. [reliability] carries provider_retries, documented default 2, and provider_backoff_ms, default 500, and the lifecycle doc states each materialized entry is attempted up to provider_retries + 1 times. The v0.8.5 config reference documents no per-provider or per-alias retry override alongside them. Do not count on the key pool either: v0.8.5's documentation says reliability.api_keys is not a working failover today, because the wrapper selects and logs an alternate key after a retryable rate limit but cannot apply it to the constructed provider, so the retry still uses the original credential. A second key you added expecting a rescue does not provide one.
Pointing at one endpoint is the configuration that gets hurt
This is the sharpest boundary for anyone running ZeroClaw against a single gateway or a single vendor endpoint, because one endpoint is by definition a single-candidate reliability configuration. Issue #10736 reports that on the released build a pre-output stream failure in that shape logs a fallback to non-streaming chat and then never sends it, killing the turn with All model providers/models failed after 0 failure event(s). It closed September 18, 2026 — after v0.8.5 was published — so the fix is on master only.
Two official positions disagree here and both are worth carrying. The v0.8.5 architecture doc promises the non-streaming retry; the issue demonstrates the released build not performing it, and its expected-behavior section asks that the log only claim a fallback when one will actually be attempted. Master then adds a single-candidate recovery allowance the release does not have — and issue #10787, still open, says that allowance is granted with RetryDecision::Admit(0) regardless of provider_retries and with no backoff, so an overloaded upstream is re-sent immediately into the same shed window. Master's behavior is not settled; do not plan against it.
The documented shape of a mitigation is configuration rather than a setting: give the profile a second candidate so the reliability walk has somewhere to go. Be clear about the evidence though — #10736 proves the one-candidate case fails, and neither it nor anything else read here demonstrates a two-candidate profile succeeding on v0.8.5. This page did not test it. The ZeroClaw API cost and setup guide covers the config shape those entries go in.
Before you re-send: what already ran, and what already billed
ZeroClaw's own tool loop reads the stream to completion, recovers tool calls after it ends, runs them, then opens a fresh streaming call for the next assistant turn. So the tools requested by the iteration that broke have not run — but that is a narrower comfort than it sounds. Provider-side pre-executed tool calls are a separate event class that already had effects upstream, which is precisely why they block replay. And long turns break late: #10736 notes the preceding tool call completed successfully before its failure, and #10787's log shows the break landing on iteration 2 with 126 messages in the request. Re-sending the original prompt replays every earlier side effect the model would repeat.
A clean-looking transcript is not proof either. Issue #9421, open at priority p1 against both the Anthropic and the OpenAI-compatible provider families, is titled that incomplete terminal responses can be reported as successful. On the Code/ACP surface two further open p1 reports describe a failed turn discarding accepted prompts and completed tool exchanges from durable history (#10788) and a budget-exceeded turn losing visible progress after session restore (#10659), with the pull request to persist interrupted turn progress still unmerged. All were open on September 21, 2026 and several are marked in progress, so re-check rather than quote this snapshot.
On cost, v0.8.5 and master genuinely disagree and you should read the one matching your build. The release's doc calls the final record a success notice rather than a canonical ledger of every attempt and says not to infer per-attempt cost accuracy from it; master replaces that paragraph with a per-attempt usage_by_provider ledger from pull request #8966, merged September 18, 2026, which no release contains and which master itself scopes to event-instrumented turn paths. Meanwhile the interrupted-stream usage snapshot is an optional field that can be absent, and ZeroClaw asks OpenAI-compatible endpoints for usage in a final SSE chunk — the one a truncated stream may never send. Treat that last point as a mechanism to check in your own cost output, not as a measured result. Reconcile against the endpoint's own usage record instead; on Kunavo that is the usage log.
Why a gateway in front of a model produces this marker
The most likely third-party cause is a completion signal that never arrives. ZeroClaw's v0.8.5 streaming documentation states that transports do not rely on connection close as the success signal: OpenAI-compatible streams finish on [DONE], OpenAI Responses streams on their terminal response event, and Anthropic streams on message_stop, and servers may keep the HTTP connection open after those events. A stream that closes without its signal is surfaced as an error — SSE stream closed before {completion_signal}: response truncated — rather than as a short success. That is an endpoint defect, not a ZeroClaw one. One exception is documented: the Anthropic parser currently also treats EOF after a non-empty message_delta.stop_reason as complete even without message_stop, and the pull request proposing to require it has not landed on either ref.
The second cause is silence on an open socket. ZeroClaw uses byte-idle timeouts rather than a whole-request deadline, documented as 300 seconds for OpenAI Responses and OpenAI-compatible providers and 90 seconds for Anthropic, with each body read resetting the clock. An endpoint that buffers an upstream response and forwards nothing for a minute and a half trips the Anthropic family slot while surviving the OpenAI-compatible one — worth knowing because an Anthropic Messages endpoint goes on the anthropic slot with a uri override, not on custom. See the Messages base URL doc and OpenAI-compatible API for the two wire protocols.
What a dead turn costs, in illustrative arithmetic
Separate the two bills. The ZeroClaw runtime is $0 — zeroclaw.com states it is open source, dual-licensed MIT OR Apache-2.0, with no subscription and no hosted seat, and that you pay only your own LLM provider costs, or nothing at all running a local model with Ollama. No tier unlocks resume, a larger retry budget or guided recovery, because there is no tier.
The model bill is the one an interruption touches. These figures are token arithmetic on assumptions, not a measured task cost and not a bill ceiling. Assume one turn sending 110,000 uncached input tokens — the prompt size in the single dated overload episode #10787 records, where the upstream accepted the request and ran prefill before shedding it — and receiving 2,000 output tokens before the stream dies. The three-attempt column is provider_retries + 1 at the documented default of 2. Rates are live Kunavo catalog prices per million tokens.
| Model | Input / output per 1M | One dead attempt | Three attempts |
|---|---|---|---|
| GPT-5.6 Luna | $0.07 / $0.42 | $0.009 | $0.026 |
| Claude Haiku 4.5 | $0.40 / $2.00 | $0.048 | $0.144 |
| Gemini 3.8 Flash | $0.525 / $2.625 | $0.063 | $0.189 |
| Claude Sonnet 4.6 | $1.20 / $6.00 | $0.144 | $0.432 |
| Claude Opus 5 | $2.00 / $10.00 | $0.240 | $0.720 |
Whether any given endpoint charges for a request it shed is that endpoint's own billing policy, and nothing in ZeroClaw's source or documentation states it — this page did not measure it for any provider. The arithmetic is here to size the question, not to answer it. Kunavo's catalog amount is a billing floor rather than a cap: when the upstream reports its charge, the bill is the greater of catalog cost and upstream cost times the applicable markup. The minimum top-up is $10 in prepaid credit, a funding minimum rather than a task fee or subscription — see billing details.
Which route holds up best against this failure
| Route | How it behaves on a mid-stream break | What you give up |
|---|---|---|
| One endpoint, direct vendor | A single-candidate reliability configuration, so it sits in #10736's reported population on v0.8.5 | Nothing about being a first-party vendor changes the walk; one candidate is one candidate |
| One endpoint, gateway | Identical single-candidate shape. What a gateway buys here is switching models on one key and one balance, not stream resilience | An extra hop that can itself close without a completion signal, and ZeroClaw prices it only if you write its [cost.rates] entries yourself |
| Two or more candidates in the profile | The documented reliability walk has somewhere to go after a pre-output failure | A second account or alias to maintain. Documented design; not demonstrated at runtime by any source read here |
| Local model via Ollama | A re-send costs time and hardware rather than money, so a conservative retry is cheap | The capability gap against hosted frontier models, and a machine to run one |
| A flat-rate subscription agent | Not a ZeroClaw route at all — the project has no subscription and no hosted seat | You would be changing client, not changing ZeroClaw's recovery behavior |
Whichever you pick, the operating rule is the one ZeroClaw already encodes: after [stream interrupted], read the persisted partial, establish what already took effect, then re-send something narrower than the original. Kunavo's configuration references for OpenAI-compatible and Messages-style endpoints are setup documentation rather than a compatibility test — ZeroClaw has not been runtime-tested here. Start at the error reference to decode what your endpoint returned, and create a Kunavo account when you are ready to fund a key. OpenRouter vs LiteLLM is the closest comparison for the one-candidate-versus-many decision above.
FAQ
Does ZeroClaw retry a stream that was interrupted?
It depends entirely on whether you had already seen output. ZeroClaw's provider-routing documentation for the released v0.8.5 says the stream is opened once and entries are not switched after it has started, so nothing is ever resumed — recovery, where it exists, is a brand-new request. If the stream fails before any immutable event output is visible, the documented behavior is that the runtime retries the whole call through the non-streaming path. Once text, reasoning or pre-executed tool events have reached an immutable event sink, the interruption becomes StreamInterruptedAfterOutput and the runtime does not replay the request. That second rule is the same on master, so it is the one statement here that needs no version caveat. Checked September 21, 2026.
What does [stream interrupted] mean in ZeroClaw?
It is the user-visible marker for a transport stream that died mid-turn, defined in ZeroClaw's English locale file as the Fluent key turn-stream-interrupted and shown across every transport — channels, WS, RPC, ACP and CLI. It is deliberately a different marker from [interrupted by user] and [turn cancelled via client], so seeing this one tells you nobody pressed stop. When the stream dies after visible output, the partial text is persisted as an assistant message with the marker appended, but only when that partial text is non-empty: a turn that produced only reasoning or only pre-executed tool events persists nothing. Non-English installs carry the same key with translated text, so do not grep for the English bracket string on one. Read at release tag v0.8.5 on September 21, 2026.
Is it safe to just re-send the prompt after a ZeroClaw stream interruption?
Not automatically, and ZeroClaw's own maintainers treat it that way. The runtime reads a stream to completion, recovers tool calls after it ends, then runs them — so the tools of the iteration that broke have not run. But a long turn breaks on later iterations too: one upstream report notes the preceding tool call completed successfully before the failure, and another's log shows the break landing on iteration 2 with 126 messages in the request. Anything an earlier iteration already did — a file written, a command run, a message sent — happens again if you re-send the same prompt blind. The open feature request for guided recovery lists its own non-goals as blindly replaying a tool-bearing or approval-bearing turn and treating every provider error as transient. Read the persisted partial text first, check what already took effect, then re-send a narrowed prompt rather than the original.
Can I configure ZeroClaw to resume the broken stream?
No. There is no setting for it in any released version, and no paid tier that unlocks one — ZeroClaw is free and open source, dual-licensed MIT OR Apache-2.0, with no subscription and no hosted seat, so the limit is an engineering boundary rather than a plan boundary. The no-replay-after-visible-output rule is compiled in and locked by a regression test whose own failure message reads that a stream error after visible output must fail the turn with no fallback retry. Guided recovery after an interrupted turn is issue #10634 — open, labelled status:accepted and priority:p2, and routed to needs design or RFC discussion first as of September 21, 2026. Accepted means triage accepted the problem statement, not that code was written or merged.
My log says it is falling back to non-streaming chat and then the turn dies. Why?
On the released v0.8.5 that log line can be untrue. Upstream issue #10736, titled that a pre-output stream failure skips the advertised non-streaming fallback, reports that the runtime logs it is falling back to non-streaming chat but does not send the non-streaming request, and the turn terminates immediately with All model providers/models failed after 0 failure event(s). Its own impact statement names the affected population as users with a single provider candidate, especially configurations with zero retries. Zero retries is not the only case: its reproduction sets provider_retries = 0, but the follow-on issue #10787 reproduces the same immediate failure with provider_retries left at the documented default of 2. The issue closed on September 18, 2026, after v0.8.5 was published on September 5, so no published release contains the fix. Debugging this from logs on v0.8.5 means reading a fallback that did not happen.
Was I billed for the interrupted turn, and how do I check?
Check the endpoint's own usage record rather than ZeroClaw's, because v0.8.5's documentation tells you not to trust its per-attempt figure: it describes the final fallback notice as a success notice, not a canonical ledger of every attempt, and says not to infer per-attempt cost accuracy from it. The per-attempt usage_by_provider ledger that resolves this landed on master via pull request #8966, merged September 18, 2026, after v0.8.5 shipped, so it is in no release — and master scopes it to event-instrumented turn paths. ZeroClaw does capture a usage snapshot on an interrupted stream, but the field is optional and can be absent, and it asks OpenAI-compatible endpoints for usage in a final SSE chunk — the chunk a truncated stream may never deliver. That last point is read from the source, not observed at runtime. Separately, ZeroClaw's own cost figures come from the operator-written [cost.rates] rate sheets in your config, so an endpoint you have not priced there is not priced by ZeroClaw either.
ZeroClaw was not installed or interrupted for this page. Repository source read at release tag v0.8.5, documentation read at the version-pinned /v0.8.5/ path, and issue and pull-request states read on September 21, 2026; several of those issues were marked in progress and can move. Kunavo token rates come from the live catalog, and every dollar figure here is illustrative token arithmetic rather than a measured task cost.